Bug 107731 - radeon (amdgpu) DisplayPort loss of max-resolution on DP monitor (after monitor power saving / idle)
Summary: radeon (amdgpu) DisplayPort loss of max-resolution on DP monitor (after monit...
Status: NEW
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/AMDgpu (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-08-29 01:37 UTC by Fermulator
Modified: 2019-10-03 16:40 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg output post DP disconnect + reconnect to fix resolution (85.33 KB, text/plain)
2018-08-29 01:37 UTC, Fermulator
no flags Details
Logs with drm.debug=4. Looks like some DC validation failure. (180.90 KB, text/plain)
2019-03-17 08:08 UTC, L.S.S.
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Fermulator 2018-08-29 01:37:02 UTC
Created attachment 141328 [details]
dmesg output post DP disconnect + reconnect to fix resolution

as an extension of the story from:
 * https://bugs.freedesktop.org/show_bug.cgi?id=107560#c9

after a few kernel/driver upgrades and weeks later, that is no longer reproducible - and is instead replaced by lesser issues still plaguing the monitor connected via display port

$ uname -r
4.17.17-100.fc27.x86_64


noticed that the same monitor (connected via DisplayPort) had mis-match capabilities (wasn't able to go max resolution)

```
$ xrandr
Screen 0: minimum 320 x 200, current 3840 x 1200, maximum 16384 x 16384
DisplayPort-0 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1920x1080     59.95* 
   1600x1200     59.95  
   1680x1050     59.95  
   1280x1024     59.95  
   1440x900      59.95  
   1280x800      59.95  
   1280x720      59.95  
   1024x768      59.95  
   800x600       59.95  
   640x480       59.95  
HDMI-A-0 disconnected (normal left inverted right x axis y axis)
DVI-D-0 connected 1920x1200+1920+0 (normal left inverted right x axis y axis) 518mm x 324mm
   1920x1200     59.95*+
   1920x1080     59.95  
   1600x1200     60.00  
   1680x1050     59.95  
   1280x1024     60.02  
   1440x900      59.95  
   1280x960      60.00  
   1280x800      59.95  
   1280x720      59.95  
   1024x768      60.00  
   800x600       60.32    56.25  
   640x480       59.94  
```

The "   1920x1200     59.95*+" option is missing from the display port monitor.

If I disconnect the DP, and reconnect, it comes back.

```
$ xrandr | grep +
DisplayPort-0 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm
   1920x1200     59.95*+
DVI-D-0 connected 1920x1200+1920+0 (normal left inverted right x axis y axis) 518mm x 324mm
   1920x1200     59.95*+
```

---
$ dnf info xorg-x11-drv-amdgpu
Failed to synchronize cache for repo 'mosquito-atom', disabling.
Failed to synchronize cache for repo 'region51-chrome-gnome-shell', disabling.
Failed to synchronize cache for repo 'spacewalk-client', disabling.
Last metadata expiration check: 20 days, 23:02:26 ago on Tue 07 Aug 2018 11:04:16 AM EDT.
Installed Packages
Name         : xorg-x11-drv-amdgpu
Version      : 18.0.1
Release      : 1.fc27
Arch         : x86_64
Size         : 147 k
Source       : xorg-x11-drv-amdgpu-18.0.1-1.fc27.src.rpm
Repo         : @System
From repo    : updates
Summary      : AMD GPU video driver
URL          : https://www.x.org/wiki
License      : MIT
Description  : X.Org X11 AMDGPU driver

$ rpm -qa | egrep "amdgpu|gdm|dri-|xorg-x11-server|gnome-session"
mesa-dri-drivers-17.3.9-1.fc27.x86_64
xorg-x11-server-utils-7.7-23.fc27.x86_64
xorg-x11-drv-amdgpu-18.0.1-1.fc27.x86_64
gnome-session-3.26.1-1.fc27.x86_64
gdm-3.26.2.1-3.fc27.x86_64
gnome-session-xsession-3.26.1-1.fc27.x86_64
xorg-x11-server-Xephyr-1.19.6-7.fc27.x86_64
gnome-session-wayland-session-3.26.1-1.fc27.x86_64
pulseaudio-gdm-hooks-12.2-1.fc27.x86_64
xorg-x11-server-Xorg-1.19.6-7.fc27.x86_64
xorg-x11-server-common-1.19.6-7.fc27.x86_64
xorg-x11-server-Xwayland-1.19.6-7.fc27.x86_64
Comment 1 L.S.S. 2019-03-10 07:44:28 UTC
Having similar issues with Manjaro Linux (4.20 Kernel) and AMD video cards.

I've a 4K@60Hz capable monitor (Lenovo ThinkVision P27) and an ATEN CS1924 KVM behind it (as I need to use this monitor for 4 different PCs). I've two PCs with Manjaro Linux and AMD GPU, and I can 100% reproduce the issue on both of them.

This happens whenever I power off the monitor (or when it went idle). After powering the monitor back on, it reverts to a lower resolution (During most cases, xrandr reported max 2048x1536 but it actually picked 1792x1344. Recently I also noticed sometimes xrandr would report only 800x600).

It can be fixed by switching the input channel back and forth on the KVM (which I think is equivalent to unplugging and replugging the DP port).

On one of the PCs, it used to have an nVidia video card before replacing it with Radeon VII. With an nVidia video card, this issue did not occur (using same configuration).

When this happens, I can find this red line in dmesg. Other log entries are mostly about on-monitor USB hubs and such, and they're irrelevent to the issue from the look of it.

[drm:dm_restore_drm_connector_state [amdgpu]] *ERROR* Restoring old state failed with -22
Comment 2 L.S.S. 2019-03-10 07:48:30 UTC
Some extra information.

uname -r
4.20.11-1-MANJARO

The correct xrandr output:

Screen 0: minimum 320 x 200, current 3840 x 2160, maximum 16384 x 16384
DisplayPort-0 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 596mm x 335mm
   3840x2160     60.00*+  29.98  
   2560x1600     74.97    59.97  
   2560x1440     59.95  
   1920x1440     75.00    60.00  
   1856x1392     75.00    60.00  
   1792x1344     75.00    60.00  
   2048x1152     60.00  
   1920x1200     74.93    59.88  
   1920x1080     60.00    60.00    50.00    59.94  
   1600x1200     75.00    70.00    65.00    60.00  
   1680x1050     74.89    59.95  
   1400x1050     74.87    59.98  
   1600x900      60.00  
   1280x1024     75.02    60.02  
   1440x900      74.98    59.89  
   1280x960      60.00  
   1366x768      59.79  
   1360x768      60.02  
   1280x800      74.93    59.81  
   1152x864      75.00  
   1280x768      74.89    59.87  
   1280x720      60.00    50.00    59.94  
   1024x768      75.03    70.07    60.00  
   800x600       72.19    75.00    60.32    56.25  
   720x576       50.00  
   848x480       60.00  
   720x480       60.00    59.94  
   640x480       75.00    72.81    60.00    59.94  
   720x400       70.08  

The "incorrect" xrandr output (after power-cycling the monitor):

Screen 0: minimum 320 x 200, current 1792 x 1344, maximum 16384 x 16384
DisplayPort-0 connected primary 1792x1344+0+0 (normal left inverted right x axis y axis) 596mm x 335mm
   1792x1344     60.00* 
   2048x1152     60.00  
   1920x1200     59.88  
   1920x1080     60.00    60.00    50.00    59.94  
   1600x1200     75.00    70.00    65.00    60.00  
   1680x1050     74.89    59.95  
   1400x1050     74.87    59.98  
   1600x900      60.00  
   1280x1024     75.02    60.02  
   1440x900      74.98    59.89  
   1280x960      60.00  
   1366x768      59.79  
   1360x768      60.02  
   1280x800      74.93    59.81  
   1152x864      75.00  
   1280x768      74.89    59.87  
   1280x720      60.00    50.00    59.94  
   1024x768      75.03    70.07    60.00  
   800x600       72.19    75.00    60.32    56.25  
   720x576       50.00  
   848x480       60.00  
   720x480       60.00    59.94  
   640x480       75.00    72.81    60.00    59.94  
   720x400       70.08  
DisplayPort-1 disconnected (normal left inverted right x axis y axis)
DisplayPort-2 disconnected (normal left inverted right x axis y axis)
HDMI-A-0 disconnected (normal left inverted right x axis y axis)
Comment 3 L.S.S. 2019-03-10 07:56:47 UTC
Forgot to mention this. Regardless of the circumstances, the EDID I got using "xrandr --prop" is identical to the one when the screen resolution is correct (4K@60Hz), so in my case, the monitor is always correctly identified, just that the resolutions aren't visible.
Comment 4 Harry Wentland 2019-03-11 16:07:29 UTC
Can you post a dmesg log with drm.debug=4?

I suspect it's because of a link training failure. drm.debug=4 should confirm that.
Comment 5 L.S.S. 2019-03-17 08:08:28 UTC
Created attachment 143701 [details]
Logs with drm.debug=4. Looks like some DC validation failure.

It seems when I power cycle the monitor, I get some "failed DC validation" errors. As for link training failure... yeah, just looked at the log and it did mention something like that.

I just upgraded my Linux systems to 5.0 kernel, and the problem persists there. The log is also done with 5.0 kernel on one of the systems.

The problem seems to be amdgpu/DC related as my Linux systems have AMD cards of different generations and are all affected by the issue (and 100% reproducible).
Comment 6 Harry Wentland 2019-03-18 20:08:18 UTC
Thanks. This is definitely a link training failure.

Can you see if your monitor is set to auto-select the input and force it to select the DP input? Some monitors don't respond well to link training when auto-cycling the inputs?
Comment 7 L.S.S. 2019-03-19 10:52:14 UTC
Unfortunately I cannot test this on my monitor (Lenovo ThinkVision P27). While it only has options for DP or HDMI input (no Auto select), it seems to actively cycle through the input signals when powering on, resuming from idle, or when there's no signal on either input.

The monitor in question doesn't appear to maintain the inactive link (as well as USB connection) when powering off, going idle, or switching input, from what I could find out. Before using a KVM (that I'm swapping between its HDMI and DP inputs that were connected to different places), whenever I switch the active signal, the built-in USB hub power-cycles (devices disconnect then reconnect), and the monitor becomes disconnected to the system connected to the now inactive signal.
Comment 8 Harry Wentland 2019-03-19 13:50:39 UTC
(In reply to L.S.S. from comment #7)

> from what I could find out. Before using a KVM (that I'm swapping between
> its HDMI and DP inputs that were connected to different places), whenever I
> switch the active signal, the built-in USB hub power-cycles (devices
> disconnect then reconnect), and the monitor becomes disconnected to the
> system connected to the now inactive signal.

Are you saying you're using a KVM in your setup?

Does the problem occur when the monitor is directly connected?
Comment 9 L.S.S. 2019-03-19 18:27:23 UTC
Just tested... it seems if I connect to the monitor directly the problem doesn't occur.

Guess the KVM does play a part in this. However, I still need the KVM as I've four PCs connected to this monitor.

It's not a major issue as switching it back and forth would put the system back to the correct resolution, and it currently doesn't have any serious impacts. Just that I'm wondering why this problem is only happening on AMD video cards and not on nVidia video cards.
Comment 10 Alex Deucher 2019-03-19 19:18:02 UTC
(In reply to L.S.S. from comment #9)
> Just tested... it seems if I connect to the monitor directly the problem
> doesn't occur.
> 
> Guess the KVM does play a part in this. However, I still need the KVM as
> I've four PCs connected to this monitor.
> 
> It's not a major issue as switching it back and forth would put the system
> back to the correct resolution, and it currently doesn't have any serious
> impacts. Just that I'm wondering why this problem is only happening on AMD
> video cards and not on nVidia video cards.

Possibly different behavior in the the hw or hw settings on what is considered a short vs. long pulse for DP.
Comment 11 L.S.S. 2019-03-22 17:28:27 UTC
So is there a possible workaround for monitors/KVMs that could cause this issue? Sadly for 4-port DisplayPort KVMs with working 4K@60 there are very few alternatives... most are either only DP 1.1 or only 4K@30.

Although I have to admit that this KVM (ATEN CS1924) is notoriously picky when it comes to cables... only stock cables or some highly expensive DP1.4 cables could make 4K@60 output work stable, but stock cables are only about 2m and in reality I needed a few 3m cables (which cost me a handful to get the right cables for the job) as some of the PCs are placed a bit far away from the KVM.
Comment 12 L.S.S. 2019-05-22 00:58:59 UTC
Sorry, but should have commented on this much sooner.

After my last comment I eventually replaced the ATEN CS1924 KVM with a new generic 4-port KVM that is 4K@60Hz-capable. This one does not exhibit the issue, so I could consider my own issue as having been worked around. The new KVM costs about 1/4 of the ATEN KVM, though.

I'm not sure about the OP's situation or whether he had worked around or not, but this kinda proved that the issue is indeed configuration-specific.
Comment 13 Fermulator 2019-05-22 02:20:25 UTC
Sorry I no longer have access to the system originally reported this issue from.
Comment 14 James Wood 2019-10-03 16:40:14 UTC
I was about to report having the same bug but it seems the today's Mesa 19.2.0-2 update has solved the problem, I will include what I was originally going to post in case it's of use to anyone.

---

I've began to have this bug in the last week or two, I have two monitors one an Asus PA238 connected via DVI has no issues, the other a AOC 2270W connected via DP changes to a lower resolution after wakeup, typically 800x600 which cannot be changed back to normal.

I can reproduce this consistently by using 'xset -display :0 dpms force standby' and waiting about one minute.
Running 'xrandr --output DisplayPort-2 --auto' restores the display to its normal native resolution.

The system log shows the following error:
[drm] enabling link 2 failed: 15
[drm:dm_restore_drm_connector_state [amdgpu]] *ERROR* Restoring old state failed with -22
Stack trace: https://pastebin.com/yguN5NUk

System specification:
OS: Arch linux 5.3.1-arch1-1-ARCH
GPU: AMD Radeon RX 590 using AMDGPU-Pro
DE: KDE Plasma 5.16.5


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.