From: ebiederm@xmission.com (Eric W. Biederman)
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Dave Hansen <haveblue@us.ibm.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] export e820 table on x86
Date: 22 Nov 2002 10:17:08 -0700 [thread overview]
Message-ID: <m17kf5zfqj.fsf@frodo.biederman.org> (raw)
In-Reply-To: <Pine.LNX.4.44.0211212355060.7728-100000@home.transmeta.com>
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
next prev parent reply other threads:[~2002-11-22 17:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-21 2:00 [PATCH] export e820 table on x86 Dave Hansen
2002-11-21 2:09 ` Christoph Hellwig
2002-11-21 21:01 ` Dave Hansen
2002-11-21 22:50 ` Linus Torvalds
2002-11-21 23:46 ` Dave Hansen
2002-11-22 0:04 ` Linus Torvalds
2002-11-22 0:53 ` H. Peter Anvin
2002-11-22 6:20 ` Eric W. Biederman
2002-11-22 7:50 ` Dave Hansen
2002-11-22 8:00 ` Linus Torvalds
2002-11-22 17:17 ` Eric W. Biederman [this message]
2002-11-22 22:37 ` Dave Hansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m17kf5zfqj.fsf@frodo.biederman.org \
--to=ebiederm@xmission.com \
--cc=haveblue@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.