linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Peter Hurley <peter@hurleysoftware.com>,
	"zhenzhong.duan@oracle.com" <zhenzhong.duan@oracle.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] x86: mtrr: Constrain WB MTRR to max phys mem prior to cleanup
Date: Sat, 29 Sep 2012 08:05:15 -0700	[thread overview]
Message-ID: <30701c46-a57e-49f2-9273-6f725c8463e0@email.android.com> (raw)
In-Reply-To: <20120929104611.GB14974@khazad-dum.debian.net>

PAT support are lacking only in the Pentium Pro and Pentium II.  Sorry, if you're using crap that old, you don't get to screw up the kernel for everyone else.

Henrique de Moraes Holschuh <hmh@hmh.eng.br> wrote:

>On Fri, 28 Sep 2012, H. Peter Anvin wrote:
>> On 09/28/2012 10:37 AM, Peter Hurley wrote:
>> > An interesting side note: more recent revisions of this BIOS (rev.
>A11)
>> > report one less variable MTRR (so, IA32_MTRRCAP is writable?)
>> > 
>> >>> However, the right way to fix that is to use the PAT interfaces,
>which 
>> >>> doesn't have this drawback -- then MTRR cleanup becomes entirely 
>> >>> superfluous and the problem goes away.
>> >> Do you mean disable MTRR totally here?
>> > 
>> > Well, since PAT entries marked WC override all MTRR settings,
>whatever
>> > the BIOS set the variable MTRRs to becomes irrelevant, so not
>disabled
>> > but rather ignored.
>> > 
>> 
>> The whole point is that the display stuff should not use MTRR, but
>> rather use PAT to provide WC.  Then we don't need to "clean up" the
>> BIOS-set MTRRs.
>
>What about my trusty ThinkPad T43, and other ia32 boxes that either
>lack PAT
>support, or have it blacklisted?
>
>These are exactly the boxes that will _never_ get a BIOS fix if their
>MTRRs
>are screwed up...

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.

  reply	other threads:[~2012-09-29 15:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-07 17:44 [RFC] x86: mtrr: Constrain WB MTRR to max phys mem prior to cleanup Peter Hurley
2012-09-07 18:40 ` H. Peter Anvin
2012-09-10  3:54   ` zhenzhong.duan
2012-09-28 17:37     ` Peter Hurley
2012-09-29  2:41       ` Zhenzhong Duan
2012-09-29  3:16       ` H. Peter Anvin
2012-09-29 10:46         ` Henrique de Moraes Holschuh
2012-09-29 15:05           ` H. Peter Anvin [this message]
2012-09-29 20:11             ` Henrique de Moraes Holschuh
2012-09-29 20:16               ` H. Peter Anvin
2012-09-29 20:17               ` H. Peter Anvin
2012-09-29 21:25                 ` Henrique de Moraes Holschuh
  -- strict thread matches above, loose matches on Subject: below --
2012-07-24 20:51 Peter Hurley

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=30701c46-a57e-49f2-9273-6f725c8463e0@email.android.com \
    --to=hpa@zytor.com \
    --cc=hmh@hmh.eng.br \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peter@hurleysoftware.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=zhenzhong.duan@oracle.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).