On Mon, Aug 25, 2008 at 7:19 AM, Vivek Goyal <vgoyal@redhat.com> wrote:
quoted text
> On Sun, Aug 24, 2008 at 03:44:57PM -0700, Yinghai Lu wrote:
>> may need user to have new kexec tools that could create e820 table
>> from /sys/firmware/memmap instead of /proc/iomem for second kernel
>>
>> Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
>> Cc: Bernhard Walle <bwalle@suse.de>
>> Cc: Vivek Goyal <vgoyal@redhat.com>
>> Cc: "Eric W. Biederman" <ebiederm@xmission.com>
>>
>> Index: linux-2.6/arch/x86/kernel/e820.c
>> ===================================================================
>> --- linux-2.6.orig/arch/x86/kernel/e820.c
>> +++ linux-2.6/arch/x86/kernel/e820.c
>> @@ -1279,6 +1279,10 @@ void __init e820_reserve_resources(void)
>>
>>       res = alloc_bootmem_low(sizeof(struct resource) * e820.nr_map);
>>       for (i = 0; i < e820.nr_map; i++) {
>> +             if (e820.map[i].type != E820_RAM) {
>> +                     res++;
>> +                     continue;
>> +             }
>>               end = e820.map[i].addr + e820.map[i].size - 1;
>>  #ifndef CONFIG_RESOURCES_64BIT
>>               if (end > 0x100000000ULL) {
>
> I think this will wipe out ACPI related entries also from /proc/iomem
> and kdump will be broken as second kernel needs to know about the ACPI
> areas.
>
> Though, if all these entries are available in /sys/firmware/memap then
> probably one can modify kexec-tools to grep RAM entries from /proc/iomem and
> rest of the entries from /sys/firmware/memmap.

/sys/firmware/memmap have all of them. though RAM entries from
/proc/iomem could be smaller than that in /sys/firmware/memmap because
of trimming from commandline.

YH
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/