Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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.
(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.