Screens wake up immediately after going to sleep

Brief summary of the problem:

Every time I try to lock/screen set dpms to off/suspend the monitors go into very short sleep and wake up again The syslog generates a single line: [drm] REG_WAIT timeout 1us * 100000 tries - mpc2_assert_idle_mpcc line:480 for every attempt

Hardware description:

• CPU: AMD Ryzen 7 2700 Eight-Core Processor
• GPU: Navi 10/ AMD 5700 XT
• System Memory: 64 GB
• Display(s): Viewsonic 2419
• Type of Diplay Connection: 3xHDMI, 2xDP

System infomration:

• Distro name and Version: Ubuntu 20.10
• Kernel version: 5.8.0-30-generic #32 (closed) SMP Wed Nov 18 03:00:45 GMT 2020 x86_64 x86_64 x86_64 GNU/Linux
• Custom kernel: 5.8.0-30-generic #32 (closed) SMP Wed Nov 18 03:00:45 GMT 2020 x86_64 x86_64 x86_64 GNU/Linux
• Upgraded to Ubuntu 21.04 Linux aldur 5.11.0-17-generic #18 (closed)-Ubuntu SMP Thu May 6 20:10:11 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
• AMD package version: xserver-xorg-video-amdgpu 19.1.0-2

How to reproduce the issue:

Install multiple monitors and issue "xset dpms force off" or lock the screen

I have a similar setup with 4 monitors but I'm using Wayland. My screens have been sleeping just fine, but I have noticed a bunch of those messages in dmesg

Are are not experiencing this issue then. I don't think the messages are directly related.

Same issue here, getting: [drm] REG_WAIT timeout 1us * 100000 tries - mpc2_assert_idle_mpcc line:480 every time i run xset dpms force off

This issue only happens when DisplayPort(not DisplayLink) monitors are connected, unplugging all DisplayPort monitors allow screens to blank ok.

• CPU: AMD Ryzen 7 2700
• GPU: Navi 10/ AMD 5700 XT
• System Memory: 64 GB
• Display(s): used to be Viewsonic 2419 moved to Philips 243V7
• Type of Display Connection: 3xHDMI, 3xDP

System infomration:

• Distro name and Version: Ubuntu 20.10
• Kernel version: 5.8.0-30-generic #32 (closed) SMP Wed Nov 18 03:00:45 GMT 2020 x86_64 x86_64 x86_64 GNU/Linux
• Custom kernel: 5.8.0-30-generic #32 (closed) SMP Wed Nov 18 03:00:45 GMT 2020 x86_64 x86_64 x86_64 GNU/Linux
• AMD package version: xserver-xorg-video-amdgpu 19.1.0-2

@bsorceror I think you just replied to your own issue :)

I see this exact same message on my machine, but I'm not experiencing any issues. I found this thread hoping to figure out what it meant. I have a Ryzen w/5700 XT, and I'm using 3x DP + 1x HDMI. They're all Dell U2415

I did previously have issues with one of the monitors and DP1.2. I disabled DP1.2 on the Dell U2415 with issues and screen off is working perfectly now

Duplicate of #662 ?

I'm having what appears to be the same issue on Ubuntu 21.04, kernel 5.11... But I don't get the mentioned error. I expect they may be unrelated, as other people has suggested.

For my monitor (connected through a DP -> HDMI adapter) there's a hot-unplug and a hotplug event triggered, which causes everything to wake up again, but only on Wayland; on X that seems to be filtered out. Ignoring hotplug events while DPMS should stay off in kwin_wayland solves the issue.

@agd5f as I understand it these hotplug events are part of the DisplayPort spec. Is that supposed to be forwarded to userspace?

The gpu drivers generate uevents for display plug/unplug events. Userspace can listen for the events and do something with them (e.g., pop up a dialog saying a display has been attached, etc.).

What I'm asking is where the DisplayPort events that are caused by DPMS off (which is disconnect + connect immediately afterwards) should be filtered out, as currently the kernel doesn't do that. I just want some confirmation about whether or not that is considered a kernel bug or if that is supposed to be done in userspace (which is very easy to do in KWin but I don't know how the situation is for other compositors).

You should only get hotplug events for physical plug/unplug events. There is no event for dpms. Once thing that can happen however, is that when the display enters dpms off, some displays will start polling the inputs on the monitor to detect if someone has plugged something into one of the other inputs. This polling an sometimes trigger spurious hotplug events because it looks like a physical change on the hotplug pin to the driver.

Okay, thanks. My display has no inputs though, so the DP->HDMI adapter probably causes it.

How prevalent are these issues / how likely do you think they can be fixed in the foreseable future? From #662 it looks like this sort of things affects quite a lot of hardware.

updated to 5.11 (ubuntu 21.04) still have the same issue with the same error message

I think the error message is related as it shows every time(multiple lines) when I issue xset dpms foce off/standaby and the screens come back to life after that (which lasts a total of about 5 seconds - due to monitor wakeup delay)

changed the description

@mishan how did you disable dp 1.2 ?

@bsorceror I have Dell monitors. In the monitors' settings (in the OSD menu), there is an option to disable DP 1.2. YMMV with your monitors.

@tmuncks I don't believe this to be a duplicate of #622 (closed) as changing DC kernel boot option does not help.

Thanks, my monitors don't have that option.I might try a cable that doesn't support 1.2

This issue hasn't had any activity since 2021-05-15. The AMD driver stack changes rapidly and contains lots of shared code across products so it's possible that it has already been fixed. Please upgrade to a current stable kernel and userspace stack and try again. If you still experience this issue with the latest driver stack, please capture relevant logging and open a new issue referring back to this one.

closed