Hi,
Since 3.16 an external monitor stays dark after resume from sleep. I didn't manage to activate it again with xrand. According to xrandr it is "connected" and configured with a mode, but I get no signal.
Happens since 3.16 and is still broken with 3.17-rc5.
Hardware: HP EliteBook 8540w 01:00.0 VGA compatible controller: NVIDIA Corporation GT215GLM [Quadro FX 1800M] (rev a2) 0
External Monitor connected via DVI on the docking station.
XRandR before amd after suspend looks the same:
$ xrandr Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 LVDS-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 345mm x 194mm 1920x1080 59.9*+ 60.0 1680x1050 60.0 1400x1050 60.0 1280x1024 59.9 1280x960 59.9 1152x864 60.0 1024x768 59.9 800x600 59.9 640x480 59.4 720x400 59.6 640x400 60.0 640x350 59.8 DP-1 disconnected (normal left inverted right x axis y axis) DP-2 disconnected (normal left inverted right x axis y axis) eDP-1 disconnected (normal left inverted right x axis y axis) DP-3 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 598mm x 336mm 1920x1080 60.0*+ 1680x1050 59.9 1280x1024 75.0 60.0 1440x900 75.0 59.9 1024x768 75.1 60.0 800x600 75.0 60.3 640x480 75.0 72.8 66.7 60.0 720x400 70.1 VGA-1 disconnected (normal left inverted right x axis y axis)
dmesg output of a suspend/resume cycle attached.
I have tried and reverted these commits but to no avail.
028791bb7d6 drm/nouveau/kms: restore fbcon after display has been resumed 456b0579fb0 drm/nouveau: use connector events for HPD instead of GPIO watching
On Thu, Sep 18, 2014 at 10:07 AM, Ortwin Glück odi@odi.ch wrote:
Hi,
Since 3.16 an external monitor stays dark after resume from sleep. I didn't manage to activate it again with xrand. According to xrandr it is "connected" and configured with a mode, but I get no signal.
Happens since 3.16 and is still broken with 3.17-rc5.
Hardware: HP EliteBook 8540w 01:00.0 VGA compatible controller: NVIDIA Corporation GT215GLM [Quadro FX 1800M] (rev a2) 0
External Monitor connected via DVI on the docking station.
This has been reported a few times already -- probably the same thing as bug https://bugs.freedesktop.org/show_bug.cgi?id=83550
Sorry, no resolution as of yet. If you could verify that the commit that got bisected to in that bug indeed causes your problem, it would be nice to have before and after logs from a kernel compiled with NOUVEAU_DEBUG set to 7 (spam) booted with nouveau.debug=trace,PDISP=spam . That should hopefully help isolate the issue. (Don't use a kernel with NOUVEAU_DEBUG set that high for daily use -- it introduces a ton of debug code everywhere.) If the commit that got bisected to in the bug is not the cause of your issues, you'll need to do your own bisect.
Cheers,
-ilia
XRandR before amd after suspend looks the same:
$ xrandr Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 LVDS-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 345mm x 194mm 1920x1080 59.9*+ 60.0 1680x1050 60.0 1400x1050 60.0 1280x1024 59.9 1280x960 59.9 1152x864 60.0 1024x768 59.9 800x600 59.9 640x480 59.4 720x400 59.6 640x400 60.0 640x350 59.8 DP-1 disconnected (normal left inverted right x axis y axis) DP-2 disconnected (normal left inverted right x axis y axis) eDP-1 disconnected (normal left inverted right x axis y axis) DP-3 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 598mm x 336mm 1920x1080 60.0*+ 1680x1050 59.9 1280x1024 75.0 60.0 1440x900 75.0 59.9 1024x768 75.1 60.0 800x600 75.0 60.3 640x480 75.0 72.8 66.7 60.0 720x400 70.1 VGA-1 disconnected (normal left inverted right x axis y axis)
dmesg output of a suspend/resume cycle attached.
On 18.09.2014 16:58, Ilia Mirkin wrote:
This has been reported a few times already -- probably the same thing as bug https://bugs.freedesktop.org/show_bug.cgi?id=83550
Ah, thanks. I would like to try with that commit reverted, but unfortunately it no longer reverts cleanly, and my attempts to make a sensible merge were futile. If you can send me a patch that reverts the changes on 3.17-rc5 or 3.16 I am glad to try it out and give you the requested feedback.
Ortwin
On Fri, Sep 19, 2014 at 10:41 AM, Ortwin Glück odi@odi.ch wrote:
On 18.09.2014 16:58, Ilia Mirkin wrote:
This has been reported a few times already -- probably the same thing as bug https://bugs.freedesktop.org/show_bug.cgi?id=83550
Ah, thanks. I would like to try with that commit reverted, but unfortunately it no longer reverts cleanly, and my attempts to make a sensible merge were futile. If you can send me a patch that reverts the changes on 3.17-rc5 or 3.16 I am glad to try it out and give you the requested feedback.
git checkout 415f12efc1b2308411b2cbc3e82666b3db8a7758^
[build, confirm it works, grab logs]
git checkout 415f12efc1b2308411b2cbc3e82666b3db8a7758
[build, confirm it's broken, grab logs]
It's not the sort of change that's really revertable...
-ilia
On Fri, Sep 19, 2014 at 12:52 PM, Ortwin Glück odi@odi.ch wrote:
On 19.09.2014 17:58, Ilia Mirkin wrote:
git checkout 415f12efc1b2308411b2cbc3e82666b3db8a7758^
Thanks again. I confirm that Bugzilla 83550 is the same issue. I have attached the captured logs there for reference.
Thanks! Hopefully you still have those kernels handy, as your logs got cut off. Try booting with log_buf_len=100M to increase the "scrollback" buffer (I assume you have oodles of RAM). Or grab the kernel logs from your system.
-ilia
On 09/19/2014 07:01 PM, Ilia Mirkin wrote:
Thanks! Hopefully you still have those kernels handy, as your logs got cut off.
Yeah, I noticed and hoped it wouldn't matter as it is mostly the boot log that's been cut off until syslog came up (it's from /var/log/messages). So suspend/resume cycle should be complete. But I can give it another try on Monday when I'm back in the office.
Ortwin
dri-devel@lists.freedesktop.org
-
Ilia Mirkin -
Ortwin Glück