Comment 53 for bug 541511

(In reply to comment #51)
> Created an attachment (id=34506) [details]
> dmesg of failure with v6 patch + gtt/cpu readback info
>
An excerpt from the above file:

[ 85.216591] i8xx chipset flush failed, expected: 5031, gtt_read: 5029
[ 85.216771] gtt readback: 5029, cpu reaback: 5029
[ 85.231559] chipset flush timed out, gtt_read: 5031, cpu_read: 5031, expected: 5032, gtt_pos :2421, cpu_pos: 0
[ 85.231854] gtt readback: 5031, cpu reaback: 5031
[ 113.151457] gtt readback: 20845, cpu reaback: 20845
[ 116.806192] gtt readback: 23135, cpu reaback: 23135

I'd say it's the second case, and narrowing down the cause seems scary. Some notes regarding patch v6:

1) there are some lags (even mouse cursor hiccups), this might be normal
2) the ability to switch to VT when system fatally crashes (e.g. video failure or other program failure, with hangcheck error or Xorg I/O errors) is gone
3) if I don't open glxgears and just use thunderbird, firefox and XFCE normally, no flush failures are ever reported in dmesg. Otherwise if I open glxgears and play with it a bit, I get the 2 failures (getting more is more difficult but indeed possible as shown before)

Regarding (2): drm and i915 modules are loaded automatically by Xorg and not loaded during kernel boot-up. I might try compiling drm+i915 as built-in, and perhaps this will fix the weird GTT corruption I am experiencing.

So it happens that after quite a while of normal usage I look at dmesg and I find no failure; in this status I have to expect a sudden (unrecoverable) crash from time to time, which requires hard shutdown, and that has almost become my usual way of closing the session (50% crashes, 50% normal I'd say).