Here I want to report a summary of the triage I did to very bizarre bug.
It mostly affects suspend while 3D application is running (compiz).
I won't make a claim that this can happen without it, but I did saw that few times.
It could be that compiz was running before and corruption just surfaced.

The bug can be reproduced without suspend by triggering the eviction of video ram
(a call to ttm_bo_evict_mm(&dev_priv->ttm.bdev, TTM_PL_VRAM); )

Next time I use nouveau, I will attach the pictures of typical corruptions.

When the most severe corruption happens, I see that in kernel log:

[25831.672535] [drm] nouveau 0000:01:00.0: PGRAPH_TRAP - Ch 5/7 Class 0x8297 Mthd 0x15e0 Data 0x00000000:0x00000000
[25831.672563] [drm] nouveau 0000:01:00.0: PGRAPH_TRAP_MP_EXEC - TP 0 MP 0: INVALID_OPCODE at 000004 warp 0, opcode 3ab15cac 00000000
[25831.704343] [drm] nouveau 0000:01:00.0: PGRAPH_TRAP - Ch 5/7 Class 0x8297 Mthd 0x1a1c Data 0x00001111:0x00001111
[25831.704374] [drm] nouveau 0000:01:00.0: PGRAPH_TRAP_MP_EXEC - TP 0 MP 0: INVALID_OPCODE at 000004 warp 0, opcode 3ab15cac 00000000
[25831.706436] [drm] nouveau 0000:01:00.0: PGRAPH_TRAP - Ch 5/7 Class 0x8297 Mthd 0x1a1c Data 0x00001111:0x00001111
[25831.706458] [drm] nouveau 0000:01:00.0: PGRAPH_TRAP_MP - TP0: Unhandled ustatus 0x00020000


Note that 'opcode 3ab15cac 00000000' isn't random, that is always the bad optcode executed.


While I did the debugging, I ruled out the following possibilities:

1. Lack of TIC flush if texture state didn't change (but textures could have been moved)

2. Move of buffers while draw operation happens. It looks like on every pushbuffer, card emits relocs for all active buffers and that also marks them as used by adding a fence.

3. Move of buffers while card isn't idle (mostly as above, but I added another wait for idle before eviction, and kept the one that after)

4. GPU assisted memory moves. I commented out the code that does that, thus made it always revert to software copy.


So thats all.