linux-kernel - Re: Case: 7454422: Re: Kernel 2.6.21.3 does not work with 8GB of RAM on Intel 965WH motherboards. (FULL DMESG)

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 08:49:40 -0400
From:	Parag Warudkar <parag.warudkar@...il.com>
To:	Robert Hancock <hancockr@...w.ca>
CC:	jpiszcz@...idpixels.com, linux-kernel@...r.kernel.org
Subject: Re: Case: 7454422: Re: Kernel 2.6.21.3 does not work with 8GB of
 RAM on Intel 965WH motherboards. (FULL DMESG)

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