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>

1 files changed, 4 insertions, 1 deletions

diff --git a/kexec/arch/x86_64/crashdump-x86_64.c b/kexec/arch/x86_64/crashdump-x86_64.c
index 7831cf2..787ede6 100644
--- a/kexec/arch/x86_64/crashdump-x86_64.c
+++ b/kexec/arch/x86_64/crashdump-x86_64.c
@@ -113,6 +113,8 @@ static int get_crash_memory_ranges(struct memory_range **range, int *ranges)
 			 * initializing acpi tables in second kernel.
 			 */
 			type = RANGE_ACPI;
+		} else if(memcmp(str,"ACPI Non-volatile Storage\n",26) == 0 ) {
+			type = RANGE_ACPI_NVS;
 		} else {
 			continue;
 		}
@@ -760,7 +762,8 @@ int load_crashdump_segments(struct kexec_info *info, char* mod_cmdline,
 	/* Inform second kernel about the presence of ACPI tables. */
 	for (i = 0; i < CRASH_MAX_MEMORY_RANGES; i++) {
 		unsigned long start, end;
-		if (mem_range[i].type != RANGE_ACPI)
+		if ( !( mem_range[i].type == RANGE_ACPI
+			|| mem_range[i].type == RANGE_ACPI_NVS) )
 			continue;
 		start = mem_range[i].start;
 		end = mem_range[i].end;