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: Sat, 29 Jul 2006 12:25:41 -0600	[thread overview]
Message-ID: <44CBA825.3080609@shaw.ca> (raw)
In-Reply-To: <1154143992.635239.225440@p79g2000cwp.googlegroups.com>

iforone wrote:
>> 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..
> 
> Agreed -- I _was_ going to inquire about XP x64 versions, and PAE also,
> and I've read a bit about it (as microshaft has written on it's site),
> but not in quite a while. I recall the semi-related  NoExec (NX) bit
> stuff (though I forgot the mnemonic difference between AMD64 and Intel
> concerning this "bit", which if set disallows execution of any code
> above the 4GB boundary, IIRC).
> 
> to follow-up: Do the XP x64 versions do something else artificially to
> enable addressing up to 16GB of RAM or thereabouts. Or - is it that PAE
> (Physical Address Extensions) stuff again that allows or it?

PAE is what allows an OS in 32-bit mode to access memory located above 
4GB in the address space. On a 64-bit OS the CPU can access all the 
memory directly so PAE is not needed or possible. Also, PAE is often 
enabled on 32-bit systems even with less than 4GB of RAM as it allows 
using the hardware NX bit, which was only added to the PAE versions of 
the 32-bit page tables.

That's a separate issue, though, from the original subject of the thread 
(memory being mapped over by IO space), and from the artificial limit on 
accessing memory above 4GB in at least 32-bit consumer Windows.

> 
> More importantly -- I have (an as-yet-to-be-assembled system) : AMD64
> s754 3000+ with a crappy mATX mobo here (VIA KTm800/8237) Chipset --
> The RAM limit is 2GB total (2 x 1GB DIMM slots only). Do you think this
> el-cheapo mobo would have problems accessing over 4GB *if* the Mobo was
> designed for 4GB ?? IOW-- a Mobo perhaps such as General S uses (MSI,
> ASUStek, etc) -- or do you know if there's something different between
> the s754 and s939 models that I'm unaware of (besides the No Dual
> Channel RAM in s754, since it's only 64bit Single-Channel capable, not
> 128bit).

I don't think most S754 boards support physically installing that much 
RAM, so it may be moot. If you could, you could likely access memory 
above 4GB, though I'm not certain if the S754 CPUs support the memory 
hole remapping to avoid some of that RAM being lost.

> Thanks for the continuing discussion -- I'm glad I didn't follow Intel
> recently and become deceived again - as I'm sure MANY have -- you'd
> think buying a spanking new Pentium-D (8xx) and a 'decent' Intel
> Desktop mobo would allow access to more than 4GB RAM ...but no.... :-(
> (especially when the specs for the mobo claim "4GB" - heck - might as
> well remove 1 x 1GB DIMM, you'd only lose 200MB (yikes)).

Yeah, there is not much point in installing more than 3GB in such a board..

-- 
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 18:25 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
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 [this message]

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=44CBA825.3080609@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