External displays connected to a DP Hub remain blank after resuming from suspend starting from linux-3.18; they used to work with linux-3.17. My setup has a Haswell Thinkpad connected to a DP Hub. The laptop's display turns back on fine. I am able to turn back the external displays by first turning them off via xrandr and then turning them on. This behavior remains with linux-3.18.9 and linux-3.19.1 Is this bug already known? If not, I can assist you with debugging if you can tell me where to look at.
Could you boot with drm.debug=14 and provide the dmesg after doing the first suspend/resume cycle that fails?
Created attachment 114353 [details] dmesg debug outputs The attachment contains the dmesg output with drm.debug=14. It contains: * before_suspend.log: output until invoking suspend to RAM * after_suspend.log.diff: output taken after resuming (the external displays remain turned off) * laptop_switch.log.diff: output after turning off all external displays with xrandr * full_switch.log.diff: output after turning on all external displays with xrandr Note that the diffs are to be applied successively as per the order listed above.
(In reply to Sree Harsha Totakura from comment #2) > The attachment contains the dmesg output with drm.debug=14. I forgot to mention that the logs were obtained while running linux-3.19.1
I see two MST streams being restored during resume. The only issue I can spot in the modeset for these is: [ 50.162397] [drm:drm_dp_mst_allocate_vcpi] initing vcpi for 532 14 [ 50.162997] [drm:intel_mst_enable_dp] 1 [ 50.176764] [drm:drm_dp_check_act_status] failed to get ACT bit 1 after 30 retries [ 50.176765] [drm:drm_dp_update_payload_part2] payload 0 1 and [ 50.218921] [drm:intel_mst_pre_enable_dp] 1 [ 50.218922] [drm:drm_dp_mst_allocate_vcpi] initing vcpi for 387 10 [ 50.219535] [drm:intel_mst_enable_dp] 2 [ 50.233404] [drm:drm_dp_check_act_status] failed to get ACT bit 1 after 30 retries [ 50.233405] [drm:drm_dp_update_payload_part2] payload 0 2 [ 50.233405] [drm:drm_dp_update_payload_part2] payload 1 1 Adding Dave. Any idea?
Any update on this? I just tested linux-3.19.2 and it, too, has this bug.
Created attachment 115543 [details] dmesg drm-intel-nightly 2015y-05m-05d I can confirm this bug. It still exists in drm-intel-nightly: b10dc96 drm-intel-nightly: 2015y-05m-05d-07h-49m-44s UTC integration manifest (I had to revert "drm/i915: Implement the intel_dp_autotest_edid function for DP EDID complaince tests", as it caused a compilation failure.) I tried raising the retry count in drm_dp_check_act_status(). With that the "[drm:drm_dp_check_act_status] failed to get ACT bit 1 after ..." message was gone and an extra log message stated that it worked after round about 66 retries, but the problem with the external monitor remains.
(In reply to Daniel Martin from comment #6) > Created attachment 115543 [details] > dmesg drm-intel-nightly 2015y-05m-05d > > I can confirm this bug. It still exists in drm-intel-nightly: > b10dc96 drm-intel-nightly: 2015y-05m-05d-07h-49m-44s UTC integration > manifest > > (I had to revert "drm/i915: Implement the intel_dp_autotest_edid function > for DP EDID complaince tests", as it caused a compilation failure.) > > I tried raising the retry count in drm_dp_check_act_status(). With that the > "[drm:drm_dp_check_act_status] failed to get ACT bit 1 after ..." message > was gone and an extra log message stated that it worked after round about 66 > retries, but the problem with the external monitor remains. Forgot to mention that you don't need a running X-Server to reproduce the problem, a plain console is sufficient. That's how the dmesg was created. And waiting until the console blanks and bringing it back with a key press re-activates the external monitor too.
Bisected down to: commit e7d6f7d708290da1b7c92f533444b042c79412e0 Author: Dave Airlie <airlied@redhat.com> Date: Mon Dec 8 13:23:37 2014 +1000 drm/i915: resume MST after reading back hw state Otherwise the MST resume paths can hit DPMS paths which hit state checker paths, which hit WARN_ON, because the state checker is inconsistent with the hw. This fixes a bunch of WARN_ON's on resume after undocking. ... Reverting this commit fixes the problem, but brings the warnings back. :/
> And waiting until the console blanks and bringing it back with a key press > re-activates the external monitor too. I confirm this. Now, as a workaround I change to a console and wait until it shows up and then change back to the Xserver.
In 4.1.0 is worse, every cca minute is monitor blinks black for a second, even without suspend-resume.
(In reply to noga.dany from comment #10) > In 4.1.0 is worse, every cca minute is monitor blinks black for a second, > even without suspend-resume. The monitors does not seem to blink black in linux-4.1.3 for me. @noga.dany: can you please confirm if its the same for you too? The monitors, however, stay blank after resume. Switching back to a virtual console seems to work sporadically now. Is there any way in which I can help debugging for this bug?
Probably same (or almost same): https://bugzilla.kernel.org/show_bug.cgi?id=88601
(In reply to Sree Harsha Totakura from comment #11) > (In reply to noga.dany from comment #10) > > In 4.1.0 is worse, every cca minute is monitor blinks black for a second, > > even without suspend-resume. > > The monitors does not seem to blink black in linux-4.1.3 for me. > @noga.dany: can you please confirm if its the same for you too? > > The monitors, however, stay blank after resume. Switching back to a virtual > console seems to work sporadically now. > > Is there any way in which I can help debugging for this bug? Negative, in 4.1.3 still blinks black.
(In reply to noga.dany from comment #13) > (In reply to Sree Harsha Totakura from comment #11) > > (In reply to noga.dany from comment #10) > > > In 4.1.0 is worse, every cca minute is monitor blinks black for a second, > > > even without suspend-resume. > > > > The monitors does not seem to blink black in linux-4.1.3 for me. > > @noga.dany: can you please confirm if its the same for you too? > > > > The monitors, however, stay blank after resume. Switching back to a virtual > > console seems to work sporadically now. > > > > Is there any way in which I can help debugging for this bug? > > Negative, in 4.1.3 still blinks black. Interesting is that it blinks only one monitor from two connected. Tested on three different monitors
In 4.2.0 RC5 I cannot start two external monitors simultaneously. One is permanently disabled.
I'm having this issue too - it never worked for me, so guess it could be unrelated but still configuration is nearly the same: - GPU: Haswell - Laptop: DELL Latitude E5440 - MST dock from DELL - 2 DELL U2415 monitors attached via mDP (DP1.2 disabled) $ rpm -qa|fgrep xorg-x11-drv-intel xorg-x11-drv-intel-2.99.917-16.20150729.fc23.x86_64 $ rpm -qa|fgrep xorg-x11-server xorg-x11-server-common-1.18.0-0.4.20150907.fc23.x86_64 xorg-x11-server-Xorg-1.18.0-0.4.20150907.fc23.x86_64 xorg-x11-server-utils-7.7-16.fc23.x86_64 There are 2 monitors connected + eDP on laptop. When I boot the system everything works just fine, monitors are visible and configurable via xrandr. But if I suspend/resume the laptop, both monitors are in power save mode but xrandr still show that they are connected. If I try to switch them off/on one by one using xrandr but only one monitor start to work, another remain blank. Attaching dmesg with drm debug enabled after resume and after play with xrandr.
Created attachment 118769 [details] dmesg after resume dmesg after resume, both monitors are blank/switched off.
Created attachment 118770 [details] dmesg after resume and xrandr dmesg after resume and xrandr command: xrandr --output DP1-1 --off xrandr --output DP1-2 --off xrandr --output DP1-2 --auto xrandr --output DP1-1 --auto xrandr --output DP1-2 --right-of DP1-1 --auto --preferred --primary forgot to add kernel version: kernel-4.2.2-300.fc23.x86_64
Just another "me too". I see this with two monitors (DP1-1 & DP1-2) attached via mdp + laptop (eDP1). My kernel: 4.2.5-1-ARCH #1 SMP PREEMPT Tue Oct 27 08:13:28 CET 2015 x86_64 GNU/Linux When I resume from sleep the laptop monitor comes on but the other two do not. If I turn off one of them the other comes back, and then I can turn the other one on. But I've found the state then to be unstable and the system can freeze suddenly so I tend just not to put it to sleep with both monitors attached. Not sure if it's related but I see this flagged in journalctl: drm:intel_mst_pre_enable_dp [i915]] *ERROR* failed to allocate vcpi drm:intel_mst_enable_dp [i915]] *ERROR* Timed out waiting for ACT sent drm:intel_mst_pre_enable_dp [i915]] *ERROR* failed to allocate vcpi drm:intel_mst_enable_dp [i915]] *ERROR* Timed out waiting for ACT sent -----------[ cut here ]------------ ARNING: CPU: 2 PID: 18078 at drivers/gpu/drm/i915/intel_display.c:6380 intel_modeset_check_stat rong connector dpms state odules linked in: rfcomm ctr ccm fuse xt_conntrack ipt_MASQUERADE nf_nat_masquerade_ipv4 iptabl snd_soc_rt5640 cfg80211 hid_generic snd_soc_rl6231 bluetooth hid_logitech_dj media snd_soc_core aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd ahci libahci libata ehci_pci xhci_pci sc PU: 2 PID: 18078 Comm: kworker/u16:92 Not tainted 4.2.5-1-ARCH #1 ardware name: Dell Inc. XPS13 9333/0D13CR, BIOS A05 09/11/2014
Please re-test running v4.4. If the problem persists, please add drm.debug=14 module parameter, and attach dmesg.
Created attachment 121128 [details] 4.4.0, still doesn't work
Now on 4.4.1-1 this seems to work the first time I suspend, but then the second time when I come out of sleep the machine freezes.
This bug seems to be fixed in the recent versions. I am not experiencing this on my setup with linux-4.6.4. If this is not the case with you, please reopen. Thank you all for your inputs.
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.