Write combining failure.
unichrome at shipmail.org
Fri Mar 18 09:24:38 PST 2005
This mail seems to have not reached the list, so I'll repost it.
Since this is a bit out of my "territory" I'd hoped for a brief
review before committing.
Thomas Hellström wrote:
> 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.
> 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
> 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.
I've posted a patch that fixes this for review on Bugzilla Bug 2750
> xorg mailing list
> xorg at lists.freedesktop.org
More information about the xorg