Forwarding this bug from Ubuntu reporter Jonathan Lange: http://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/849782 [Problem] When system is under load, the graphics experience periodic glitches. Perhaps under the load of oneiric's Unity3D the driver isn't able to keep up with the graphics loads, and isn't able to fill the pipe 100% of the time? How could that be proved/disproved (or are we way off base?) [Original Description] I have a Lenovo X200 laptop, and I run Unity 3D. Every so often, since oneiric, my screen jitters. That is, it seems to jump up and down like it has a nervous twitch. I can't reproduce it exactly, but it seems more likely to happen when my system is under load. I've monitored .xsession-errors when the twitch happens, and nothing is dumped there. I've also checked /var/crash/, but none of the crashes there have times that match the twitch. Chris Halse Rogers suggested trying, "echo 0 > /sys/module/drm_kms_helper/parameters/poll", but that doesn't seem to correct the problem. In addition, unity_support_test crashed while filing this bug. DistroRelease: Ubuntu 11.10 Package: xserver-xorg 1:7.6+7ubuntu7 ProcVersionSignature: Ubuntu 3.0.0-10.16-generic 3.0.4 Uname: Linux 3.0.0-10-generic x86_64 .tmp.unity.support.test.0: ApportVersion: 1.22.1-0ubuntu2 Architecture: amd64 CompizPlugins: [core,bailer,detection,composite,opengl,compiztoolbox,decor,mousepoll,resize,gnomecompat,place,wall,vpswitch,move,regex,snap,session,animation,expo,workarounds,ezoom,staticswitcher,fade,scale,unityshell] CompositorRunning: compiz Date: Wed Sep 14 09:31:23 2011 DistUpgraded: Log time: 2011-07-26 11:37:40.528783 DistroCodename: oneiric DistroVariant: ubuntu EcryptfsInUse: Yes ExtraDebuggingInterest: Yes, whatever it takes to get this fixed in Ubuntu GlAlternative: lrwxrwxrwx 1 root root 24 2010-03-20 18:53 /etc/alternatives/gl_conf -> /usr/lib/mesa/ld.so.conf GraphicsCard: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device [17aa:20e4] Subsystem: Lenovo Device [17aa:20e4] MachineType: LENOVO 7454A12 ProcEnviron: PATH=(custom, user) LANG=en_AU.UTF-8ProcKernelCmdLine: root=UUID=66c83d9d-bb68-4f51-995c-63e9b4ee025f ro quiet splash SourcePackage: xorg UnitySupportTest: Error: command ['/usr/lib/nux/unity_support_test', '-p', '-f'] failed with exit code -11: UpgradeStatus: Upgraded to oneiric on 2011-07-26 (49 days ago) dmi.bios.date: 07/30/2008 dmi.bios.vendor: LENOVO dmi.bios.version: 6DET28WW (1.05 ) dmi.board.name: 7454A12 dmi.board.vendor: LENOVO dmi.board.version: Not Available dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.modalias: dmi:bvnLENOVO:bvr6DET28WW(1.05):bd07/30/2008:svnLENOVO:pn7454A12:pvrThinkPadX200:rvnLENOVO:rn7454A12:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.name: 7454A12 dmi.product.version: ThinkPad X200 dmi.sys.vendor: LENOVO version.compiz: compiz 1:0.9.5.94+bzr2803-0ubuntu1 version.ia32-libs: ia32-libs 20090808ubuntu20 version.libdrm2: libdrm2 2.4.26-1ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 7.11.0+git20110128.2a18d195-0ubuntu0sarvatt version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A version.libgl1-mesa-glx: libgl1-mesa-glx 7.11.0+git20110128.2a18d195-0ubuntu0sarvatt version.xserver-xorg: xserver-xorg 1:7.6+7ubuntu7 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.6.0-1ubuntu13 version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.14.99~git20110811.g93fc084-0ubuntu1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.15.901-1ubuntu2 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau N/A
Jonathan has also tested with KMS debugging turned on, but nothing is printed to dmesg when the glitch occurs. I'm having him re-test natty again (to rule out hardware), as well as a clean oneiric image (to rule out possible local config), but suspect those won't turn up anything.
A video to demonstrate the problem is at this link (file too large for bugzilla): https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/849782/+attachment/2401527/+files/VID_20110908_181612.3gp The quality of the video is unfortunately poor, but the glitch occurs around the 9-10 sec mark.
Created attachment 52276 [details] BootDmesg.txt
Created attachment 52277 [details] CurrentDmesg.txt
Created attachment 52278 [details] XorgLog.txt
Afaict from that video, the glitch was limited to a vertical shift of the chat pane within xchat. Is the glitch typically limited to a single window?
It's a whole screen thing. That said, I do tend to run windows maximized, and it *is* a momentary effect, so I could be wrong. I doubt it though. Sorry for the delay in answering. I had typed out an answer before and hit "Commit", but no dice.
A whole screen jitter is much more likely to be a FIFO underrun, which sadly are only reported with drm.debug=0x1 (along with every ioctl, so too noisy to be useful). Can you attach your boot dmesg with drm.debug=0xe, I want to confirm if this hardware also fixed FIFO watermarks due to a silicon bug, in which case there is very little we can do (if it does turn out to be a FIFO issue).
Created attachment 52289 [details] dmesg with drm.debug=0xe Attached is the dmesg with drm.debug=0xe included. I've triggered the glitch on this boot. Also, I've tested with clean natty and oneiric live USB sticks. I can confirm that the issue does occur with clean oneiric and does *not* occur with clean natty.
Ok, the important line is [drm:g4x_update_wm], Setting FIFO watermarks - A: plane=2, cursor=2, B: plane=26, cursor=6, SR: plane=59, cursor=6 which means that your hardware did not inherit the broken Crestline silicon, and an actual FIFO underrun is much less likely. Might still be worth running with drm.debug=0x1 and keeping an eye out for FIFO underrun warnings. And as is the nature of such issues, a change in rendering patterns is also likely to provoke running into different memory constraints (so a FIFO underrun is susceptible to userspace changes).
Just to be clear, if I run with 0x1, what exactly am I grepping for in dmesg?
if (pipe_stats[pipe] & PIPE_FIFO_UNDERRUN_STATUS) DRM_DEBUG_DRIVER("pipe %c underrun\n", pipe_name(pipe)); So that would be "pipe [AB] underrun"
Created attachment 52329 [details] dmesg w/ drm.debug=0x1 Here's w/ drm.debug=0x1. No 'pipe [AB] underrun' regex matches.
(In reply to comment #13) > Created an attachment (id=52329) [details] > dmesg w/ drm.debug=0x1 > > Here's w/ drm.debug=0x1. No 'pipe [AB] underrun' regex matches. To check the obvious as it is quite a short dmesg (compared to what I was expecting, very few ioctls i.e. very few drawing commands), did you observe flicker within that time?
(In reply to comment #14) > (In reply to comment #13) > > Created an attachment (id=52329) [details] [details] > > dmesg w/ drm.debug=0x1 > > > > Here's w/ drm.debug=0x1. No 'pipe [AB] underrun' regex matches. > > To check the obvious as it is quite a short dmesg (compared to what I was > expecting, very few ioctls i.e. very few drawing commands), did you observe > flicker within that time? Yes, I did. Three separate incidents. Perhaps I mistyped the drm.debug kernel boot option? Also, to be clear, I'm uploading /var/log/dmesg. Do let me know if I should be doing something else. Btw, I'm very grateful for how responsive you've been. Thanks.
Ah, iirc /var/log/dmesg is the dmesg from boot and not the latest message. To get the current dmesg, just type 'dmesg' (so dmesg > dmesg.txt and attach).
Created attachment 52918 [details] dmesg w/ drm.debug=0xe for real This is a dmesg snapshot taken shortly after reproducing the bug with drm.debug=0xe.
Created attachment 52919 [details] dmesg snapshot taken w/ drm.debug=0x1 after reproducing This time with drm.debug=0x1.
FWIW, this issue still occurs regularly for me.
Demonstrably a hardware issue. Same jitters have occurred on console and before OS boot.
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.