I'm using a ThinkPad T540p, docking station, two identical external monitors (HP LP2065), wired through the VGA (D-SUB) and DVI docking station ports. Latest Fedora 22. XFCE. Usually, I only use the external monitors for output. When the screensaver kicks in (or when I run 'xset s activate', for example), both monitors correctly go into power saving mode. When I then move the mouse, the RHS monitor (connected through DVI) wakes up and displays picture normally. The LHS monitor (connected through the VGA) does not wake up at all. I have to manually disable the LHS monitor using xfce4-display-settings, then manually re-enable it before it wakes up again.
Created attachment 117459 [details] Xorg.0.log Xorg.0.log attached. At the bottom you can see a couple of occasions where it was in 3200x1200 across two monitors, screen saver came on, then came back as only 1600x1200 (one monitor not active). The other bits (where it goes 1600x1200->5120x1200->3200x1200) are me wrestling with xfce4-display-settings to get the picture back right.
Created attachment 117460 [details] dmesg dmesg, booted with drm.debug=0x06
Created attachment 117461 [details] dmesg.gz
Other details: -- chipset: 00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device 2210 Flags: bus master, fast devsel, latency 0, IRQ 29 Memory at f0000000 (64-bit, non-prefetchable) [size=4M] Memory at e0000000 (64-bit, prefetchable) [size=256M] I/O ports at 4000 [size=64] Expansion ROM at <unassigned> [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915 Kernel modules: i915 -- system architecture: x86_64 -- xf86-video-intel/xserver/ version: latest Fedora 22 X.Org X Server 1.17.2 [ 25.878] (II) Module intel: vendor="X.Org Foundation" [ 25.878] compiled for 1.17.1, module version = 2.99.917 -- kernel version: 4.0.6-300.fc22.x86_64 -- Linux distribution: Fedora 22 -- Machine or mobo model: ThinkPad T540p -- Display connector: see comment #1 Reproducibility: 100% with 'xset s activate'
Please re-test running v4.4. If the problem persists, please add drm.debug=14 module parameter, and attach dmesg.
I believe I have the same issue. Kernel: Linux version 4.4.0-999-generic (kernel@tangerine) (gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2) ) #201601122100 SMP Wed Jan 13 02:02:49 UTC 2016 Release: Ubuntu 15.10 00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: Dell Device 060a Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 42 Region 0: Memory at f0000000 (64-bit, non-prefetchable) [size=4M] Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M] Region 4: I/O ports at 3000 [size=64] Expansion ROM at <unassigned> [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: fee0f00c Data: 41a1 Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [a4] PCI Advanced Features AFCap: TP+ FLR+ AFCtrl: FLR- AFStatus: TP- Kernel driver in use: i915 X.Org X Server 1.17.2 Machine: Dell XPS 13 9333 with bios A08 (latest) Setup: Belkin 2x HDMI to mini-displayport Originally reported: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1527829 The issue doesn't occur if sleep mode is activated less than 10s. I wrote a script to go through various intervals and get the output of dmesg immediately following an "xset dpms force off". Files debug14-8s, debug14-9s are with successful external monitor restore (expected behavior) Files debug14-10s, debug14-11s are with the display resuming and the two external monitors don't wake.
Created attachment 121030 [details] debug14-8s
Created attachment 121031 [details] debug14-9s
Created attachment 121032 [details] debug14-10s error occurs
Created attachment 121033 [details] debug14-11s error occurs
Created attachment 121034 [details] Xorg.0.log
Failed suspend/resume always results in the following: $ grep "payload 1 1" debug14* debug14-8s:[ 1102.530611] [drm:drm_dp_update_payload_part2] payload 1 1 debug14-9s:[ 1130.909691] [drm:drm_dp_update_payload_part2] payload 1 1 $ grep qlock debug14* debug14-10s:[ 1148.486445] [drm:set_hdr_from_dst_qlock] set_hdr_from_dst_qlock: failed to find slot debug14-10s:[ 1148.486449] [drm:process_single_down_tx_qlock] failed to send msg in q -11 debug14-11s:[ 1162.850656] [drm:set_hdr_from_dst_qlock] set_hdr_from_dst_qlock: failed to find slot debug14-11s:[ 1162.850657] [drm:process_single_down_tx_qlock] failed to send msg in q -11 debug14-11s:[ 1162.876006] [drm:set_hdr_from_dst_qlock] set_hdr_from_dst_qlock: failed to find slot debug14-11s:[ 1162.876007] [drm:process_single_down_tx_qlock] failed to send msg in q -11 debug14-11s:[ 1162.876144] [drm:set_hdr_from_dst_qlock] set_hdr_from_dst_qlock: failed to find slot debug14-11s:[ 1162.876145] [drm:process_single_down_tx_qlock] failed to send msg in q -11 debug14-11s:[ 1174.216766] [drm:set_hdr_from_dst_qlock] set_hdr_from_dst_qlock: failed to find slot debug14-11s:[ 1174.216767] [drm:process_single_down_tx_qlock] failed to send msg in q -11
For the record, I'm adding some debugging output to the affected modules in an attempt to isolate the issue. Will report back with patch if possible.
Jim or Derek have you seen this error still? Have you tried a more recent kernel? (suggest to try with latest) Once submitted information please remove the NeedInfo status and move it Reopen
based on the lack of activity and a response from the submitter to update results with latest configuration the bug will be closed
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.