Bug 55455

Created attachment 67858 [details]
Xorg.0.log for SNA (corruption).

Created attachment 67859 [details]
Xorg.0.log for UXA (good).

Created attachment 67860 [details]
dmesg for SNA (corruption).

Created attachment 67861 [details]
dmesg for UXA (good).

So that I am clear...

The bug is only evident after the machine has been turned off for a long period time. The bug does not manifest by itself under normal usage.

Whilst I ponder, can you run memtest to rule out possible hw failure?

(In reply to comment #5)
> So that I am clear...
> 
> The bug is only evident after the machine has been turned off for a long
> period time. The bug does not manifest by itself under normal usage.
Yes that is correct. Furthermore, the bug only manifests if SNA is used. Using UXA is always fine. Using UXA first and then switching to SNA also works correctly all the time. The corruption shows only after the system was down for a couple of minutes (say 20 or more) and then disappears as soon as the intel driver with UXA was used once.

It looks like UXA, in contrast to SNA, is doing something to the hardware that makes it work correctly, and that something then persists until the electric charge leaks out when the system is down. I have no idea how the graphics hardware and driver are working, so you should take this more as an illustration than a fact.

> Whilst I ponder, can you run memtest to rule out possible hw failure?
Memtest reports no errors.

(In reply to comment #6)
> It looks like UXA, in contrast to SNA, is doing something to the hardware
> that makes it work correctly, and that something then persists until the
> electric charge leaks out when the system is down. I have no idea how the
> graphics hardware and driver are working, so you should take this more as an
> illustration than a fact.

More likely the converse, as compared to SNA, UXA barely tries to use the hardware. The patterns do look like a form of tiling/swizzling corruption, but since I haven't seen similar on either 845g/855gm, it could be something peculiar to 865g. Or some weird bug. :|

(In reply to comment #7)
> (In reply to comment #6)
> > It looks like UXA, in contrast to SNA, is doing something to the hardware
> > that makes it work correctly, and that something then persists until the
> > electric charge leaks out when the system is down. I have no idea how the
> > graphics hardware and driver are working, so you should take this more as an
> > illustration than a fact.
> 
> More likely the converse, as compared to SNA, UXA barely tries to use the
> hardware. The patterns do look like a form of tiling/swizzling corruption,
> but since I haven't seen similar on either 845g/855gm, it could be something
> peculiar to 865g. Or some weird bug. :|
As I said, take it as an illustration. :) But, since X is running without corruption using SNA *after* UXA was used once, at least it looks like UXA is doing something that SNA is not doing.

That does sound promising (and there are bits of code that only exist to turn off various unused bits of hw).

Ok, so if this was the case, you should be able to boot into SNA (see the corruption), switch to UXA (fix the corruption), switch back to SNA (now corruption free).

You definitely mention that doing the first two steps fixes the corruption, do you mind confirming that SNA after UXA after SNA works. :)

(In reply to comment #9)
> That does sound promising (and there are bits of code that only exist to
> turn off various unused bits of hw).
> 
> Ok, so if this was the case, you should be able to boot into SNA (see the
> corruption), switch to UXA (fix the corruption), switch back to SNA (now
> corruption free).
Correct.

> You definitely mention that doing the first two steps fixes the corruption,
> do you mind confirming that SNA after UXA after SNA works. :)
Yes, SNA after UXA after SNA works. (The weird thing is that even SNA after reboot after UXA after... works as long as the power was not off for too long.) Is there anything I can do to (help) identify the part of the hw that causes the corruption?

If you feel bored, you can can mess around in src/sna/gen2_render.c and see which paths are affected. In particular, it will be a missing hunk of code from gen2_emit_invariant()...

diff --git a/src/sna/gen2_render.c b/src/sna/gen2_render.c
index ca61bd3..d7980d4 100644
--- a/src/sna/gen2_render.c
+++ b/src/sna/gen2_render.c
@@ -503,6 +503,8 @@ static void gen2_emit_invariant(struct sna *sna)
              ENABLE_COLOR_WRITE |
              ENABLE_TEX_CACHE);
 
+       BATCH(_3DSTATE_STIPPLE);
+
        sna->render_state.gen2.need_invariant = false;
 }

commit ba1dea5e373b8d7b410c07df897acc4d11079f63
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Oct 1 11:19:41 2012 +0100

    sna/gen2: Clear STIPPLE setup before rendering with the 3D pipeline
    
    One over-zealous removal too many.
    
    Reported-by: Timo Kamph <timo@kamph.org>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55455
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Yes, your patch fixes this bug. Thank you for your effort.

However, I am afraid that it uncovered another rendering bug. I will file a report for that one once I can provide more details about it.

So fixing the stipple for you unmasked a further bug:

commit 83b8669abc7415202f9e0c764de675ffbcf45dac
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Oct 3 23:45:28 2012 +0100

    sna/gen2: Setup invariant blend arguments
    
    I thought these were completely specified via the LOAD_STATE_IMMEDIATE
    commands we used whilst seting up the render pipeline. I was wrong.
    
    Reported-by: Timo Kamph <timo@kamph.org>
    References: https://bugs.freedesktop.org/show_bug.cgi?id=55455
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

With that patch applied, the rendering bug is gone. Thank you.