Created attachment 37241 [details] /var/log/messages with drm debugging set to level 4 While running Gnome with metacity (without a compositor), with an HDMI monitor at 1920x1200 and the internal panel at 1440x900; If I turn off LVDS1, HDMI1 flickers with the correct output briefly, then turns grey. Often when it's grey, the lower half of the screen will flicker black and grey. Moving the mouse updates the cursor correctly, but the image remains grey. Switching to a VT and back again restores correct behaviour/image/compositing. On the first VT switch, HDMI1 remains blank, the terminal appears on LVDS1 but the backlight is off. Switching back to X, LVDS1 still shows the console (still with the backlight off). /var/log/messages attached with drm.debug 4.
Created attachment 37244 [details] The actual messages
I hereby declare that the submitter is of sound mind and neither his vision nor his judgment was impaired by popping too many pills. Haven't got a clue as to what is going on, yet. It is not typical of the many Arrandale hangs so far reported -- in that it is *not* a hang. (Whilst noting, Thomas said that his x61 would occasionally hang on unplugging from the dock - a spin not unlike the suspected PP_CONTROL hang.)
I've managed to hit something very similar with: xrandr --output LVDS1 --off --output DP1 --preferred The registers look fine but the external monitor loses sync. Of particular note is that this change causes drm_remove_fb() to decouple the old framebuffer from crtc0.
I'm not sure if this helps or what it means, but the grey seems to come from the gtk theme - I'm guessing it's the window background colour...
Hmm, I managed to bisect the failure on my x201s to commit 1eb2cbb6d5efe129cd006691267ce513c0aa59da Author: Al Viro <viro@zeniv.linux.org.uk> Date: Thu May 27 11:11:06 2010 -0400 Revert "anon_inode: set S_IFREG on the anon_inode" This reverts commit a7cf4145bb86aaf85d4d4d29a69b50b688e2e49d. and reverting just that commit makes 'xrandr --output LVDS1 --off --output DP1 --preferred' work again. I am baffled.
For extra fun, it appears that udev is both the saviour and the culprit here. That commit fixes udev running at 100%, and thus blocking uevents. A killall udevd causes the same failure as running without the reverted commit.
Having learnt about the udevd anomaly, I repeated the bisection and found this as the potential culprit for my failure: commit 7f8a85698f5c8a981641ec0bdf9926768786db9d Author: Zhenyu Wang <zhenyuw@linux.intel.com> Date: Thu Apr 1 13:07:53 2010 +0800 drm/i915: Add the support of memory self-refresh on Ironlake Update the self-refresh watermark for display plane/cursor and enable the memory self-refresh on Ironlake. The watermark is also updated for the active display plane. More than 1W idle power is saved on one Ironlake laptop after enabling memory self-refresh.
Created attachment 37621 [details] [review] Update SR after dpms changes.
To add further mystery, booting up with a single connection enabled, self-refresh works. Add an external, self-refresh is disabled as expected. Remove either, self-refresh is re-enabled and the output fails. Notably, during this sequence we also get warnings that we fail to turn off the pipe...
In git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git drm-intel-staging we have a patch to disable self-refresh which is how we plan to sweep this bug under the carpet in the short term. /o\ http://git.kernel.org/?p=linux/kernel/git/ickle/drm-intel.git;a=commit;h=71c831d2cce539e0ee8e3b3fadae49355867efc2
We've disabled self-refresh [bug 30125].
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.