Bug 41588 - suspend/resume with active CRTC, but disconnected output causes problems
Summary: suspend/resume with active CRTC, but disconnected output causes problems
Status: RESOLVED INVALID
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-08 07:29 UTC by maximlevitsky
Modified: 2013-10-01 16:24 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
disable hotplug polling while in suspend (1016 bytes, patch)
2011-10-08 07:29 UTC, maximlevitsky
no flags Details | Splinter Review

Description maximlevitsky 2011-10-08 07:29:17 UTC
Created attachment 52120 [details] [review]
disable hotplug polling while in suspend

Just like summary says, to reproduce just attach external monitor via DVI (other inputs should cause same problem) suspend/resume.

On resume you see black/white stripes on internal screen (LVDS) and external monitor is on standby.
If you then disconnect external monitor and suspend again, on resume often the desktop's screen doesn't come back ether.
Happens with and without compiz, with and without pageflipping enabled.

However I found what triggers the problem. kernel driver doesn't disable output polling during suspend so once in a while, it polls the port while whole card is disabled and logically doesn't detect anything connected.
Then on resume it detects the monitor again, and that triggers the bug.
Of course this should be fixed, and patch to do so will be attached here.

However, its still possible to reproduce same bug, with 100% probability, by doing:

1. ensure you don't have apps that listen to hotplug events and reconfigure the screen. KDE sadly is belongs here.

2. connect external monitor, and activate an output on it using xrandr (side by side screens) aka:
xrandr --output DVI-I-1 --auto --left-of LVDS-1

3. suspend the system

4. while system suspended, disconnect the monitor

5. resume the system, and note that screen configuration didn't change, because
no apps listen to hotplug events. Yet, if you connect the DVI screen now, it won't activate. don't connect it though yet.

7. suspend system

8. connect monitor

9. resume system, and see the problem.

10. if you also run compiz and try to rotate screen, enjoy hung compiz. Dunno why.


Yet though, the above sequence of events is unlikely to happen while using the system, thus patch to stop hotplug detection while in suspend is enough for me to use external monitor safely.
Comment 1 maximlevitsky 2011-10-08 08:22:15 UTC
Changed bug title to reflect further findings.

So to reproduce the problem (with the patch), all you need is:

1. connect external monitor
2. activate it using xrandr
3. disconnect it (and rely on lack of software that deactivates the CRTC).

4. suspend/resume.

Now the bug is already there. If you suspended with compiz running, you can try to rotate the cube and it will freeze, sometimes the screen will be filled with black/white pattern.
Of course if you connect the DVI output it won't show anything.

If you suspend/resume again, you will get for sure that black/white pattern.
Comment 2 maximlevitsky 2011-10-08 11:21:35 UTC
Note that I verified that this problem doesn't happen on VGA output.
I suspect its somewhat related to clock scripts nouveau executes.

Also, I managed even with all this still to cause DVI not to come back after resume, and that seems to be partially unreleated bug, and unlike the bug we discuss here its mostly harmless (I can suspend/resume again or turn output on/off to fix this) and happens very rarely
Comment 3 maximlevitsky 2011-10-09 04:12:21 UTC
And I found the way to 100% reproduce the other way of breaking external output.
I opened another bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=41608
Comment 4 maximlevitsky 2011-10-09 06:28:02 UTC
And with patch I just wrote for the other bugreport, this bug now it clearly causes much less damage that expected initially.

Now if I suspend/resume with external DVI output activated and off (and with or without cursor on it), on resume output is deactivated, but off/on cycle fixes it.
If I suspend/resume again, then I see garbage over main screen, but that doesn't cause any hangs, I just need to redraw that screen.
I dig into this deeper later, but really now I can finally safely use my DVI monitor.
Comment 5 Carsten Pfeiffer 2012-09-10 19:56:32 UTC
I Lenovo notebook W510 with a GT216 [Quadro FX 880M] (rev a2) running xserver-xorg-video-nouveau 1.0.1-3 (Debian unstable), Kernel 3.2.0-3-amd64.

My problem is that after resuming from ram, I cannot re-activate the LVDS-1 display if it had been disabled once before suspending.

To reproduce, do the following:
1. plug in external monitor (DVI here)
2. use xrandr or e.g. krandrtray to enable external display and disable internal display (LVDS-1)
3. suspend to ram
4. resume
5. => LVDS-1 stays black forever, no way to reactivate it

I tried to disable the external display and re-enable LVDS-1 *before* suspending, which works fine (LVDS-1 works). But after suspend&resume, LVDS-1 is black and cannot be reactivated.

A workaround is to keep LVDS-1 always on, but then you cannot use two external displays anymore. For using two external displays, you *have* to disable LVDS-1.
Comment 6 Ilia Mirkin 2013-08-30 23:43:16 UTC
Does this still happen with the latest kernel?
Comment 7 Ilia Mirkin 2013-10-01 16:24:59 UTC
No response to re-test request for over a month. Closing as invalid.


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.