Bug 728930 - kexec fails to load crash kernel with crashkernel>=1024M
Summary: kexec fails to load crash kernel with crashkernel>=1024M
Keywords:
Status: CLOSED DUPLICATE of bug 608312
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kexec-tools
Version: 6.1
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Cong Wang
QA Contact: Caspar Zhang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-08 12:29 UTC by Martin Wilck
Modified: 2013-09-30 02:26 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-08-09 03:35:46 UTC


Attachments (Terms of Use)
sosreport (2.91 MB, application/x-xz)
2011-08-08 12:33 UTC, Martin Wilck
no flags Details

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.


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