From: lsorense@csclub.uwaterloo.ca (Lennart Sorensen)
To: Satyam Sharma <satyam.sharma@gmail.com>
Cc: Tom Moore <tmoore@spatial.ca>, linux-kernel@vger.kernel.org
Subject: Re: 4Gb ram not showing up
Date: Thu, 7 Jun 2007 16:13:08 -0400 [thread overview]
Message-ID: <20070607201308.GC10006@csclub.uwaterloo.ca> (raw)
In-Reply-To: <a781481a0706061418m7f51dc1bke079e6e6b7d5f930@mail.gmail.com>
On Thu, Jun 07, 2007 at 02:48:50AM +0530, Satyam Sharma wrote:
> Ugh, no! How can we expect the user compiling a kernel to be *so*
> familiar with address space re-mapping / BIOSen (_his_ particular
> BIOS, specifically, and what / how it re-maps memory) / etc to be
> able to answer such questions? "Select ... if you have ... RAM
> installed" is perfectly clear, simple, and all that's needed.
>
> BTW, just imagine what a user would need to do to make things
> work as per your proposal. Build some kernel (don't care about
> memory loss), boot and find what his firmware prefers to do with
> address space (or else read up the BIOS documentation!) and
> _then_ again build a new kernel, this time selecting the options
> appropriately ...
>
> Also, note that the change you're proposing is unnecessary! As
> Andi pointed out, this issue has more to do with broken BIOSen
> and the proper fix for Tom is to contact his vendor and flash /
> upgrade the BIOS firmware. I don't see anything wrong with the
> Kconfig help texts.
Well no. If you have 4GB of ram, and a proper BIOS, then you NEED a
kernel configured for 64GB ram since PCI will take at least 0.5GB of it
and make it remapped above the 4GB address. So describing the
CONFIG_4GB option as being correct for people with 1 to 4GB ram is very
much wrong for almost all systems. It would only be correct for those
systems where the bios or chipset incorrectly does not remap memory
above the PCI address space. The current description is in fact wrong
when the bios isn't broken. Somewhere around 3 or 3.5GB seems to be the
limit for the CONFIG_4GB option. Any more and you need the CONFIG_64GB
option instead, unless your bios and/or chipset sucks in which case you
simply loose the ram in the PCI space and you might as well stick with
the CONFIG_4GB option to keep full performance.
--
Len Sorensen
next prev parent reply other threads:[~2007-06-07 20:13 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-04 15:14 Tom Moore
2007-06-04 19:10 ` Lennart Sorensen
2007-06-04 19:45 ` Tom Moore
2007-06-04 22:28 ` Wakko Warner
2007-06-05 13:12 ` Tom Moore
2007-06-05 13:37 ` Joseph Fannin
[not found] ` <46646B4C.2070707@spatial.ca>
2007-06-05 18:57 ` Lennart Sorensen
2007-06-06 21:18 ` Satyam Sharma
2007-06-07 6:58 ` Jan Engelhardt
2007-06-07 13:33 ` Tom Moore
2007-06-07 20:13 ` Lennart Sorensen [this message]
2007-06-06 11:45 ` Andi Kleen
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=20070607201308.GC10006@csclub.uwaterloo.ca \
--to=lsorense@csclub.uwaterloo.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=satyam.sharma@gmail.com \
--cc=tmoore@spatial.ca \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®