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 Once in a while, one of the external monitors "desynchronizes" and blanks (in a very peculiar fashion, detailed below), only to restore its image quickly afterwards. This happens on both of my external displays (never on the laptop screen), about once every 15 minutes (sometimes more frequently, sometimes less). A video of the blanking: http://users.elis.ugent.be/~tbesard/public/mst-desync.mp4 This is a 4x slowed down recording of my screen blanking. Note that just before my screen blanks, it kinda "desynchronizes" (clearly visible at 3.4s). In some cases, this phenomena is way stronger, eg. straight lines go all wobbly for a full second, then seem to go back to normal for a while, but the screen still blanks quickly after that. Also interesting is how the screen blanks, it *always* happens in this two-step fashion as seen in the video: ~.25s blank, ~.5s normal again, ~2s blank. Very occasionally (once a week) the screen in question remains dead after all this. I have been tracking Dave Airlie's MST patches since they first arrived on his 3.14 branch kernel on fdo, and I distinctly remember this bug not being there in the first weeks on being able to drive my external displays. However, I have not been able to go back to that stable situation, despite trying all of the old branches (starting at drm-i915-mst-v3.14) and patchsets. I haven't tried to revert my xorg driver though (because of it being relatively hard due to ABI dependencies). Sadly, I cannot provide much more information, no additional messages are generated in dmesg (booting with drm.debug=0x06). I've posted some more information (register snapshots, opregions) in bug #89612, which is otherwise unrelated but happens to be on the exact same hardware.
I presume it is a DP link retraining event that starts the snowball rolling. If you keep drm.debug=6 active and then grab the dmesg once the proverbial hits the fan, that would help.
I am already keeping drm.debug=6 on all the time (0x06 actually, but that should be the same) but I'm not seeing any drm messages whatsoever in dmesg when a screen blanks.
I even tried booting with drm.debug=0xf, which generates a crapton of messages, but nothing out of the ordinary (ie. only some I915_GEM_* noise) around the time that my screens blank. Is there another way for me to gather more information, or enable more debug messages?
Any news about this issue? The status is NEEDINFO, but what can I still provide? The requested dmesg with drm.debug=6 doesn't contain any specific messages around the time of the blanking, so the one I've posted in bug #89612 should contain the necessary information. I've also been keeping track of new kernels, and currently the issue still happens on git master (4.0 rc6).
Another ping, seeing how the status of this bug is still NEEDINFO... Currently running Linux 4.2.2 with Xserver 1.17.2 and Intel driver 2.99.917 from commit 4e668dd (that's what Arch ships). It kinda sucks to have my screens blank every few minutes. Given some pointers, I even would want to try and have a look at the code myself, but I'm not familiar with either kernel or X development (let alone DisplayPort) so that seems like an unproductive thing to attempt.
Please try newer kernels (say, v4.3-rc5 or drm-intel-nightly branch of http://cgit.freedesktop.org/drm-intel) and attach dmesg with drm.debug=14.
Just tried 4.3.0-rc5-ge3be426, same symptoms. although I have the impression blanking occurs less frequently. But as with other kernels, the blanking event doesn't generate any dmesg entry (with drm.debug=14).
Please attach dmesg all the way from boot to the problem, with drm.debug=14 module parameter.
Created attachment 118853 [details] dmesg log on 4.3-rc5 with drm.debug=14 (at least 2 blank events happened during logging) Log is attached. At least 2 blank events happened during the time of logging not corresponding with any specific lines in the log.
I tried the drm-intel-nightly branch yesterday (4.4.0-rc3-g31ade3b) but I'm still seeing the same behaviour. Seeing this bug is still NEEDINFO, and pointers on how I can log even more? Current suggestions (drm.debug=..) don't result in logs containing anything special around the time of blanking.
I gave up on this configuration working reliably and have moved to a different hardware configuration, so I won't be able to test this anymore.
Closing as wontfix due to the submitter moving to other HW. If anyone else has this same bug with the latest upstream driver/kernel, please open a new bug.
(In reply to dog from comment #12) > Closing as wontfix due to the submitter moving to other HW. If anyone else > has this same bug with the latest upstream driver/kernel, please open a new > bug. Closing 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.