Created attachment 67857 [details] Screenshot of the corruption. Using the xf86-video-intel driver with SNA enabled and UXA disabled results in screen corruption as shown in the attached screenshot. Moving the mouse cursor over a button in the panel temporarily restores the icon of the button. Selecting some text in a terminal often restores a part of the selected text, but only while it is selected. Using the driver with UXA enabled does not corrupt the screen. The interesting thing is that the corruption happens only if the system was powered down for some time and UXA was not enabled after that downtime. 1. Starting the X server with the intel driver with UXA enabled works fine. 2. Recompiling the driver with "--enable-sna --disable-uxa" and restarting the X server is also fine. 3. Even rebooting the system or having it powered down for a short time does not result in corruption. 4. If the system was powered down for at least some minutes, the screen gets corrupted when the X server starts. 5. Recompiling the driver with "--enable-sna --enable-uxa" and restarting the X server removes the corruption. Now, we are back at step 1. System environment: -- chipset: 00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller]) -- system architecture: i686 -- xf86-video-intel: 2.20.7, 2.20.8, 2.20.9, git 33f6f753788398efdf20cde4aa0b4ca402eee8fe (I did not test versions prior to 2.20.7) -- xserver: 1.13.0 -- mesa: mesa-9.0_pre20120918 -- libdrm: libdrm-2.4.39 -- kernel: 3.5.4, 3.6.0-rc7 -- Linux distribution: Gentoo -- Display connector: VGA
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.