With kernel 3.6 and later X is unusable on a Lenovo x200s laptop. Good kernel versions: 3.5.0, 3.5.7 Bad kernel versions: 3.6.11, 3.7.6, 3.8.0-rc6 Distributions is Ubuntu 12.04. All tested kernels are built from mainline and stable git. x200s have an Intel GMA45 GPU: $ lspci|grep VGA 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) A rather non-technical description of the bug is that the screen does not seem to be refreshed as often as it should be. For example when typing a password into the KDM login window, no * characters are shown. In konsole (KDEs terminal emulator) the window content frequently freezes. I can keep on typing and running commands, but nothing changes on the screen until I change back and forth between either another konsole tab or another virtual desktop. I have bisected this and the first bad commit is: commit 0b9f43a0ee7e89013a3d913ce556715fd8acb674 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: 2012-06-05 10:07:11 +0200 drm/i915: allow pipe A for lvds on gen4 Given the havoc the missing backlight pipe select code might have caused, let's try to re-enabled pipe A support for lvds on gen4 hw. Just to see what all blows up ... ...snip... So I guess one thing that blows up is my laptop? Reverting this commit fix the problem for me, verified on 3.6.11 and 3.8.0-rc6. Please let me know if I can help debug this further.
Lack of render cache flushing seems a strange side-effect of enabling that quirk, can you please attach your Xorg.0.log and also check for unusual CPU usage. If you xf86-video-intel driver is much older than 2.15.0 then this is a known bug in that driver.
Created attachment 92951 [details] Xorg.0.log when running 3.8.0-rc7 (bad)
Created attachment 92961 [details] dmesg.3.8.0-rc7 (bad)
Created attachment 92971 [details] dmesg.3.8.0-rc7+ (good)
I have attached Xorg.0.log from 3.8.0-rc7 (bad), and dmesg output with drm.debug=14. I also attached dmesg from 3.8.0-rc7+ (good) where 0b9f43a0 is reverted. I have not noticed any strange CPU usage. However I have not actually used the bad kernel versions very much, due to this bug. The version of xserver-xorg-video-intel is 2:2.17.0-1ubuntu4.3.
Forgot to mention this. The reason for not attaching Xorg.0.log from 3.8.0-rc7+ is that it is identical as the one from 3.8.0-rc7. --- Xorg.0.log.good 2013-02-10 19:10:45.233796374 +0100 +++ Xorg.0.log.bad 2013-02-10 19:10:41.286721791 +0100 @@ -5,4 +5,4 @@ Build Operating System: Linux 2.6.42-34-generic x86_64 Ubuntu -Current Operating System: Linux faran 3.8.0-rc7+ #1 SMP Sun Feb 10 14:24:25 CET 2013 x86_64 -Kernel command line: BOOT_IMAGE=/vmlinuz-3.8.0-rc7+ root=/dev/mapper/faranVG-btrfs1 ro rootflags=subvol=root pcie_aspm=force i915.i915_enable_rc6=1 splash vt.handoff=7 drm.debug=14 +Current Operating System: Linux faran 3.8.0-rc7 #1 SMP Sun Feb 10 13:58:28 CET 2013 x86_64 +Kernel command line: BOOT_IMAGE=/vmlinuz-3.8.0-rc7 root=/dev/mapper/faranVG-btrfs1 ro rootflags=subvol=root pcie_aspm=force i915.i915_enable_rc6=1 splash drm.debug=14 Build Date: 17 January 2013 06:14:10AM @@ -15,3 +15,3 @@ (WW) warning, (EE) error, (NI) not implemented, (??) unknown. -(==) Log file: "/var/log/Xorg.0.log", Time: Sun Feb 10 19:05:43 2013 +(==) Log file: "/var/log/Xorg.0.log", Time: Sun Feb 10 18:58:43 2013 (==) Using config file: "/etc/X11/xorg.conf" @@ -38,3 +38,3 @@ If no devices become available, reconfigure udev or disable AutoAddDevices. -(II) Loader magic: 0x7fe4d7474b00 +(II) Loader magic: 0x7f7fc1e64b00 (II) Module ABI versions:
Passes the smell test. Is it possible for you to test with a recent -intel to rule out a driver bug there? Would also be useful to compare the approaches taken by UXA vs SNA just in case. I'm still convinced this is a cache-flushing issue since the symptoms match many earlier reports thereof. As for why it only affects one pipe... Something else you can try is to switch the pipes using xrandr: $ xrandr --output LVDS1 --crtc 0 or $ xrandr --output LVDS1 --crtc 1
Nice trick. Using xrandr I can change from bad to good and back again. Just had to figure out to add --mode to the xrandr command to avoid a black screen. $ uname -r 3.8.0-rc7 $ # bad $ xrandr --output LVDS1 --crtc 1 --mode 1440x900 $ # good $ xrandr --output LVDS1 --crtc 0 --mode 1440x900 $ # bad again Another thing I just discovered is that running some OpenGL application also seems to fix (or at least hide) the problem as long as the GL window remains visible on screen. I discovered this by starting glxgears to see if it would also freeze, but this opposite result. Various GL screensavers from xscreensaver also seem to work. All this is still using Ubuntus 2.17.0 -intel. I will try to install a more recent -intel driver later.
I have now enabled the xorg-edgers PPA, which have git versions of most X packages like xorg core, drivers, libdrm, mesa and so on. xserver-xorg-video-intel is now version 2.21.0+git20130204.9640640a The bug is still present, but seem to trigger slightly less often. Both workarounds from my last comment (change crtc or run a GL program) are still working.
Created attachment 92991 [details] Xorg.0.log with -intel 2.21.0 on 3.8.7-rc7
The old bug about enabling pipe A for lvds was bug 16307.
Chris, I am happy to report that this bug is fixed in Linux 3.9. LVDS1 can use both CRTCs, defaults to CRTC 0 and there are no freezes. However I could not find anything relevant in the git log, so I did a bisect. The commit that fixes the bug is: commit e12a2d53ae45a69aea499b64f75e7222cca0f12f Author: Chris Wilson <chris@chris-wilson.co.uk> Date: 2012-11-15 11:32:18 +0000 drm/i915: Fix detection of base of stolen memory The routine to query the base of stolen memory was using the wrong registers and the wrong encodings on virtually every platform. ... Does this make sense to you? I have verified that cherry-picking this commit also fixes the bug on kernel 3.6 and 3.8. I should mention that I now run -intel 2.21.6, and I have verified that the bug is still present if I boot an unpatched 3.6 or 3.8 kernel. Thanks.
Well, it doesn't make much sense to me, the only sensible explanation is that we've stomped over some bios stuff. But on 3.6 we don't really use stolen memory, so I have no idea. Anyway, I've submitted the commit for stable inclusion, thanks for reporting this issue.