From: Jesse Barnes <jesse.barnes@intel.com>
To: Justin Piszcz <jpiszcz@lucidpixels.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
Andi Kleen <andi@firstfloor.org>,
linux-kernel@vger.kernel.org
Subject: Re: Intel's response Linux/MTRR/8GB Memory Support / Why doesn't the kernel realize the BIOS has problems and re-map appropriately?
Date: Mon, 4 Jun 2007 12:17:39 -0700 [thread overview]
Message-ID: <200706041217.39246.jesse.barnes@intel.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0706041420100.25811@p34.internal.lan>
On Monday, June 4, 2007 11:22 am Justin Piszcz wrote:
> On Mon, 4 Jun 2007, Eric W. Biederman wrote:
> > Jesse Barnes <jbarnes@virtuousgeek.org> 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.
That's a separate issue from the MTRR mapping though. Regardless of the
fact that the system needs some address space in its 8GB range reserved
for I/O devices, the BIOS should properly setup the MTRRs to map all of
*available* RAM. So the person handling your bug report may have been
confused into thinking that you were describing the former problem.
Jesse
next prev parent reply other threads:[~2007-06-04 19:18 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-01 18:14 Intel's response Linux/MTRR/8GB Memory Support / Why doesn't the kernel realize the BIOS has problems and re-map appropriately? Justin Piszcz
2007-06-01 19:10 ` Jesse Barnes
2007-06-01 19:17 ` Justin Piszcz
2007-06-01 19:19 ` Justin Piszcz
2007-06-01 19:21 ` Jesse Barnes
2007-06-01 21:14 ` Andi Kleen
2007-06-01 20:19 ` Justin Piszcz
2007-06-01 20:24 ` Andi Kleen
2007-06-01 20:26 ` Justin Piszcz
2007-06-01 21:07 ` Jesse Barnes
2007-06-01 21:19 ` Andi Kleen
2007-06-01 21:35 ` Jesse Barnes
2007-06-01 21:41 ` Jesse Barnes
2007-06-02 1:05 ` Venki Pallipadi
2007-06-02 1:15 ` Jesse Barnes
2007-06-02 8:43 ` Justin Piszcz
2007-06-02 9:22 ` Andi Kleen
2007-06-02 20:11 ` Justin Piszcz
2007-06-03 9:15 ` Matt Keenan
2007-06-04 15:40 ` Jesse Barnes
2007-06-04 15:48 ` Ray Lee
2007-06-04 15:49 ` Justin Piszcz
2007-06-04 16:01 ` Ray Lee
2007-06-04 15:54 ` Jesse Barnes
2007-06-04 18:24 ` Andi Kleen
2007-06-04 18:13 ` Eric W. Biederman
2007-06-04 18:22 ` Justin Piszcz
2007-06-04 19:08 ` Justin Piszcz
2007-06-04 19:17 ` Jesse Barnes [this message]
2007-06-04 19:18 ` Alan Cox
2007-06-04 21:01 ` Eric W. Biederman
2007-06-05 0:59 ` Yinghai Lu
2007-06-05 1:38 ` Eric W. Biederman
2007-06-05 9:46 ` Andi Kleen
2007-06-05 13:18 ` Justin Piszcz
2007-06-05 17:20 ` Jesse Barnes
2007-06-07 8:47 ` Andi Kleen
2007-06-04 19:23 ` Andi Kleen
2007-06-04 19:24 ` Intel's response Linux/MTRR/8GB Memory Support / Why doesn't the kernel realize the BIOS has problems and re-map appropriately? II Andi Kleen
2007-06-05 0:54 ` Intel's response Linux/MTRR/8GB Memory Support / Why doesn't the kernel realize the BIOS has problems and re-map appropriately? Yinghai Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200706041217.39246.jesse.barnes@intel.com \
--to=jesse.barnes@intel.com \
--cc=andi@firstfloor.org \
--cc=ebiederm@xmission.com \
--cc=jpiszcz@lucidpixels.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.