Created attachment 169651 [details] journalctl output showing disconnect and following reboot to recover I have a display port monitor running at 2560x1440 60Hz that my laptop will randomly disconnect from. When this occurs the following error shows up in the system log: [drm:drm_dp_get_mst_branch_device] *ERROR* failed to lookup MSTB with lct 2, rad 00 The only recovery I have been able to manage on a consistent basis is to restart the machine (and monitor it seems). Obviously not much of a workaround. The last time this occurred I was able to fix this by disabling the display with xrandr for awhile, then turning it back on. This last time this did not work, and doing that a few times actually hard-locked the system.
I can only see references to an Intel GPU in the attached log, so the component field of this report is set incorrectly.
Created attachment 169951 [details] Second journalctl dump from disconnect Attaching a second log from most recent disconnect. This seems to have a new type of error in it which I haven't seen before: Mar 09 05:49:31 procyon /etc/gdm/Xsession[5551]: [7977:7977:0309/054931:ERROR:display_info_provider_aura.cc(28)] Not implemented reached in virtual void extensions::DisplayInfoProviderAura::UpdateDisplayUnitInfoForPlatform(const gfx::Display &, extensions::core_api
Kernel 3.19.3 I can confirm that similar things with that kernel error message is happening here as well. apr 08 12:25:10 papaya kernel: [drm:drm_dp_get_mst_branch_device.isra.17 [drm_kms_helper]] *ERROR* failed to lookup MSTB with lct 2, rad 00 I have an LG 27" 2560 http://www.lg.com/us/monitors/lg-27EA83-D-led-monitor connected to DELL PR02X dock via DisplayPort. * After docking the laptop, if the monitor was powered on and sitting in standby, all xrandr activation attempts fail with "*ERROR* failed to lookup MSTB with lct 2, rad 00" * After docking the laptop, I always have to power cycle the monitor in order for xrandr --output DP1-1-8 --auto to succeed. See above. MST implementation has been very flaky from the time it was implemented, but I do understand it's more like prototype stage thing still and not enough resource is available to make it more bulletproof. I've been able to crash the whole display system with just xrandr-based display connection management consistently, as in the screen goes completely blank with no way to bring it back. Sucks a lot for being able to trust Linux with the basics, as a business mobile desktop platform. Some more adventures for those interested https://bugs.freedesktop.org/show_bug.cgi?id=85913
Forgot to say, on topic of the bug title, I'm also experiencing occasional random monitor disconnections in the middle of work.
Long time no updates, closing. If the problem persists with latest kernels, please file a bug at the freedesktop.org bugzilla [1], referencing this bug. Thank you. [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel