On Fri, Jun 23, 2006 at 09:17:22AM -0400, Benjamin Romer wrote:
> 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:
>
Hi,
Thanks for the patch. When I added the code for ACPI tables I was not
sure about ACPI NVS so I did not include it.
[..]
> diff -urNp -X dontdiff kexec-tools-1.101/kexec/arch/x86_64/crashdump-x86_64.c
> kexec-tools-1.101-kdump/kexec/arch/x86_64/crashdump-x86_64.c
> --- kexec-tools-1.101/kexec/arch/x86_64/crashdump-x86_64.c 09:17:05.000000000
> -0600
> +++ kexec-tools-1.101-kdump/kexec/arch/x86_64/crashdump-x86_64.c
> 06:19:51.000000000 -0600
> @@ -113,6 +113,8 @@ static int get_crash_memory_ranges(struc
> * 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;
> }
Generally ACPI data and ACPI NVS regions are contiguous. Can we put some
logic here and merge the two regions so that we pass a single
memmap=A#B entry to the second kernel.
Already kdump is adding too many command line options internally and it
is consuming a big chunk out of 256 limit. So lets avoid adding another
entry and instead merge this one with ACPI data itself if ACPI NVS is
contiguous to it.
Thanks
Vivek
_______________________________________________
fastboot mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/fastboot
