Kubuntu 9.10, kernel 2.6.33rc2 Intel driver version 2.9.0 (package 2.9.0-1ubuntu2) libdrm packages from xorg-edgers ppa, package versions 2.4.17+git20091230.c5c503b5-0ubuntu0sarvatt~karmic Machine is an Advent 4211 netbook (MSI Wind U100 rebrand). Behavior: The screen randomly makes weird jerks where entire screen content is temporarily displaced for a split second (100ms perhaps). It's as if something briefly tugs at the screen at random intervals. The behavior starts after having disabled an external monitor and lasts until X session restart, until you reenable the other monitor, or if you start glxgears and keep it running in the background. How to reproduce: 1. Connect an external monitor 2. Enable monitor, such as with 'xrandr --output VGA1 --mode 1280x1024 --above LVDS1' 3. Disable monitor with 'xrandr --output VGA1 --off' 4. Wait and observe screen jerks How to recover: - Restart X OR - Reenable monitor and keep it enabled OR - Run glxgears and keep it running in the background
Correction; behavior persists even after X restart (complete stop/start). Reboot is necessary. Please reassign this report if this falls outside of xorg/intel.
This machine has a 945 GPU, right? -Carl
$ lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GME Express Integrated Graphics Controller (rev 03) Apologies, I really should have included that in the original report. As per advice from #intel-gfx on irc.freenode.net I added 'i915.powersave=0' as a bootline option, after which this behavior stopped. I have since installed Kubuntu 10.04 Lucid, and in its kernel (2.6.32) powersaving seems to be disabled by default, removing the need for the option. When it was flickering, intel_gpu_top showed some process (framebuffer compression?) constantly maxing out at 99% - whereas now with powersaving disabled everything is hovering at near 0% at idle. I imagine this is a duplicate of some much larger i915 bug?
The "jerk" is a FIFO underrun. The debugging that helps here is an intel_reg_dump before and after the jerks begin. Rebooting with drm.debug=0xf might be useful to record the timings and pixel clocks used when calculating the FIFO size.
We need the debug output, but the reporter seems to be awol. Closing this, please reopen once you've gathered the requested information (reg dumps + dmesg with drm.debug=0xe).
Reporter here. Many apologies for the lack of feedback. The machine on which this happened is on the shelf counting electric sheep, so I haven't been able to casually debug it amid everyday use. Ever since I migrated to a beefier laptop it simply hasn't scratched my itch, so to speak, I'll try to find the time to bring said laptop back to life for some torture.
Cool, thanks for the feedback. Please reopen this bug here once your machine is fit for testing - we're working on (finally) tackling the dsparb underrun problem for real, so might have a patch to test soon.
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.