[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



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.

> 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.

.config - Linux/i386 3.2.6 Kernel Configuration
...
Saying Y here also fixes a problem with buggy SMP BIOSes which
only set the MTRRs for the boot CPU and not for the secondary CPUs.
This can lead to all sorts of problems, so it's good to say Y here.

-- 
Stan



Reply to: