Bug 53353

Created attachment 65399 [details]
error-state of wedged gpu

If you can reproduce the corruption whilst wedged using #define NO_HW 1, then yes I'd worry. As it stands, the GPU is performing a stray write so any memory is suspect.

I've just pushed a patch to add a debug option - I've add some more assertions based on the debug log as well, this is just a quick guess based on the error state.

Can you update and set #define NO_TILE_8x8 1 in src/sna/sna_accel.c and see if that causes the hang to go away?

The corruptions I get in wedged mode are different, no need to get nervous ;)
I'll give your new patches a try...

NO_TILE_8x8 helps - I don't get any corruption or hang with it set.

However, the added assertions don't catch the cause.

Found a couple of bugs so far in the tiled_8x8 function:

commit b33f6754a99f6d11e423d6a03739fa2c04eeed88
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Aug 10 21:59:36 2012 +0100

    sna: Add assertions to 8x8 tiled BLTs and reset BLT state afterwards
    
    Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
    References: https://bugs.freedesktop.org/show_bug.cgi?id=53353
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Judging by your error-state, that may indeed be the root cause.

Unfourtunatly I still don't hit any assertion :/

Hmm, can you try:

diff --git a/src/sna/sna_accel.c b/src/sna/sna_accel.c
index 935f1bc..5385c02 100644
--- a/src/sna/sna_accel.c
+++ b/src/sna/sna_accel.c
@@ -9414,8 +9414,8 @@ sna_poly_fill_rect_tiled_8x8_blt(DrawablePtr drawable,
        int16_t dx, dy;
        uint32_t *b;
 
-       if (NO_TILE_8x8)
-               return false;
+       if (1)
+               return true;
 
        DBG(("%s x %d [(%d, %d)+(%d, %d)...], clipped=%x\n",
             __FUNCTION__, n, r->x, r->y, r->width, r->height, clipped));

Jap, made the hang as well as the corruption go away.

Also be sure to be running with --enable-debug[=full] to enable assertions.

Just double-checked and did a clean build - however I don't hit any assertions, without that unconditional return true, should I try with it?

(In reply to comment #11)
> Just double-checked and did a clean build - however I don't hit any assertions,
> without that unconditional return true, should I try with it?

No, I was just double checking that the hang didn't go away as a side-effect of forcing a fallback at that point. Returning true instead meant we kept going as usual, just omitting the tiled_8x8 blt.

Ok, the cause isn't immediately obvious. I've check that we are rendering in function within the target pixmap, so I need to find the bit of state that isn't being reset such that the GPU is interpreting these or subsequent commands in an unexpected manner. :|

Another possibility:

commit 5d6d9231cd2003fda1c6f2dd3174014317a45704
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Aug 10 23:07:07 2012 +0100

    sna: Reset BLT state after copy-boxes

Unfourtunatly still no luck :/

Do you mind refreshing the error-state? Hopefully I've eliminated a few of the broken commands...

Third time lucky?

commit 44f848f9b2f2a2dcd9087210ea46bc4fdb63c057
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sat Aug 11 19:44:15 2012 +0100

    sna: Fix typo in computation of texel offsets for tiled 8x8 blts
    
    Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53353
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Oh boy, that was a stupid typo.

Thanks! :)