Description of problem:
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...
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Specify crashkernel=1024M (or more) on the kernel command line
kdump kernel successfully loaded
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.
Created attachment 517197 [details]
*** This bug has been marked as a duplicate of bug 608312 ***
Martin, why are you trying to reserve memory at 896MB? And why are you trying to reserve 1GB of RAM for second kernel?
(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.