My Lenovo ThinkPad T440p is docked to a Lenovo ThinkPad Ultra Dock (40A20135EU, firmware 2.17) with two external monitors attached via DVI / DisplayPort. The current (as of 2014-08-04) DP MST patches are in place, but when initially logging into my KDE session both external monitors turn off and only start producing an image after briefly unplugging the dock's power adapter. The dmesg output shows an error (but I do not know whether it is related): "[drm:intel_uncore_check_errors] *ERROR* Unclaimed register before interrupt / Unclaimed register detected before reading register 0x44018" (for details, refer to attached dmesg output). System environment: -- chipset: QM87 -- system architecture: x86_64 -- xf86-video-intel/xserver/mesa/libdrm version: - xf86-video-intel: 2.99.914 - xserver: 1.15.1 - mesa: 10.1.3 - libdrm: 2.4.52 -- kernel version: 3.16.0-rc6-tg+ (built from drm-next-nightly @ 2014-08-04) -- Linux distribution: Kubuntu 14.04 -- Machine or mobo model: Lenovo ThinkPad T440p 20AN -- Display connector: DVI, DisplayPort 3) Reproduce steps. Boot system while docked. Log in to X session. External monitors attached to dock will turn off. Attachments will follow shortly (except for a VBIOS dump, which aborts with the following error in dmesg: "i915 0000:00:02.0: Invalid ROM contents"). Please let me know if you need any further details or if I can help testing any experimental patches.
Created attachment 104022 [details] Xorg.0.log
Created attachment 104023 [details] dmesg (after displays have turned off)
Created attachment 104024 [details] intel_reg_dumper (after displays have erratically turned off)
Created attachment 104025 [details] intel_reg_dumper (when external displays are working correctly)
It looks like the command to disable the outputs is external. I've added some extra logging just in case we are actually doing output hotplugging, so please could you update to commit 941ae4c868279c994756a2a476af2cd32afc6d35 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Aug 5 10:19:05 2014 +0100 sna: Add some extra logging for hotplugging of outputs References: https://bugs.freedesktop.org/show_bug.cgi?id=82153 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk and attach the Xorg.0.log.
Chris, in which git repo is this commit located?
http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/
Created attachment 104095 [details] Xorg.log w/ debug logging from commit 941ae4c868279c994756a2a476af2cd32afc6d35
Just noticed that sometimes both external displays will work without any necessity workaround while collecting data for bug #82207. The interesting thing is that the kernel BUG from #82207 does not happen on logout in that case.
Ok, that is conclusively the DE that rearranges the monitor in several steps. I was worried that the hotplug event was triggering extraneous steps... However, in this case there was not a hotplug event during startup and we did not go through a stage with both external outputs disabled. So this is not quite the same sequence as earlier. Could you please try a few more times and look for an Xorg.0.log with "removing GPU device /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-DP-5 (null)" and/or "resizing framebuffer to 1920x1080"
Created attachment 104100 [details] Xorg.0.log My current Xorg.0.log contains both log messages. Based on the timing (starting at 84.479) this looks pretty much like the dock power cycle workaround triggering it.
Created attachment 104244 [details] xrandr --verbose I just noticed that I forgot to attach the `xrandr --verbose` output (captured while the error was present). The interesting thing is that xrandr thinks the external displays are connected (and the listed modes are actually correct), but they just remain dark.
The problem appears to be that the KMS state tracking is not reset across the unplug and so when we try to set the new mode after detecting the dock being powered on, they are converted into no-ops.
Closed after more than one year of inactivity. Feel free to reopen if needed. Thanks
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.