On 2/4/07, Andi Kleen ak@suse.de wrote:
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.
-Andi
Andi, I just reread Roman's original note. I am re-attaching it. It does seem to me that there is some problem in how linux is handling the map. Or am I missing something here? We're happy to fix any linuxbios issues, I just can't see any LinuxBIOS issues in the bug Roman describes.
From what I can see, the kernel is confused because a part of the F
segment is reserved, and a part is available as memory. Does the linux code require that a 64k segment be all one or the other? What are the rules here?
thanks
ron === Hello,
I have this situation:
Linuxbios boots an Opteron motherboard with 1GB memory.
Linuxbios directly loads a recent linux kernel. The memory layout is like this:
BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 0000000000000e18 (reserved) BIOS-e820: 0000000000000e18 - 00000000000a0000 (usable) BIOS-e820: 00000000000c0000 - 00000000000f0000 (usable) BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved) BIOS-e820: 00000000000f0400 - 0000000040000000 (usable)
The f0000-f0400 region contains IRQ and ACPI tables.
At some point the kernel builds a resource table containing all physical address ranges and type of hardware the addresses are mapped to. The table is accessible via /proc/iomem:
# cat /proc/iomem 00000000-00000e17 : reserved 00000e18-0009ffff : System RAM 000a0000-000bffff : Video RAM area 000c0000-000cbfff : Video ROM 000f0000-000fffff : System ROM e0000000-efffffff : PCI Bus #03 e0000000-efffffff : 0000:03:00.0 f0000000-f3ffffff : GART f4000000-f60fffff : PCI Bus #03 f4000000-f4ffffff : 0000:03:00.0 f5000000-f5ffffff : 0000:03:00.0 f6000000-f601ffff : 0000:03:00.0 f6100000-f6100fff : 0000:00:01.0 f6101000-f6101fff : 0000:00:02.0 f6101000-f6101fff : ohci_hcd f6102000-f6102fff : 0000:00:04.0 f6103000-f6103fff : 0000:00:07.0 f6103000-f6103fff : sata_nv f6104000-f6104fff : 0000:00:08.0 f6104000-f6104fff : sata_nv f6105000-f6105fff : 0000:00:0a.0 f6106000-f61060ff : 0000:00:02.1 f6200000-f620ffff : 0000:40:01.0
As you can see, the 00000000000f0400-0000000040000000 region is not listed.
It is not listed because the kernel unconditionally adds "000f0000-000fffff : System ROM" first (look for "request_resource(&iomem_resource, &system_rom_resource)"), and then the attempt to add f0400-40000000 range fails because of overlapping.
The kernel does not care that the range is not listed there. Kexec does. It uses the /proc/iomem file to instruct the kexec system call how to place the segments of a new kernel in the physical memory. Kexec fails to start a new kernel because it cannot locate enough physical memory.
This must be fixed either in linux or linuxbios.
Assuming that linuxbios is to be fixed, I cooked a patch which provides this memory layout:
BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 0000000000000e18 (reserved) BIOS-e820: 0000000000000e18 - 00000000000a0000 (usable) BIOS-e820: 00000000000c0000 - 00000000000f0000 (usable) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 0000000040000000 (usable)
The /proc/iomem contains:
# cat /proc/iomem 00000000-00000e17 : reserved 00000e18-0009ffff : System RAM 000a0000-000bffff : Video RAM area 000c0000-000cbfff : Video ROM 000f0000-000fffff : System ROM 00100000-3fffffff : System RAM 00100000-00203c61 : Kernel code 00203c62-00248c3f : Kernel data e0000000-efffffff : PCI Bus #03 e0000000-efffffff : 0000:03:00.0 f0000000-f3ffffff : GART f4000000-f60fffff : PCI Bus #03 f4000000-f4ffffff : 0000:03:00.0 f5000000-f5ffffff : 0000:03:00.0 f6000000-f601ffff : 0000:03:00.0 f6100000-f6100fff : 0000:00:01.0 f6101000-f6101fff : 0000:00:02.0 f6101000-f6101fff : ohci_hcd f6102000-f6102fff : 0000:00:04.0 f6103000-f6103fff : 0000:00:07.0 f6103000-f6103fff : sata_nv f6104000-f6104fff : 0000:00:08.0 f6104000-f6104fff : sata_nv f6105000-f6105fff : 0000:00:0a.0 f6106000-f61060ff : 0000:00:02.1 f6200000-f620ffff : 0000:40:01.0
Kexec is happier with the patch.