diff options
author | Benjamin Romer <benjamin.romer@unisys.com> | 2006-07-27 11:27:46 -0600 |
---|---|---|
committer | Eric W. Biederman <ebiederm@xmission.com> | 2006-07-27 11:27:46 -0600 |
commit | a59caf2ae4f2027c3644551b03d5474d4d634ec5 (patch) | |
tree | 28ef44533c54f3f4009d7545e39bf25d7f993781 /kexec/kexec-sha256.h | |
parent | 5f85389b619197d1274d8391ca9377384c85ef13 (diff) |
fix ACPI NVS reservation
I'd like to submit a patch to kexec that addresses a serious problem
with kdump on the Unisys ES7000/600 system. We initially encountered
this issue on SUSE's SLES 10 beta distributions.
On the ES7000/600, the ACPI data is located in the 3GB range, and above
that is an ACPI NVS region. The problem is that kexec, when loading a
dump kernel, does not include the ACPI NVS region in the memory map it
provides to the dump kernel. This causes a kernel panic early in the
dump kernel's boot process:
Bootdata ok (command line is root=/dev/sda2 showopts console=tty0
console=ttyS0,115200n8 earlyprintk=serial,ttyS0,115200n8 memmap=exactmap
memmap=640K@0K memmap=3296K@16384K memmap=61599K@20321K
elfcorehdr=20320K memmap=408K#3144128K)
Linux version 2.6.16.14-6-kdump (geeko@buildhost) (gcc version 4.1.0
(SUSE Linux)) #1 Tue May 9 12:09:06 UTC 2006
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000100 - 000000000009e400 (usable)
BIOS-e820: 000000000009e400 - 00000000000a0000 (reserved)
BIOS-e820: 0000000000100000 - 00000000bfe70000 (usable)
BIOS-e820: 00000000bfe70000 - 00000000bfed6000 (ACPI data)
BIOS-e820: 00000000bfed6000 - 00000000bff00000 (ACPI NVS)
BIOS-e820: 00000000bff00000 - 00000000e8000000 (usable)
BIOS-e820: 00000000f8000000 - 00000000fec00000 (reserved)
BIOS-e820: 00000000fffc0000 - 0000000100000000 (reserved)
BIOS-e820: 0000000100000000 - 0000000810000000 (usable)
user-defined physical RAM map:
user: 0000000000000000 - 00000000000a0000 (usable)
user: 0000000001000000 - 0000000001338000 (usable)
user: 00000000013d8400 - 0000000005000000 (usable)
user: 00000000bfe70000 - 00000000bfed6000 (ACPI data)
kernel direct mapping tables up to bfed6000 @ 8000-8000
PANIC: early exception rip 10 error ffffffff8131433b cr2 2b0ed2682180
Call Trace: <ffffffff8131433b>{reserve_bootmem_core+78}
<ffffffff81312b52>{reserve_bootmem_generic+19}
<ffffffff81310ea7>{smp_scan_config+145}
<ffffffff81310f02>{find_intel_smp+54}
<ffffffff8130b6af>{setup_arch+2158}
<ffffffff813045de>{start_kernel+42} <ffffffff81304259>{_sinittext
+601}
RIP 0x10
We have determined that the cause of this panic is that the kernel
attempts to reserve the ACPI NVS region, which is defined by a pointer
stored in the ACPI data region, but cannot reserve memory above the
maximum usable memory limit. The kernel determines the maximum usable
memory by taking the highest address of usable memory specified in the
memory map; so it is setting the value to 0x5000000, as listed in the
map, then attempting to reserve memory above 0xbfed6000, which triggers
a panic.
By modifying kexec to also pass the ACPI NVS region as reserved memory
in the memory map, the kernel will not panic. We have tested this on
both the ES7000/600 and a Dell server system which exhibited the same
problem and it worked on both. The attached patch file contains the
changes that we made, and applies to kexec-tools-1.101.
-- Ben
Signed-off-by: Benjamin Romer <benjamin.romer@unisys.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
Diffstat (limited to 'kexec/kexec-sha256.h')
0 files changed, 0 insertions, 0 deletions