I most often trigger this in firefox, but it is also triggerable in google-chrome and I even got this once on a desktop with just xterms open. Switching to a different desktop or application window fixes the display. See the videos on http://uguu.de/~ranma/intel_kms_bugs/ This only happens when I use KMS. Unfortunately I don't have a second system I could use to ssh into the machine to get a gpu dump while the bug is manifesting itself...
I forgot to mention this: ii xserver-xorg-c 2:1.7.4-2 Xorg X server - core server ii libdrm2 2.4.17-0ubuntu Userspace interface to kernel DRM services - (II) Module intel: vendor="X.Org Foundation" compiled for 1.7.4, module version = 2.9.99 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 6.0 This is Debian/testing, with libdrm2 2.4.17 from Ubuntu lucid and xf86-video-intel compiled from git the day before yesterday, but I have been seeing this issue for about half a year now. Initially KMS worked fine, but at some point after a dist-upgrade it started acting up like this. I'm pretty sure these rendering errors and the sporadic GPU hangs started at the same time, but since I don't have a reliable way to trigger either I can't bisect it.
Since updating to the git version of xf86-video-intel I noticed a new bug: Sometimes fonts are not rendered correctly, that did not happen with the older Debian testing driver. Sometimes parts of the characters are missing, which is sometimes fixed by a redraw (most likely depends on whether it is still cached (redraw doesn't fix) or not (fixed by redraw)). Today I also upgraded libdrm from the ubuntu 2.4.17 to 2.4.17 compiled from git, but that didn't help. Now running on 2.6.33-rc6, libdrm 1802e1a4e747b5906d3af10c4a53fd457eddcbb4 and xf86-video-intel 1a76fa5574e8e8f88ac3518a4e4494e1af301dc1
I upgraded to libdrm git HEAD including the "intel: Handle resetting of input params after EINTR during SET_TILING" commit http://cgit.freedesktop.org/mesa/drm/commit/?id=4f0f871730b76730ca58209181d16725b0c40184 FWIW I just saw the text rendering bug, so that's not gone, but that's also one I got only recently. I'm still hoping the other rendering bugs are fixes by this.
(In reply to comment #3) > FWIW I just saw the text rendering bug, so that's not gone, but that's also one > I got only recently. I'm still hoping the other rendering bugs are fixes by > this. Unfortunately the other rendering bugs also still happen, possibly less frequently. And I now have the suspicion that they now only happen after I suspended the system at least once.
One particular rendering error that I see sometimes and still see with 2.6.33-rc7, libdrm 1802e1a4e747b5906d3af10c4a53fd457eddcbb4 and xf86-video-intel 1a76fa5574e8e8f88ac3518a4e4494e1af301dc1 and forgot to mention in the first post: Rarely the screens flickers for a split second. It looks like maybe the framebuffer offset is wrong for one frame, but happens to fast and to seldom to see the exact problem. I've only ever seen this with KMS, never without.
Created attachment 33407 [details] Image showing the character 'z' not rendered correctly Currently running 2.6.33-rc8, drm-git 4a17be4a86cde1065908576e44f3710f6d9d68af, xf86-video-intel-git 00e7312dc45e54cd4547a943897a524639cb0b38
Created attachment 33408 [details] Weird rendering bug, see also video http://uguu.de/~ranma/intel_kms_bugs/S6000641.AVI
Created attachment 33409 [details] Photo of what looks like a failed blit
Created attachment 33491 [details] [review] Unconditional big-hammer wbinvd() patch Hmm, it looks like all rendering errors except the font rendering bug are fixed by the 'drm-intel-big-hammer.patch' (after removing the i8xx-check in front of the wbinvd()). Still have to double-check though since I also upgraded to 2.6.33-rc8-git4 at the same time. (Now recompiling 2.6.33-rc8-git4 without the big-hammer patch)
I can confirm that those rendering errors (except the font thing) are apparently cache-coherency related. After removing the 'big hammer' patch, I see the errors again.
shining^ on #intel-gfx suggested reverting http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=83626aba357ffb4dd7931daaf163c1dd1d08f9d3 for the font issue, recompiling now.
FWIW, I'm still seeing the font errors with the patch reverted.
Tobias, just to confirm this is a i915 [as opposed to i945, g33, PineView, i965, g45, Ironlake etc]?
(In reply to comment #13) > Tobias, just to confirm this is a i915 [as opposed to i945, g33, PineView, > i965, g45, Ironlake etc]? I think so: 00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03) 00:02.0 0300: 8086:2592 (rev 03) 00:02.1 0380: 8086:2792 (rev 03) FWIW the font errors seem to be quite rare with the big hammer patch applied. Still running on 2.6.33-rc8-git4 (Since the problems mostly went away with the big hammer patch I haven't felt the need to update...) and intel_drv.so 00e7312dc45e54cd4547a943897a524639cb0b38. Currently waiting for https://bugs.freedesktop.org/show_bug.cgi?id=26744 to show up again after applying the debug patch...
How did this fare with Dave Airlie's fix for rendering errors during low-power CPU modes? [2.6.35]
(In reply to comment #15) > How did this fare with Dave Airlie's fix for rendering errors during low-power > CPU modes? [2.6.35] I've been running 2.6.35.1 for some time now and haven't seen any rendering problems even without the bighammer patch.
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.