MTRR setting failure

[Felix Kühling]

Am Mittwoch, den 16.03.2005, 09:06 +0100 schrieb Thomas Hellström:
> Hi!
> 
> It seems that the linux MTRR setting code both in Xorg and in kernels 
>  >=2.6 is not doing it's job properly:
> 
> The background is that some BIOSes do not set up MTRR correctly, but 
> just sets up write-combining in a small part of the framebuffer memory. 
> When the X server tries to set it's MTRR this fails because there are 
> overlapping regions of different sizes. I've seen this in most VIA 
> bioses and also newer DELL workstations with ATI Radeons.

I can't speak for all hardware or BIOSes, but in all cases I have seen
it was the Linux frame buffer driver (even vesafb) that set up
write-combining for a part of the frame buffer (usually 8MB).

> 
> In the via/unichrome driver we have an ugly workaround which first maps 
> the framebuffer as MMIO (uncached) to get rid of any offending MTRR 
> region, then unmaps it and remaps it as write-combining.
> 
> On 2.6 series kernels, removing a wc region does sometimes not work the 
> first time it is tried. You have to give the command twice to make this 
> work. Don't know why. I never saw this in the 2.4 series.
> 
> This makes the code even more ugly, having to map framebuffer as MMIO twice.
> 
> I suggest to
> 
> 1. Change the linux X framebuffer mapping code to remove any offending 
> MTRR regions, possibly saving them for a clean exit.
> 2. Have the code double check if the removal really went through. If 
> not, do it again, repeat a limited number of times.
> 3. Maybe inplement the newer IOCTL removal instead of fprintf(mtrrfile, 
> "disable=%d\n", region); ?
> 
> Failure to properly set up MTRR can be such a performance degrador. 
> Particularly when using Xv, and the user will rarely find out the cause 
> of the slowness.
> 
> /Thomas

-- 
| Felix Kühling <fxkuehl at gmx.de>                     http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3  B152 151C 5CC1 D888 E595 |