Red Hat Bugzilla – Bug 714162
kdump kernel crash during panic handling, kvm guest
Last modified: 2013-04-05 15:47:10 EDT
Created attachment 505279 [details]
serial console logs from guest kernel, then crash, then kdump kernel
A kdump kernel reproducibly fails to start after an induced crash.
This is for a rawhide x86-64 instance, running inside a KVM guest (4 CPU,
This is how the main guest kernel is started up:
[ 0.000000] Kernel command line: ro root=/dev/mapper/VolGroup-lv_root nomodes
et SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us rd_plytheme=text crash
kernel=64m@128m divider=10 selinux=0 console=ttyS0,115200 console=tty0
With a working "service kdump on" etc. A "echo c > /proc/sysrq-trigger"
reboots the guest, starting up the kdump kernel image:
[ 0.000000] Linux version 2.6.39-0.rc7.git0.0.fc16.x86_64 (email@example.com
hx2.fedoraproject.org) (gcc version 4.6.0 20110428 (Red Hat 4.6.0-6) (GCC) ) #1
SMP Tue May 10 13:14:43 UTC 2011
but it hangs soon thereafter
[ 0.374375] Switching to clocksource kvm-clock
[ 0.376705] Switched to NOHz mode on CPU #0
and no /var/crash data gets made.
In any case, this looks like more of a kernel bug rather than kexec-tools. I am pretty sure kdump for kvm guest was working in upstream before, so we can bisect a little bit to find out where this regression was introduced.
Further testing indicates that changing to ... crashkernel=128m@128m ...
makes the kdump process work more of the time (but still not 100%).
Frank, this was reported against 2.6.39, which is fairly old by now. Are you still having kdump issues on that machine with the 3.2 or 3.3-rc3/rc4 kernels?
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.
(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)
More information and reason for this action is here: