Messages in this thread | | | Subject | Re: [PATCH] export e820 table on x86 | From | (Eric W. Biederman) | Date | 22 Nov 2002 10:17:08 -0700 |
| |
Linus Torvalds <torvalds@transmeta.com> writes:
> On Thu, 21 Nov 2002, Dave Hansen wrote: > > > > BIOS-e820: 0000000000000000 - 000000000009dc00 (usable) > > BIOS-e820: 000000000009dc00 - 00000000000a0000 (reserved) > > BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) > > BIOS-e820: 0000000000100000 - 000000003fff9380 (usable) > > BIOS-e820: 000000003fff9380 - 0000000040000000 (ACPI data) > > BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) > > BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) > > BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved) > > > > I added a " e820" onto the end of each of the cases in > > register_memory(). Where does the "00000000000e0000 - > > 0000000000100000 (reserved)" entry go?
Dave please don't keep the "e820" appending in the final patch.
> The kernel removes all region claims in the 0xa0000 - 0x100000 area, since > there are broken bioses that claim there is good memory there even if > there isn't.
And I have at least one system that actually has useable memory there. But it is running LinuxBIOS which makes that an entirely different problem is this regard.
> > I wonder if it is vital to the next boot... > > Nope, the next boot would also just remove it..
To be clear all that is really critical is getting the entries marked System RAM/(useable). The kernel really does not use the rest. And while it may be nice to do better, it is not necessary.
As a first pass, all that is needed is we come close enough to the true amount of ram that peoples machines don't become unuseable, and that repeated invocations don't make the situation worse.
The kernel is an abstraction layer, and the BIOS is an abstraction layer. I don't expect to exactly, or trivially replicate what the BIOS reports with the kernels abstraction layer. Instead I intend to do well enough, so the loaded kernel is useable. Eventually it may be worth letting the kernel know this information came from another kernel and not the BIOS. But we don't need that currently.
Eric - 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/
| |