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-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <465EDB4F.6020800@shaw.ca>
Date:	Thu, 31 May 2007 08:27:27 -0600
From:	Robert Hancock <hancockr@...w.ca>
To:	Justin Piszcz <jpiszcz@...idpixels.com>
Cc:	Parag Warudkar <parag.warudkar@...il.com>,
	linux-kernel@...r.kernel.org, crmotherboard@...el.com
Subject: Re: Case: 7454422: Re: Kernel 2.6.21.3 does not work with 8GB of RAM
 on Intel 965WH motherboards. (FULL DMESG)

Justin Piszcz wrote:
> On Thu, 31 May 2007, Parag Warudkar wrote:
> 
>> Robert Hancock wrote:
>>> I think that mem=8832M would work as well, to make the kernel use 
>>> only the memory that is marked cacheable. (It looks like this 
>>> parameter takes the highest memory address we want the kernel to use, 
>>> not the highest memory amount.)
>>>
>> Yep, and that would be much easier too.
>>
>> I am curious though as this seems to be somewhat common a problem, 
>> could we make the kernel analyze which memory is not cacheable (it 
>> already knows this via MTRR) and not use that portion for anything? 
>> Plus may be warn the user to contact their BIOS vendor to correct the 
>> problem?
>>
>> I think that would be possible - even if the kernel knows late that 
>> the memory was uncached we could migrate those pages in that region to 
>> someplace else?
>>
>> Parag
>>
> 
> That is an excellent question and I wonder the same thing.  I also had 
> this problem when I only used 4GB of ram and upgraded the (another 
> motherboard, I have two) past version 1666P and I had no idea what was 
> going on other than the BIOS did not work correctly.
> 
> In this case however it worked with 4GB with bios version 1612P but not 
> with 8GB.  Is this the case of a buggy BIOS for the 965 chipset or do 
> Intel boards have a lot of issues?

We could conceivably generate a warning if the MTRRs don't map all of 
the physical memory as write-back. Actually, conceivably we could 
actually go and fix up the MTRRs if we found them to be wrong according 
to the E820 memory map. That would be more complicated, however.

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