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]
Date:	Thu, 31 May 2007 14:44:07 -0400 (EDT)
From:	Justin Piszcz <jpiszcz@...idpixels.com>
To:	Robert Hancock <hancockr@...w.ca>
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)



On Thu, 31 May 2007, Robert Hancock wrote:

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

Intel is working on a work-around/fix for this problem, they said I need 
to wait another day or so until it is completed.  I will let everyone know 
what the outcome is, hopefully it is a good fix :)  I totally agree 
however, a lot of 'weird' problems that some people may attribute to Linux 
are actually BIOS problems, I think warnings in the kernel would be a good 
idea, then they would not have to blame the kernel for BIOS issues :)

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