On Fri, 7 Dec 2012 22:08:13 +0100, Daniel Vetter daniel@ffwll.ch 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

On 07.12.2012, Daniel Vetter wrote:

[....]

I did a "git bisect" betweeb 3.6 and 3.7-rc8 and ended up with this. Unfortunately, git can't revert this patch on top of master, sp I have not been able to test if a revert will cure the problem.

After reading on the net that Peter (Lekensteyn) already ended up with bisecting the same patch and it didn't work for him reverting it on top of 3-7-rc4, I'm somewhat clueless..

What else can I do to help finding the cause?

Heinz

[root@wildsau linux-git]# git bisect good 6c085a728cf000ac1865d66f8c9b52935558b328 is the first bad commit commit 6c085a728cf000ac1865d66f8c9b52935558b328 Author: Chris Wilson chris@chris-wilson.co.uk Date: Mon Aug 20 11:40:46 2012 +0200

drm/i915: Track unbound pages

When dealing with a working set larger than the GATT, or even the mappable aperture when touching through the GTT, we end up with evicting objects only to rebind them at a new offset again later. Moving an object into and out of the GTT requires clflushing the pages, thus causing a double-clflush penalty for rebinding.

To avoid having to clflush on rebinding, we can track the pages as they are evicted from the GTT and only relinquish those pages on memory pressure.

As usual, if it were not for the handling of out-of-memory condition and having to manually shrink our own bo caches, it would be a net reduction of code. Alas.

Note: The patch also contains a few changes to the last-hope evict_everything logic in i916_gem_execbuffer.c - we no longer try to only evict the purgeable stuff in a first try (since that's superflous and only helps in OOM corner-cases, not fragmented-gtt trashing situations).

Also, the extraction of the get_pages retry loop from bind_to_gtt (and other callsites) to get_pages should imo have been a separate patch.

v2: Ditch the newly added put_pages (for unbound objects only) in i915_gem_reset. A quick irc discussion hasn't revealed any important reason for this, so if we need this, I'd like to have a git blame'able explanation for it.

v3: Undo the s/drm_malloc_ab/kmalloc/ in get_pages that Chris noticed.

Signed-off-by: Chris Wilson chris@chris-wilson.co.uk [danvet: Split out code movements and rant a bit in the commit message with a few Notes. Done v2] Signed-off-by: Daniel Vetter daniel.vetter@ffwll.ch

:040000 040000 c4f02e0d05a570d0baf9d2f19a6c276c06a55142 df93a56308637e3840353c3c9425ec96c3422dcc M drivers [root@wildsau linux-git]#