Bug 728930

Summary: kexec fails to load crash kernel with crashkernel>=1024M
Product: Red Hat Enterprise Linux 6 Reporter: Martin Wilck <martin.wilck>
Component: kexec-toolsAssignee: Cong Wang <amwang>
Status: CLOSED DUPLICATE QA Contact: Caspar Zhang <czhang>
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.1CC: cye, gasmith, qcai, rkhan, vgoyal
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-08-09 03:35:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
sosreport none

Description Martin Wilck 2011-08-08 12:29:28 UTC 
Description of problem:
/var/log/messages:
kernel: Reserving 1024MB of memory at 896MB for crashkernel (System RAM: 67584MB)
kdump: kexec: failed to load kdump kernel

Running kexec manually:

/sbin/kexec -p '--command-line=root=UUID=7125ca0f-5146-4716-a4ec-396e3f1330bf ro rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=de-latin1-nodeadkeys rhgb quiet biosdevname=1 irqpoll maxcpus=1 reset_devices cgroup_disable=memory ' --initrd=/boot/initrd-2.6.32-131.6.1.el6.x86_64kdump.img /boot/vmlinuz-2.6.32-131.6.1.el6.x86_64

Could not find a free area of memory of 3b1000 bytes...
locate_hole failed

Version-Release number of selected component (if applicable):
kexec-tools-2.0.0-188.el6.x86_64
kernel-2.6.32-131.6.1.el6.x86_64

How reproducible:
always

Steps to Reproduce:
1. Specify crashkernel=1024M (or more) on the kernel command line
2. Boot

Actual results:
See above

Expected results:
kdump kernel successfully loaded

Additional info:
With 1024M, the kernel needs to reserve the crashkernel memory above 896M because of the initrd image located at 0x38000000.

(8 early reservations) ==> bootmem [0880000000 - 1080000000]
  #0 [0000000000 - 0000001000]   BIOS data page
  #1 [0000006000 - 0000008000]       TRAMPOLINE
  #2 [0001000000 - 0001f474e4]    TEXT DATA BSS
  #3 [003719d000 - 0037fef1a3]          RAMDISK
  #4 [000009a800 - 0000100000]    BIOS reserved
  #5 [0001f48000 - 0001f4877d]              BRK
  #6 [0000008000 - 000000a000]          PGTABLE
  #7 [0000001000 - 000000103c]        ACPI SLIT
found SMP MP-table at [ffff8800000fd9d0] fd9d0
Reserving 1024MB of memory at 896MB for crashkernel (System RAM: 67584MB)

With lower crashkernel values (tested: 512), the kernel reserves the crashkernel memory at base 32M:

Reserving 512MB of memory at 32MB for crashkernel (System RAM: 67584MB)

We have never observed the described problem in that case.
Comment 1 Martin Wilck 2011-08-08 12:33:18 UTC 
Created attachment 517197 [details]
sosreport
Comment 3 Cong Wang 2011-08-09 03:35:46 UTC 

*** This bug has been marked as a duplicate of bug 608312 ***
Comment 4 Vivek Goyal 2011-08-09 19:35:31 UTC 
Martin, why are you trying to reserve memory at 896MB? And why are you trying to reserve 1GB of RAM for second kernel?
Comment 5 Martin Wilck 2011-08-10 11:52:45 UTC 
(In reply to comment #4)
> Martin, why are you trying to reserve memory at 896MB?

I am not doing it. The kernel does it automatically when the crashkernel size exceeds some value between 512M and 1024M which I don't know exactly. The reason is probably the RAMDISK at 003719d000 which prevents 1G to be allocated at 32M. I suspect that loading the kdump kernel fails if and only if the offset is at 896 (but I can't prove it).

> And why are you trying
> to reserve 1GB of RAM for second kernel?

Well, this came in from a customer who saw that the default reservation of 128M was too small (makedumpfile was killed by the OOM killer while dumping). So the customer increased the crashkernel value, and, having no further guidance, set it to 1024M in order to be "on the safe side". That turned out to be wrong, too.