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

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)

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.

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.

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).

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?

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.

(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?

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.

(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.

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.

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.

Sorry I no longer have access to the system originally reported this issue from.

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

-- 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/500.