Re: MTRR use in drivers

[Henrique de Moraes Holschuh <hmh@hmh.eng.br>]

On Sun, 23 Jun 2013, H. Peter Anvin wrote:
> On 06/23/2013 12:29 PM, Henrique de Moraes Holschuh wrote:
> > On Sun, 23 Jun 2013, H. Peter Anvin wrote:
> >> Why do you care about performance when PAT is disabled?
> > 
> > It will regress already slow boxes.  We blacklist a LOT of P4s, PMs, etc and
> > nobody ever took the pain to track down which ones of those actually have
> > PAT+MTRR aliasing bugs.
> > 
> > These boxes have boards like the Radeon X300, which needs either PAT or MTRR
> > to not become unusable...
> 
> We're talking hardware which is now many years old, but this is causing
> very serious problems on real, modern hardware.  As far as I understand
> it, too, the blacklisting was precautionary (the only bug that I
> personally know about is a performance bug, where WC would be
> incorrectly converted to UC.)

And as far as I could find from Intel's not-that-complete public
"specification updates", we are applying the errata workaround to a few more
processors than strictly required, but since I have no idea how to write a
test case, I can't whitelist the 3rd-gen Pentium M on my T43, nor can I get
ThinkPad owners to test it for us on 1st and 2nd-gen Pentium M and report
back.

> We need a way forward here.  If it is the only way I think we would have
> to sacrifice the old machines, but perhaps something can be worked out
> (e.g. if PAT is disabled, fall back to MTRRs if available for ioremap_wc()).

I'd be quite happy with a MTRR fallback.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh