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/
This archive was generated by hypermail 2b29 : Sat Nov 23 2002 - 22:00:40 EST