MTRR setting failure
fxkuehl at gmx.de
Wed Mar 16 00:40:09 PST 2005
Am Mittwoch, den 16.03.2005, 09:06 +0100 schrieb Thomas Hellström:
> 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.
| Felix Kühling <fxkuehl at gmx.de> http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
More information about the xorg