| Summary: | MST displays fail to wake | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Dan Doel <dan.doel> | ||||||||
| Component: | DRM/Radeon | Assignee: | Default DRI bug account <dri-devel> | ||||||||
| Status: | RESOLVED MOVED | QA Contact: | |||||||||
| Severity: | normal | ||||||||||
| Priority: | medium | ||||||||||
| Version: | XOrg git | ||||||||||
| Hardware: | x86-64 (AMD64) | ||||||||||
| OS: | Linux (All) | ||||||||||
| Whiteboard: | |||||||||||
| i915 platform: | i915 features: | ||||||||||
| Attachments: |
|
||||||||||
Created attachment 125465 [details]
dmesg output with drm.debug=0xe
Adding (compressed) dmesg output with drm.debug=0xe on the kernel boot line. Careful extracting it, it's 502MB decompressed. Unfortunately, I couldn't seem to make the problem happen faster than over night.
Don't know if this will help or not, but it can't hurt, I suppose.
So, I decided to turn off one of my monitors for a bit, and I haven't experienced this bug even after almost 3 days uptime. So, this seems to specifically affect setups with multiple monitors, and probably only multiple MST monitor setups. Turns out I was wrong. It does still happen with a single display, but it takes much longer. After over 6 days of uptime, my single display failed to wake up. I'll attach dmesg output for that case. It appears that the numbers in the debug message don't go way up when the problem happens with a single display. So I guess maybe that isn't as much of a clue as I'd hoped. Created attachment 125935 [details]
dmesg output with a single MST monitor
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/730. |
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.
Created attachment 125450 [details] dmesg output Since moving to kernel 4.6, I've been having regular problems with my MST monitors failing to wake after being put to sleep. This only seems to occur after the machine has been on for a sufficient amount of time, but I usually experience it within a day of booting, and typically after the displays have been powered off for an extended period of time. There are two MST monitors, but typically only one fails to wake. Also, it is more often that the secondary display is the one that fails. However, I have had the primary display fail to come back (while the secondary one succeeds), and I have had both fail to come back as well. Sometimes, only a complete power off is able to make the monitors wake up; a reboot is not always sufficient. The dmesg displays some errors, and I've poked around a bit. It seems likely that this is related to commit f3d58dccdbf9f8c0a229d555d4b295d52e743039, which was first included in 4.6. This commit basically causes dpms to work at all with MST monitors; before it was a no-op that didn't actually put the monitors into power saving. That doesn't help narrow the problem down much, though, since a significant portion of the mst dpms code probably wasn't being exercised before that. Also, it seems notable that the error message (which seems more like a debug message) in the STANDBY/SUSPEND/OFF case keeps reporting higher numbers, as though it keeps going through the ON case, which increments the variable, but not making it through the portion of the OFF case that decrements the variable. I'll attach dmesg journal output that might be relevant. I believe the error/debug messages timestamped 'Jul 31 11:03:49' correspond to the first time one of the displays failed to wake up. I tried various ways of toggling the dpms off and on after that, so those are the subsequent error messages in the log. As far as specs go, I have: Radeon HD7870 (Pitcairn) Kernel 4.6.4 (4.6.3 also affected) 2 UP2414Q mst displays xorg-server 1.18.4 Modesetting driver Let me know if there's any more information I can try to provide.