Bug 524172 - Cannot start kdump
Summary: Cannot start kdump
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: kexec-tools
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Neil Horman
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-18 08:10 UTC by Quentin Armitage
Modified: 2009-09-18 16:41 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-09-18 16:41:56 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Output from /proc/iomem (1.54 KB, text/plain)
2009-09-18 08:10 UTC, Quentin Armitage
no flags Details

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.


Note You need to log in before you can comment on or make changes to this bug.