[LinuxBIOS] [PATCH] e820 table correction
Eric W. Biederman
ebiederm at xmission.com
Sun Feb 4 19:33:00 CET 2007
Andi Kleen <ak at suse.de> writes:
> On Sunday 04 February 2007 11:45, Stefan Reinauer wrote:
>> Andi Kleen wrote:
>> > On Sunday 04 February 2007 03:39, yhlu wrote:
>> >> commit dbf9272e863bf4b17ee8e3c66c26682b2061d40d
>> >> Author: Andi Kleen <ak at suse.de>
>> >> Date: Tue Sep 26 10:52:36 2006 +0200
>> >> [PATCH] Don't force reserve the 640k-1MB range
>> > Ok, but if that breaks LinuxBios then the problem is clearly in LinuxBIOS
>> > and needs to be fixed there.
>> Why? Is LinuxBIOS breaking some standard here?
> If anything between 640K and 1MB isn't memory it should report
> that properly in the e820 map.
No the problem was that the patch was incomplete. Linux is still
reserving a ROM at 0xf0000-0xfffff. Now when LinuxBIOS properly
reports that area as RAM that you can do something with, Linux ignores
it, because of the ROM reservation is reserved first. But worse
the whole range is thrown out which in this case was:
BIOS-e820: 00000000000f0400 - 0000000040000000 (usable)
So basically none of the memory below 4G is reported in /proc/iomem.
Which is painful.
When /sbin/kexec goes to regenerate the e820 map since we have huge
holes in the e820 map the whole thing falls over.
Which means we want to either delete the System ROM reservation,
perform the System ROM reservation after other reservations from
the e820 map, or improve the error handling.
I believe the following trivial patch will resolve the issue
but reserving the ROMs later.
diff --git a/arch/x86_64/kernel/setup.c b/arch/x86_64/kernel/setup.c
index af425a8..f9610b7 100644
@@ -522,8 +522,8 @@ void __init setup_arch(char **cmdline_p)
* Request address space for all standard RAM and ROM resources
* and also for regions reported as reserved by the e820.
More information about the coreboot