On Mon, 4 Jun 2007, Justin Piszcz wrote:
On Mon, 4 Jun 2007, Eric W. Biederman wrote:
Jesse Barnes <[email protected]> writes:
On Friday, June 1, 2007 2:19:43 Andi Kleen wrote:
And normally the MTRRs win, don't they (if I remember the table
correctly)
So if the MTRR says UC and PAT disagrees it might not actually help
I just checked, yes the MTRRs win for UC types. But it sounds like the
cases
we're talking about are actually situations where there's no MTRR
coverage,
so the default type is used. The manual doesn't specifically call out how
memory using the default type interacts with PAT, but it may well be that
it
stays uncached if the default type is uncached. Again that argues for
fixing
the MTRR mapping problem in some way.
Last I looked PAT can only demote not promote the type of a page,
except for the specific exception of UC to WC.
Normally the default type is UC so putting a pat type of WB won't
help anything. I may have missed some subtle detail but I remember
looking into this in some detail a while ago and coming to that
conclusion.
It is the BIOS's responsibility to mark all usable memory as WB,
using the MTRRs. If it doesn't it is a BIOS bug.
Eric
According to Intel it is not a BIOS bug but rather the media controller
hub (MCH) uses memory for various purposes, outlined in their doc:
From their response, it sounds like the kernel needs to setup the memory
properly to deal with the MCH found in the 965 motherboards?
From their e-mail:
Note before continuing: Debian* Linux Operating System is not an officially,
validated, tested Operating System for the Intel(R) Desktop Board DG965WH
(see http://downloadcenter.intel.com/Product_Filter.aspx?ProductID=2375);
moreover, we do confirm that "on a system that has 8 GB of system memory
installed, it is not possible to use all of the installed memory due to
system address space being allocated for other system critical functions."
[qtd. on page 43 of the Technical Product Specification (see
http://download.intel.com/design/motherbd/wh/D5600801US.pdf)]. Thus, the
following suggestions are provided AS IS; we cannot guarantee the problem
would be fixed afterwards:
Therefore, they are NOT going to fix their BIOS-- and I have already received
an e-mail from one or two people who are experiencing this problem, I presume
it will only get worse.
Justin.
Therefore, since they will NOT commit to a BIOS fix (they claim not a BIOS
issue) what options does that leave us with?
Justin.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]