Re: Only 3.6gb of 64gb RAM recognized by 64bit squeeze



On Mon, 14 May 2012, Stan Hoeppner wrote:
On 5/13/2012 7:02 PM, Henrique de Moraes Holschuh wrote:
On Fri, 11 May 2012, Seyyed Mohtadin Hashemi wrote:
On 5/10/2012 1:16 PM, Stan Hoeppner wrote:
If this doesn't fix the issue, and memtest and other utils can see all
64GB just fine, then I'd say you're dealing with a BIOS bug.

The very top of /var/log/dmesg has the kernel debug output about the memory
map. It might well tell us very quickly who is the culprit, if the user
with the problem can post it for the best working case and the non-working
[ 0.000000] e820 update range: 00000000e0000000 - 000000101f000000
(usable) ==> (reserved)
[ 0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory,
losing 61936MB of RAM.

There you have it.

I'm not surprised I was correct WRT a BIOS bug, but I am a little
embarrassed I didn't know and suggest this would be reported in dmesg.
I admit I just don't see this very often--this being the 1st time
actually seeing this WARNING.

Well, it is the first time I've seen a BIOS screw it up so badly as to
have someone lose 61GiB of RAM over it.

Any of the latest versions of the longterm kernels (2.6.32, 3.0), or
latest 3.2 should be able to repair MTRRs properly, but you have to
compile the kernel with that option enabled. It might be already
available, but not enabled by default. In that case, this might help
you:

Yep. In vanilla 3.2.6 it's selected by default in menuconfig, and you
can't un-select it.

We _really_ need to have that enabled by default on the Debian kernels
IMO, if we don't enable it already.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx
with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx
Archive: http://lists.debian.org/20120515023008.GA6295@xxxxxxxxxxxxxxxxxxxxx