|Summary:||Cannot start kdump|
|Product:||[Fedora] Fedora||Reporter:||Quentin Armitage <quentin>|
|Component:||kexec-tools||Assignee:||Neil Horman <nhorman>|
|Status:||CLOSED NOTABUG||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-09-18 16:41:56 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Quentin Armitage 2009-09-18 08:10:36 UTC
Created attachment 361609 [details] Output from /proc/iomem Description of problem: kdump fails to start, both at init time, and also if execute service kdump start Version-Release number of selected component (if applicable): kexec-2.0.0-27.fc12 kernel-2.6.31-23.fc12.i686 How reproducible: Always Steps to Reproduce: 1.Specify crashkernel=64M@16M in boot string 2. 3. Actual results: kdump [FAILED] output at init or if execute service kdump start Expected results: kdump runs successfully Additional info: cat /proc/cmdline shows: ro root=/dev/mapper/vg_samson_rawhid-lv_root crashkernel=64M@16M quiet vga=838 SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=uk rd_plytheme=charge lapic The problem appears to be that /proc/iomem does not have an entry for "Crash kernel" - see attachment. I have modified /etc/init.d/kdump in function load_kdump as follows: @@ -172,7 +172,7 @@ fi ARCH=`uname -m` - if [ "$ARCH" == "ppc64" ] + if [ "$ARCH" == "ppc64" -o "$ARCH" == "i686" ] then MEM_RESERVED=`grep "crashkernel=[0-9]\+[MmKkGg]@[0-9]\+[MmGgKk]" /proc/cmdline` else so that it will now execute kexec. However, kexec now outputs the message: Memory for crashkernel is not reserved Please reserve memory by passing "crashkernel=X@Y" parameter to the kernel This appears to be caused by kexec/arch/i36/crashdump-x86.c also looking at the output of /proc/iomem to find "Crash kernel" in function is_crashkernel_mem_reserved.
Comment 1 Quentin Armitage 2009-09-18 10:48:23 UTC
I have found the cause of the problem, The following is in /var/log/dmesg: (9 early reservations) ==> bootmem [0000000000 - 00373fe000] #0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000] #1 [0000001000 - 0000002000] EX TRAMPOLINE ==> [0000001000 - 0000002000] #2 [0000006000 - 0000007000] TRAMPOLINE ==> [0000006000 - 0000007000] #3 [0000400000 - 00012b55cc] TEXT DATA BSS ==> [0000400000 - 00012b55cc] #4 [000009f000 - 0000100000] BIOS reserved ==> [000009f000 - 0000100000] #5 [00012b6000 - 00012bc1a4] BRK ==> [00012b6000 - 00012bc1a4] #6 [0000007000 - 000000a000] PGTABLE ==> [0000007000 - 000000a000] #7 [00012bd000 - 0001d4eda1] NEW RAMDISK ==> [00012bd000 - 0001d4eda1] #8 [000000a000 - 0000011000] BOOTMAP ==> [000000a000 - 0000011000] crashkernel reservation failed - memory is in use If I specify crashkernel=64M@32M then it loads OK. I haven't been able to find any documentation anywhere that suggests anything other than @16M. Now I can load a crashdump kernel, I now have the problem that a panic does not cause the new kernel to load, and I just get some minor screen corruption. I will report that as a separate bug.
Comment 2 Neil Horman 2009-09-18 16:41:56 UTC
Yes, please report the panic failure as a separate bug. As for the @32M thing, that value specifies a location. Its specifically there for you to select a location to start the reservation at, so that in the event that the acddress space starting at 16M is reserved, you can select another location. Thats working as designed. Alternatively, you can just set your crashkernel value as a size (omitting the @location spec). That will cause the kernel to attempt to intellegently select an unused area of memory for you.