On Fri, 7 Dec 2012 22:08:13 +0100, Daniel Vetter <daniel@xxxxxxxx> wrote: > ilk with rc6 disabled, and the two hangs you've attached both die on > the MI_FLUSH in between a 3D primitive and a 2D blit, like all the > other non-rc6 hangs we've seen thus far that indicate that 3.7 > regressed. This A looks _very_ good. I'm adding lists again so that > people are updated and can check whether I've analyzed the > error_states correctly. For reference I've uploaded your dmesg and > error_states at The error states do disappear into a black hole during the execution of a 3DPRIMITIVE. The similarity between the two appear that the WM kernel loaded for the 3DPRIMITIVE both appear to be recently bound, and were the last kernels to be bound in the batch. Coincidence? Maybe, the INSTDONE in both cases is again the same highly unusual condition suggesting that the EU died. However, both error-states also suggest that a fresh surface was uploaded for the same 3DPRIMITIVE - but I'm having to guess since the error-state doesn't include the auxiliary state for me to check. One thing you can try is SNA, which packs its batches differently with the advantage that more auxiliary state is included in the error-state. It also packs all the kernels into a single buffer which will reduce the frequency at which it is paged out/in. So if you can reproduce with SNA (use Option "AccelMethod" "SNA" in a device section of your xorg.conf snippet) I expect the error-state to be quite different and hopefully shed some more light on the issue. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
