Created attachment 114389 [details] dmesg after booting on 3.14 + MST patches, with drm.debug=14 I'm using Arch Linux (shipping xf86-video-intel 2.99.917 and xorg-server 1.17.1) on my T440s with two external Dell 24" monitors connected over both DVI and DP to a docking station. This specific docking station (official Ultra dock) uses DP MST to wire the external connections. When connected to the external displays, I'm not using my laptops screen (lid closed). I'm configuring my external screens as follows: $ xrandr --output DP2-2 --auto --output DP2-1 --auto --right-of DP2-2 If I disable my external screens using: $ xrandr --output DP2-1 --off --output DP2-2 --off ... and I try to revive them afterwards using: $ xrandr --output DP2-2 --auto --output DP2-1 --auto xrandr responds with "Configure crtc 1 failed" and both my external screens refuse to turn on. I tested this on the 3.19 kernel Arch linux ships, as well as the initial 3.14 + MST patches from Dave Airlie's git tree, but I'm seeing identical behaviour on both kernels. Attached are multiple files: * dmesg.log: boot-up dmesg on 3.14 with drm.debug-14 (as per Fedora reporting guidelines) * dmesg.xrandr.log: relevant drm debug statements from dmesg around the xrandr commands detailed above * dri_*_i915_opregion, lspci.log, Xorg.0.log: as per Fedora's guidelines again * reg_snapshot_*: register snapshots *before* doing anything (laptop screen off, both external displays enabled), *after* issuing the "xrandr --off" (and opening my laptop screen in order to see something), and after trying "xrandr --auto" and seeing a *failed* message Note that when I was recording the register snapshots above, and rebooting after nuking my external displays with "xrandr --off", I briefly got to see my init system output on one of my external screens just before the system rebooted.
Created attachment 114390 [details] dmesg DRM debug info around relevant xrandr commands
Created attachment 114391 [details] /sys/kernel/debug/dri/0/i915_opregion
Created attachment 114392 [details] /sys/kernel/debug/dri/64/i915_opregion
Created attachment 114393 [details] register snapshot before issueing any command (laptop display off, 2 external displays on)
Created attachment 114394 [details] register snapshot after issueing xrandr --off and opening my laptop (laptop display on, 2 external displays off)
Created attachment 114395 [details] register snapshot after trying xrandr --auto (laptop display on, 2 external displays still off)
Created attachment 114396 [details] /sys/kernel/debug/dri/0/i915_opregion
Created attachment 114397 [details] /sys/kernel/debug/dri/64/i915_opregion
Created attachment 114398 [details] bzipped register snapshot before issueing any command (laptop display off, 2 external displays on)
Created attachment 114399 [details] bzipped register snapshot after issueing xrandr --off and opening my laptop (laptop display on, 2 external displays off)
Created attachment 114400 [details] bzipped register snapshot after trying xrandr --auto (laptop display on, 2 external displays still off)
I messed up the attachments, fixed now. Sorry for the spam.
Kernel says that DP-3/DP-4 (mst DP2-1/DP2-2) can be cloned and fails without reporting why. If you did $ xrandr --output DP2-2 --auto --output DP2-1 --auto --right-of DP2-2 again, it should have worked.
So you're saying a second "xrandr --auto" should have fixed the issue? I just tried, and my external displays remained off. Will be attaching dmesg log below.
Created attachment 114431 [details] dmesg DRM debug info when trying an xrandr --auto twice
No, not a second "xrandr --auto" but "xrandr --output DP2-2 --auto --output DP2-1 --auto --right-of DP2-2"
That's what I did; I shouldn't have abbreviated the commands.. Just to be clear, every time I mentioned "xrandr --off" I executed: $ xrandr --output DP2-1 --off --output DP2-2 --off ... and "xrandr --auto" maps to: $ xrandr --output DP2-2 --auto --output DP2-1 --auto (adding `--right-of DP2-2` to that last command doesn't change a thing)
Just to be clear, can you attach a dmesg for the repeated "--right-of" xrandr? Earlier the logs show that DP2-1 and DP2-2 were being assigned to the same CRTC, which can only happen if they occupy the same position in the framebuffer. I think the full workaround would be: xrandr --output DP2-2 --preferred --crtc 1 --output DP2-1 --preferred --crtc 2 --right-of "DP2-2"
Will do. In the meanwhile, I discovered that restarting X actually fixes the issue. In summary: * boot system, configure MST external screens * turn off screens with xrandr * try to turn on external screens with xrandr --> configure crtc 1 failed * restart X --> both my external screens turn on again, but still in "clone" because I only call "xrandr ... --right-of ..." as part of my xprofile * log in, xprofile calls xrandr, external screens work properly again I'll be attaching a dmesg log detailing the steps above. I've pinpointed major events in the log (search for "xrandr" or "restart X"), but due to there being _a lot_ of messages I couldn't spot where the "xrandr ... --right-of" gets called after restarting X. These latest logs are on 4.0 from git btw, which shows the same behaviour.
Created attachment 114434 [details] dmesg DRM debug info when doing the xrandr commands and restarting X (which fixes the issue)
Created attachment 114435 [details] dmesg DRM debug info when trying an xrandr --auto, as requested Extra log as requested. The workaround xrandr (specifying the --crtc) works properly indeed.
Please re-test running v4.4. If the problem persists, please add drm.debug=14 module parameter, and attach dmesg.
I gave up on this configuration working reliably (mostly due to #89658) and have moved to a different hardware configuration, so I won't be able to test this anymore, sorry.
(In reply to Tim Besard from comment #23) > I gave up on this configuration working reliably (mostly due to #89658) and > have moved to a different hardware configuration, so I won't be able to test > this anymore, sorry. then closed as won't fix
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.