7:07 a.m.
Hello,
'xm dump-core -L <domain>' generates a coredump of a Xen4 HVM guest, and
crash is able to poke around in this coredump.
Thanks for that.
But: How can I use crash to debug the crash/kdump kernel itself?
I did a 'echo c > /proc/sysrq-trigger' and want to look at the crash
kernel, not the normal kernel.
Olaf
7:42 a.m.
New subject: How do debug the kdump kernel using a Xen dump-core file?
Hi Olaf,
On Thu, Feb 10, 2011 at 02:07:02PM +0100, Olaf Hering wrote:
Hello,
'xm dump-core -L <domain>' generates a coredump of a Xen4 HVM guest, and
crash is able to poke around in this coredump.
Thanks for that.
But: How can I use crash to debug the crash/kdump kernel itself?
I did a 'echo c > /proc/sysrq-trigger' and want to look at the crash
kernel, not the normal kernel.
Olaf
You can make the crash kernel come all the way up to multi-user mode.
Then run crash. I haven't run crash under the crash kernel, but I don't
see why it wouldn't work.
I use this method with a SLES system:
edit /etc/sysconfig/kdump and set KDUMP_SAVEDIR to a
non-existing dir:
KDUMP_SAVEDIR="file:///fubar"
KDUMP_IMMEDIATE_REBOOT="no"
Or this seems to work with a RHEL6 system:
- edit /etc/init.d/kdump and comment out the makedumpfile and restart
lines; just make it exit
- modify script /sbin/mkdumprd so that it does not save a
dump, but goes to user mode:
2429,2430c2429,2432
< emit " $CORE_COLLECTOR /proc/vmcore \$VMCORE-incomplete...
emit "# $CORE_COLLECTOR /proc/vmcore
\$VMCORE-incomplete...
---
< emit " exitcode=\$?"
emit " exitcode=1"
2444c2446,2448
< emit " $FINAL_ACTION"
emit " echo bye"
and
/etc/init.d/kdump to not call save_core in the crash kernel:
start)
if [ -s /proc/vmcoreXXX ]; then
save_core
)
-Cliff
--
Cliff Wickman
SGI
cpw(a)sgi.com
(651) 683-3824
7:54 a.m.
New subject: How do debug the kdump kernel using a Xen dump-core file?
----- Original Message -----
Hi Olaf,
On Thu, Feb 10, 2011 at 02:07:02PM +0100, Olaf Hering wrote:
>
> Hello,
>
> 'xm dump-core -L <domain>' generates a coredump of a Xen4 HVM guest,
and
> crash is able to poke around in this coredump.
> Thanks for that.
>
> But: How can I use crash to debug the crash/kdump kernel itself?
> I did a 'echo c > /proc/sysrq-trigger' and want to look at the crash
> kernel, not the normal kernel.
>
> Olaf
You can make the crash kernel come all the way up to multi-user mode.
Then run crash. I haven't run crash under the crash kernel, but I don't
see why it wouldn't work.
Hmmm. I've never tried it, but because of the relocation, live access
won't work. But you *may* be able to coerce it into coming up by forcing
the phys_base to whatever it is:
# crash --machdep phys_base=<physical-base-address>
BTW, that's with x86_64 only.
Dave
I use this method with a SLES system:
edit /etc/sysconfig/kdump and set KDUMP_SAVEDIR to a
non-existing dir:
KDUMP_SAVEDIR="file:///fubar"
KDUMP_IMMEDIATE_REBOOT="no"
Or this seems to work with a RHEL6 system:
- edit /etc/init.d/kdump and comment out the makedumpfile and restart
lines; just make it exit
- modify script /sbin/mkdumprd so that it does not save a
dump, but goes to user mode:
2429,2430c2429,2432
< emit " $CORE_COLLECTOR /proc/vmcore \$VMCORE-incomplete...
> emit "# $CORE_COLLECTOR /proc/vmcore
> \$VMCORE-incomplete...
---
< emit " exitcode=\$?"
> emit " exitcode=1"
2444c2446,2448
< emit " $FINAL_ACTION"
> emit " echo bye"
and /etc/init.d/kdump to not call save_core in the crash kernel:
start)
if [ -s /proc/vmcoreXXX ]; then
save_core
)
-Cliff
--
Cliff Wickman
SGI
cpw(a)sgi.com
(651) 683-3824
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
8:13 a.m.
New subject: How do debug the kdump kernel using a Xen dump-core file?
On Thu, Feb 10, Dave Anderson wrote:
Hmmm. I've never tried it, but because of the relocation, live
access
won't work. But you *may* be able to coerce it into coming up by forcing
the phys_base to whatever it is:
# crash --machdep phys_base=<physical-base-address>
BTW, that's with x86_64 only.
That did the trick. Thanks.
After looking for a line like this in the normal kernel:
Reserving 128MB of memory at 32MB for crashkernel (System RAM: 1024MB)
crash --machdep phys_base=32M -s \
/boot/System.map-2.6.32.27-21-default \
/boot/vmlinux-2.6.32.27-21-default.gz \
/var/lib/xen/dump/sles11_4/2011-0210-1335.40-sles11_4.3.core
Olaf
7:45 a.m.
New subject: How do debug the kdump kernel using a Xen dump-core file?
----- Original Message -----
Hello,
'xm dump-core -L <domain>' generates a coredump of a Xen4 HVM guest, and
crash is able to poke around in this coredump.
Thanks for that.
But: How can I use crash to debug the crash/kdump kernel itself?
I did a 'echo c > /proc/sysrq-trigger' and want to look at the crash
kernel, not the normal kernel.
Olaf
There is no facility for kdump'ing the secondary "kdump" kernel.
Dave
7:52 a.m.
New subject: How do debug the kdump kernel using a Xen dump-core file?
On Thu, Feb 10, Dave Anderson wrote:
----- Original Message -----
> Hello,
>
> 'xm dump-core -L <domain>' generates a coredump of a Xen4 HVM guest,
and
> crash is able to poke around in this coredump.
> Thanks for that.
>
> But: How can I use crash to debug the crash/kdump kernel itself?
> I did a 'echo c > /proc/sysrq-trigger' and want to look at the crash
> kernel, not the normal kernel.
>
> Olaf
There is no facility for kdump'ing the secondary "kdump" kernel.
'xm dump-core' can appearently create the required core file while the
kdump kernel runs. Just crash can appearently not "switch over".
What should I modify in crash to let it work from a different "offset",
in other words: the memory reserved for the kdump kernel?
Olaf
8:12 a.m.
New subject: How do debug the kdump kernel using a Xen dump-core file?
----- Original Message -----
'xm dump-core' can appearently create the required core file while the
kdump kernel runs. Just crash can appearently not "switch over".
What should I modify in crash to let it work from a different "offset",
in other words: the memory reserved for the kdump kernel?
Olaf
Ah, I misunderstood. So you are running an HVM guest which has kdump
enabled, the guest has crashed, and now you want to look at the guest's
kdump kernel.
Anyway, like I mentioned in my last message, you *may* be able to coerce
it into running by adding the --machdep physbase=<physical-address> option.
And that would only be possible if it's an x86_64 guest. I'm not sure
what the <physical-address> value should be in that case, so you would
have to experiment.
Normally people don't have much interest in debugging the kdump kernel...
Dave
4958
days inactive
4958
days old
devel@lists.crash-utility.osci.io
6 comments
3 participants
participants (3)
-
Cliff Wickman -
Dave Anderson -
Olaf Hering