On Tue, May 15, 2012 at 8:51 PM, Stan Hoeppner <s...@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 < > h...@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.
