Re: [RFC Patch] use MTRR for write combining if PAT is not available

[Robert Hancock <hancockrwd@gmail.com>]

On 10/11/2009 02:19 PM, Henrique de Moraes Holschuh wrote:
> On Sun, 11 Oct 2009, Arjan van de Ven wrote:
>> Henrique de Moraes Holschuh wrote:
>>> On Fri, 09 Oct 2009, Arjan van de Ven wrote:
>>>>> I've found a problem with X.org not setting up MTRR for the
>>>>> framebuffer memory. After I investigated I think this is not a
>>>>> X.org problem, but a kernel issue.
>>>> is there any CPU left that does not support PAT ?
>>>
>>> A few million of them.  Like every Centrino laptop out there, unless the
>>> kernel blacklist for PAT on Intel CPUs is wrong.
>>
>> afaik it is extremely conservative right now. FAR too much so.
>
> That *still* means we need the patch in this thread.

I don't know that it is too conservative - the erratum which justifies 
the disablement (Core Solo/Duo erratum AE7, Pentium M erratum Y31, 
likely other IDs for it too) states that "A page whose PAT memory type 
is USWC while the relevant MTRR memory type is UC, the consolidated 
memory type may be treated as UC (rather than WC as specified in IA-32 
Intel® Architecture Software Developer's Manual). When this erratum 
occurs, the memory page may be as UC (rather than WC). This may have a 
negative performance impact." This is exactly the case being discussed 
here with the framebuffer which we're trying to set as WC with existing 
MTRRs set (or defaulting to) UC. This not only affects Pentium M but 
also the original Core Solo and Core Duo CPUs which surely is millions 
of existing laptops. It seems pretty clear-cut and there's no workaround 
identified, so I think we do indeed need a patch like this one.