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

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



On Tue, 2012-05-15 at 21:26 +0200, Seyyed Mohtadin Hashemi wrote:
> On Tue, May 15, 2012 at 8:51 PM, Stan Hoeppner
> <stan@hardwarefreak.com> wrote:
>         On 5/15/2012 12:26 PM, Seyyed Mohtadin Hashemi wrote:
>         > On Tue, May 15, 2012 at 4:30 AM, Henrique de Moraes Holschuh
>         <hmh@debian.org
>         >> wrote:
>         >
>         >> 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
>         >>
>         >
>         > Thank you for the tips Henrique and Stan, unfortunately i
>         don't have time
>         > to build/test new kernels this week because i have to finish
>         my thesis. I
>         > will have time next week to look at it and report back the
>         results.
>         
>         
>         In that case you could simply install the latest backport
>         kernel image
>         and see if that does the trick.  Should be quick 'n painless.
>         
>         Add to /etc/apt/sources.list
>         deb http://backports.debian.org/debian-backports
>         squeeze-backports \
>         main contrib non-free
>         
>         $ aptitude update
>         $ aptitude -t squeeze-backports install
>         linux-image-3.2.0-0.bpo.1-amd64
>         $ shutdown -r now
>         
>         Should take less than 5 minutes.
>         
>         --
>         Stan
>         
> 
> Funny you should mention that, I did actually try the exact kernel you
> mentioned yesterday - it did not go well, i got kernel panic. I didn't
> do many tests because i didn't have much time, i went back to the old
> kernel, and though i'm not happy with the situation the computer at
> least works and i can use the CPU to do calculations.


Hi Stan,

I RMA'd the MB and with the replacement I received I am able to run the
3.2 kernel and all installed RAM is usable. However, I have to use
"noapic irqpoll acpi=force" boot flags.

I did have a small problem, sometimes I would get "RAM R/W test fail" at
BIOS POST. I had done extensive memtest on the DIMMs earlier so I only
tested if the individual DIMMs could POST, only one gave the "RAM R/W
test fail". After removing the faulty DIMM + a healthy DIMM the system
works smoothly.


regards,
Mohtadin


Reply to: