Eric W. Biederman wrote:
quoted text
>> but Andi and Eric said resetting mtrr is not good... when someone from
>> intel try to trim the MTRR for intel CPU.
> 
> There are a couple issues with changing the MTRR configuration.
> - You may not have perfect information on the cpu, the AMD revF is a good
>   example.
> - Code in SMM mode may actually depend on the current mtrr configuration.
> - The BIOS's need to fixed to setup MTRRs properly.

Well the BIOS is definitely doing it wrong here. As I mentioned before, it was 
setting up
	0-0x100000000 WB
	0xc0000000 - 0x100000000 UC
	0xc0000000 - 0xd0000000 WC

But the Intel Architecture Software Developer's Manual states that whenever 
any variable MTRR range overlaps with an UC MTRR range, the range remains UC. 
(Section 9.12.2.3). So in fact what I needed to set was
	0-2GB WB
	2-3GB WB
	3-3.25GB WC
and delete the 3-4GB UC range to get the behavior that the BIOS seems to have 
been intending to set up. (Relying on the default of UC for the unspecified 
ranges.)

quoted text
> So the sanest approach appears to be.
> - In linux only use ram that is mapped by a write-back mtrr.
>   This preserves performance and is always safe.
> - If you need write-combining set it up in the page tables with PAT.
> 
> There is some difficulty there but software can always do those things
> safely.

Hm. Section 9.5.1 of the doc (table 9-5) says that anything marked UC is 
always UC regardless of the bits in the page table. So with the MTRR setup 
that the BIOS left me with, this is still a no-go. There's no way to get the 
desired effect without completely reinitializing the MTRRs.

Of course, this isn't the only problem with these Asus BIOSs...
-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/