Bug 29173 - Arrandale, Turning off LVDS1 while HDMI1 is on results in a flickering grey screen
Summary: Arrandale, Turning off LVDS1 while HDMI1 is on results in a flickering grey s...
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: git
Hardware: Other All
: highest normal
Assignee: Chris Wilson
QA Contact: Xorg Project Team
Depends on:
Reported: 2010-07-20 07:31 UTC by Chris Lord
Modified: 2010-09-10 16:12 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

/var/log/messages with drm debugging set to level 4 (141.96 KB, text/plain)
2010-07-20 07:31 UTC, Chris Lord
no flags Details
The actual messages (83.34 KB, text/plain)
2010-07-20 08:09 UTC, Chris Lord
no flags Details
Update SR after dpms changes. (3.47 KB, patch)
2010-08-06 00:51 UTC, Chris Wilson
no flags Details | Splinter Review

Description Chris Lord 2010-07-20 07:31:25 UTC
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.
Comment 1 Chris Lord 2010-07-20 08:09:26 UTC
Created attachment 37244 [details]
The actual messages
Comment 2 Chris Wilson 2010-07-20 08:17:40 UTC
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.)
Comment 3 Chris Wilson 2010-08-03 01:19:46 UTC
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.
Comment 4 Chris Lord 2010-08-03 03:26:30 UTC
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...
Comment 5 Chris Wilson 2010-08-04 10:37:24 UTC
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.
Comment 6 Chris Wilson 2010-08-04 11:00:50 UTC
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.
Comment 7 Chris Wilson 2010-08-05 14:28:32 UTC
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.
Comment 8 Chris Wilson 2010-08-06 00:51:50 UTC
Created attachment 37621 [details] [review]
Update SR after dpms changes.
Comment 9 Chris Wilson 2010-08-20 03:38:34 UTC
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...
Comment 10 Chris Wilson 2010-09-10 02:53:51 UTC
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\

Comment 11 Chris Wilson 2010-09-10 16:12:31 UTC
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.