lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 28 Jul 2006 20:04:57 -0600
From:	Robert Hancock <hancockr@...w.ca>
To:	linux-kernel <linux-kernel@...r.kernel.org>
Cc:	iforone <floydstestemail@...oo.com>
Subject: Re: BIOS detects 4 GB RAM, but kernel does not

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@...pamshaw.ca
Home Page: http://www.roberthancock.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ