public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Robert Hancock <hancockr@shaw.ca>
To: linux-kernel <linux-kernel@vger.kernel.org>
Cc: iforone <floydstestemail@yahoo.com>
Subject: Re: BIOS detects 4 GB RAM, but kernel does not
Date: Fri, 28 Jul 2006 20:04:57 -0600	[thread overview]
Message-ID: <44CAC249.1010605@shaw.ca> (raw)
In-Reply-To: <1154112339.037481.119210@p79g2000cwp.googlegroups.com>

iforone wrote:
> see why above (mostly)... That doesn't necessarily mean that some kind
> of certain 'config' doesn't need to be compiled into the kernel. Yet
> I'm not sure exactly which options are necessary, if any, nor am I sure
> you can achieve your goal using what *seems* (Robert Hancock's
> reponses) to be essentially an Intel DualCore 32bit CPU(s). I'm having
> a bit of trouble understanding (or believing) that an EM64T system
> isn't capable of seeing more than 4GB RAM (although the Mobo max for
> that Desktop mobo is 4GB) -- BUT then again, that is not a Server grade
> Mobo either -- it's a Desktop mobo (perhaps using an
> unsupporting(cheaper) Chipset(?). Yet; the BIOS detects all 4GB (which
> shoots down my chipset theory) - so maybe it's a kerenl specific issue
> (harkens back to General S's response about 2.6.15+ kernels only).
> In my earlier post, I hadn't realized you were using a 64bit kernel.

The BIOS can see that all 4GB of memory is there, but it has no way of 
moving it out of the way to make room for the PCI/PCI-E memory-mapped IO 
space, so it has to map that IO space over the RAM in that part of the 
address space, rendering it inaccessible. There's no way that the kernel 
can fix this, regardless of whether you are using 32 or 64 bit or what 
configuration options are set.

Athlon 64/Opteron CPUs have support for moving this part of the RAM 
above 4GB to allow it to be used. This is part of the CPU's on-die 
memory controller so no special chipset support is needed. On Intel 
systems this support has to be provided by the chipset, and on the 
desktop boards, it's not.

You can see what's going on from the BIOS e820 memory map that's printed 
in the dmesg output at the start of bootup. If you calculate out the 
amount of address space reported as "usable" then you will get your 
value of 3.2GB or so which is all the kernel has access to. If the 
system supported memory remapping then you would see another region 
starting at 0x0000000100000000 (4GB) which would account for this 
missing 800MB or so.

Probably the main reason Intel didn't bother including this support in 
the desktop boards is that current non-server versions of Windows (at 
least 32-bit) won't use any memory that is mapped above 4GB anyway even 
though PAE is enabled - a purely artificial limit that MS put in place 
to discourage using desktop Windows on such large memory machines..

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/


  parent reply	other threads:[~2006-07-29  2:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1153931278.034068.54630@h48g2000cwc.googlegroups.com>
2006-07-26 16:54 ` BIOS detects 4 GB RAM, but kernel does not Robert Hancock
2006-07-28 17:03   ` Jan Engelhardt
2006-07-28 17:06     ` Robert Hancock
     [not found] ` <1153933737.200164.160870@m73g2000cwd.googlegroups.com>
     [not found]   ` <1154007393.940693.259680@i42g2000cwa.googlegroups.com>
     [not found]     ` <mH3yg.16777$2u4.7977@trnddc06>
2006-07-27 19:41       ` Robert Hancock
     [not found]     ` <1154112339.037481.119210@p79g2000cwp.googlegroups.com>
2006-07-29  2:04       ` Robert Hancock [this message]
2006-07-29 22:21         ` Andi Kleen
     [not found]       ` <fa.6TLi9h8OI9J6KX0+lv+D4/CEU0U@ifi.uio.no>
     [not found]         ` <fa.adpnQx0XAWgd4+g2tR5HDa2qHDw@ifi.uio.no>
     [not found]           ` <1154145714.279248.233230@m73g2000cwd.googlegroups.com>
2006-07-29 18:12             ` Robert Hancock
     [not found]           ` <1154143992.635239.225440@p79g2000cwp.googlegroups.com>
2006-07-29 18:25             ` Robert Hancock

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=44CAC249.1010605@shaw.ca \
    --to=hancockr@shaw.ca \
    --cc=floydstestemail@yahoo.com \
    --cc=linux-kernel@vger.kernel.org \
    /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