Bug 215417 - kdump kernel panics early in boot
kdump kernel panics early in boot
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.0
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Red Hat Kernel Manager
Red Hat Kernel QE team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-13 16:14 EST by Amul Shah
Modified: 2009-09-09 01:02 EDT (History)
5 users (show)

See Also:
Fixed In Version: beta2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-12-22 21:37:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
This patch will avoid any attempts to reserve memory about end_pfn_map, the end of memory (1.14 KB, patch)
2006-11-13 16:14 EST, Amul Shah
no flags Details | Diff

  None (edit)
Description Amul Shah 2006-11-13 16:14:50 EST
Description of problem:
The kdump crash kernel panics when it tries to reserve the MP Config
tables on an ES7000.

The MP Config table is located above 1MB of physical memory in a
reserved memory area.  It is located outside the first 1MB area because
the tables are too large, 240k.

The crash kernel is given a user defined memory map with E820 reserved
and ACPI areas passed in by kexec tools and a usable area from 16MB
physical to 80MB physical.  This user defined map causes the top of
memory to be set as 80MB.

The ACPI tables and MP Tables reside higher in memory.  When reserving
memory with reserve_bootmem_generic, the function has a BUG panic if the
memory location to reserve is above the top of usable memory for the node.  The
MP table is above the top of memory in a user defined memory map.

Version-Release number of selected component (if applicable):
Tested with RHEL5 Beta 2 Milestone 9


How reproducible:
Always on an ES7000

Steps to Reproduce:
1. Setup for kdump with boot paramter crashkernel=64M@16M
2. Install the kernel with  kexec -p /boot/vmlinux-kdump --args-linux
--command-line="`cat /proc/cmdline` lpj=1306000
earlyprintk=serial,ttyS0,115200n8" --initrd=/boot/initrd-kdump
3. Issue alt-sysrq-c (or echo c > /proc/sysrq-trigger)
  
Actual results:
Actual kernel panic to follow

Expected results:
Kdump kernel should boot up.

Additional info:
http://www.ussg.iu.edu/hypermail/linux/kernel/0611.0/0796.html
The associated patch is currently in 2.6.19-rc5-mm1
Comment 1 Amul Shah 2006-11-13 16:14:50 EST
Created attachment 141102 [details]
This patch will avoid any attempts to reserve memory about end_pfn_map, the end of memory
Comment 2 RHEL Product and Program Management 2006-11-14 12:41:20 EST
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 3 Amul Shah 2006-11-28 13:14:28 EST
FYI, this patch has been accepted into 2.6.19-rc6
Comment 4 Don Zickus 2006-12-04 13:35:56 EST
in 2.6.18-1.2789.el5
Comment 5 Daniel W. Ottey 2006-12-05 08:53:37 EST
Is this kernel available for download & testing, or do we need to wait for the
next release?
Comment 6 RHEL Product and Program Management 2006-12-22 21:37:07 EST
A package has been built which should help the problem described in 
this bug report. This report is therefore being closed with a resolution 
of CURRENTRELEASE. You may reopen this bug report if the solution does 
not work for you.

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