Comment 148 for bug 541511

(In reply to comment #123)
> This is just with the kernel changed, right? Because 2.11 has taken a
> rather severe hit against 2.10 for i8xx chipsets on some workloads (I'm
> working on fixing it).

Yes, all userspace is unchanged since I switched to 2.11 and newer libdrm.

I didn't notice any regressions with 2.11 compared to 2.10 though, but I'm
only using 2D with xcompmgr -a running.

> Depends. It's definitely just a failed chipset flush (I've checked the
> offset). But given enough time and testers, this is somewhat expected
> because this patch just implements a probabilistic chipset flush. Tallying
> all the chipset flushes of all testers easily gives on the order of 100mm
> successful ones. Now if yours is the only one that failed, that's not a
> problem. Please keep an eye on this and report any reoccurences - some
> more tuning might be called for (perhaps even a module parameter).

Well, it's curious I never got it with the v7 patch, while I ran that one for days.

A module parameter to dis/enable this canary stuff would be good, it just seems to slow things down for me without improving anything.

I wonder if it's in any way significant that the difference between the expected 827 and cpu_read 315 is precisely 512... Did anyone try to increase I830_MCH_WRITE_BUFFER_SIZE to something bigger?

Looking at the commit, especially the description, it seems like there's no way to do proper chipset flushes. Maybe hunt down and confront an Intel developer? Or avoid the need to do flushes, but that's probably unrealistic. On the other hand, if you can't really flush, you can't really depend on it either.

> Also please report if the glyph corruptions show up again.

I will.

Okay, while writing this I got a second warning:

i8xx chipset flush failed, expected: 4043, cpu_read: 3531

The difference is again exactly 512.

Maybe the chipset flushing is fine, but there's a different bug making it seem to fail?