Andi Kleen ak@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@suse.de Date: Tue Sep 26 10:52:36 2006 +0200
[PATCH] Don't force reserve the 640k-1MB rangeOk, 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 --- a/arch/x86_64/kernel/setup.c +++ b/arch/x86_64/kernel/setup.c @@ -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. */ - probe_roms(); e820_reserve_resources(); + probe_roms(); e820_mark_nosave_regions();
request_resource(&iomem_resource, &video_ram_resource);