Created attachment 138317 [details] Linux 4.16-rc6+ messages from suspend and resume With Linux 4.16-rc6+ and mutter 3.28.0-2 from Debian Sid/unstable and a Dell XPS 13 9370 and docking station TB16, going in suspend and waking back up, the external monitor is not detected according to the output of `xrandr` until reconnected. It was also not detected during boot. Please find the Linux kernel messages from suspend and resume with `drm.debug=0x1e` attached.
As you know the TB16 is a Thunderbolt dock. I don't believe the DP tunnels are initialized unless the dock has been authorized. Can you please confirm what security level you have Thunderbolt configured in BIOS setup? The default is "user security" (SL1). If you are booting in SL1, please try to reconfigure to SL0 or SL3 and try again. If it works then I don't believe this is a problem in the DRM stack but rather in the userspace stack that is managing transferring boot ACL's. FYI there is a pull request being discussed related to this in the Intel thunderbolt tools project on Github. https://github.com/intel/thunderbolt-software-user-space/pull/59
(In reply to Mario Limonciello from comment #1) > As you know the TB16 is a Thunderbolt dock. I don't believe the DP tunnels > are initialized unless the dock has been authorized. I don't think that is true, at least not in my experiments with a combination of the T470s and the Lenovo Thunderbolt 3 dock. The DP links were created independently of security level. There are a few people reporting issues with the TB16 and the XPS13 and external displays inside RH. Some report it as a regression when upgrading to F28. The current working hypothesis is that it might be related to MST. Lyude has been doing some where in that area lately.
(In reply to Mario Limonciello from comment #1) > As you know the TB16 is a Thunderbolt dock. I don't believe the DP tunnels > are initialized unless the dock has been authorized. […] Before I read up on that, can you please confirm, that replugging the DP cable fixing the problem, doesn’t contradict your hypothesis?
I can confirm a similar experience on Fedora 28/GNOME/Wayland. The external monitor works during boot (Plymouth) and on the login screen (GDM), but once I log into a session the external monitor goes black after a few blinks. If I restart the dock at this moment (with the system up and running and logged into the session) the external monitor gets back on and stays that way. But this is with a special build of mutter with a couple of drm patches reverted. The default experience on F28 is a completely frozen system (gnome-shell taking 100% of cpu) which you can only hard-reboot. It works on Xorg until resuming from suspend and the original post says. Tested on several machines, Thunderbolt security definitely doesn't stand in the way because I have had the security level set to 'none' and other connected USB devices work for me.
Thunderbolt security is set correctly in my setup and I have roughly the same setup as the above comment. I cannot resume from suspend or hibernate without eventually freezing due to some i915 driver issues. Replugging does *not* help. After 4.15.10+, resume is not working when attached to the dock or even if you detach prior to suspend/hibernate and do not reattach until after resume. I also consistently do not have USB working after resume in almost any scenario. I'm running standard module settings. Even software level bind/rebinds do not help. I cannot resume or suspend (I'll take either one of them working) once the dock has been introduced into the equation in some way. I must reboot sooner rather than later. If I hotplug after booting, I get 1-2 cycles of each monitoring blinking before it keeps all the monitors on. I have 2 external monitors and keep the laptop monitor on as a 3rd. Some of the last spins 4.14 worked pretty good for the dock but 4.15.x has been consistently difficult.
I'm on f27/gnome/wayland.
First of all. Sorry about spam. This is mass update for our bugs. Sorry if you feel this annoying but with this trying to understand if bug still valid or not. If bug investigation still in progress, please ignore this and I apologize! If you think this is not anymore valid, please comment to the bug that can be closed. If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
Paul, can you test latest drm-tip now? See: https://bugs.freedesktop.org/show_bug.cgi?id=104425
Closing, please re-open if occurs again.
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.