Bug 109246 - HDMI connected monitors fail to sleep and instead turn back on when amdgpu.dc=1
Summary: HDMI connected monitors fail to sleep and instead turn back on when amdgpu.dc=1
Status: NEW
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/AMDgpu (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-08 05:09 UTC by tme
Modified: 2019-01-19 05:52 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Xorg log (75.92 KB, text/plain)
2019-01-08 17:13 UTC, tme
no flags Details
dmesg output (86.92 KB, text/plain)
2019-01-08 17:15 UTC, tme
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description tme 2019-01-08 05:09:31 UTC
Original launchpad thread: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1790861

  Overview:
When my computer tries to suspend my monitors after a period of idleness, they'll suspend for a few seconds before waking back up.

  Steps to Reproduce:
1) Have a monitor attached over HDMI.
2) Set screen energy saving (in Plasma 5) to 1 minute.
3) After 1 minute has passed, the monitor will try to enter sleep mode. It will fail and turn back on.
4) The monitor will continue to attempt to enter sleep mode every minute until interrupted by the user.

  Actual Results:
The monitors turn back on a few seconds after entering sleep mode.

  Expected Results:
The monitors stay in sleep mode.

  Additional Information:
While I have two monitors, this issue is only triggered when one is connected using HDMI. Connecting only one monitor using HDMI will trigger the problem. Connecting either one using DVI does not trigger the problem. 
I am unable to test if DisplayPort triggers the problem, as I have no compatible monitors.
Setting the kernel parameter amdgpu.dc=0 does not cause the problem to trigger.

I haven't confirmed if the other affected users in the launchpad thread are using HDMI, so I'm only reporting my experience.
Comment 1 tme 2019-01-08 05:23:20 UTC
Forgot to mention that I have tested and reproduced this bug on kernel versions 4.18, 4.20, and 5.0-rc1.
Comment 2 fin4478 2019-01-08 08:02:32 UTC
I am tired to automatic monitor sleep problems and made a launcher to manually sleep the monitor.

#! /bin/bash

sleep 5s
xset dpms force standby
Comment 3 Michel Dänzer 2019-01-08 09:11:04 UTC
Please attach the output of dmesg and the Xorg log file, captured after reproducing the problem.
Comment 4 fin4478 2019-01-08 12:58:34 UTC
Use the DVI connector then. The HDMI development has a low priority. Developers use the display port connector and it is computer oriented while HDMI is for consumer electronics. I did sold my HDMI only monitor because of this. The ASUS VP28UQG monitor is really nice and freesync works.
Comment 5 Alex Deucher 2019-01-08 14:29:32 UTC
Do you have an option in your monitor's menu to poll inputs?  If so can you disable it?  Some monitors poll inputs which sometimes causes the hpd pin to fire which looks like a hotplug event to the driver.
Comment 6 tme 2019-01-08 17:13:17 UTC
Created attachment 143014 [details]
Xorg log

I reproduced the problem at about 210 in the log.

Unfortunately I don't see an option to poll inputs in my monitor.
Comment 7 tme 2019-01-08 17:15:21 UTC
Created attachment 143015 [details]
dmesg output
Comment 8 Michel Dänzer 2019-01-08 18:07:49 UTC
From the Xorg log file:

[   212.439] (II) AMDGPU(0): Allocate new frame buffer 1440x900
[   212.439] (II) AMDGPU(0):  => pitch 6144 bytes
[   212.639] (II) AMDGPU(0): Allocate new frame buffer 3360x1080
[   212.639] (II) AMDGPU(0):  => pitch 14336 bytes

This does look like there are hotplug events, and the HDMI output is considered disconnected for a moment.

(In reply to Alex Deucher from comment #5)
> Some monitors poll inputs which sometimes causes the hpd pin to fire which
> looks like a hotplug event to the driver.

Any idea why this seems to only cause trouble with DC though?

(I was seeing similar symptoms with DC and an HDMI connection with Kaveri, I reported it to the DC developers internally a while ago; it's one reason why I'm currently not using DC on this machine)
Comment 9 tme 2019-01-08 19:12:22 UTC
I've tested some more kernels, all from https://kernel.ubuntu.com/~kernel-ppa/mainline/.

Setting amdgpu.dc=1 on 4.15.18 and 4.16.18 does not reproduce the problem. It does, however, reproduce on 4.17.19.

Also, I now believe my HDMI monitor may have polling, as it cycles through each input once when it no longer detects a signal.

Please let me know if there is anything else I can help with.
Comment 10 Alex Deucher 2019-01-08 20:20:57 UTC
(In reply to Michel Dänzer from comment #8)
> 
> This does look like there are hotplug events, and the HDMI output is
> considered disconnected for a moment.

When the monitor enters dpms, it starts polling inputs so it can light up whatever input gets connected without the user having to manually select the input.  This can cause havoc with drivers sometimes.

> 
> (In reply to Alex Deucher from comment #5)
> > Some monitors poll inputs which sometimes causes the hpd pin to fire which
> > looks like a hotplug event to the driver.
> 
> Any idea why this seems to only cause trouble with DC though?

DC handles both short and long pulses while I think the non-DC code only handles long pulses.  IIRC, the only difference is the length of the pulse and I think the register values used to determine the pulse length are tuned slightly differently in DC to deal with other problematic monitors.  I suspect tuning those settings would fix the issue, but I don't know if it would break other things.
Comment 11 Nathan Patera 2019-01-09 05:12:04 UTC
I have the same exact bug as a secondary confirmation of this bug. I am currently using kernel version 4.15.0-42-generic with an RX 580
Comment 12 Michel Dänzer 2019-01-09 09:32:43 UTC
(In reply to tme from comment #9)
> Setting amdgpu.dc=1 on 4.15.18 and 4.16.18 does not reproduce the problem.
> It does, however, reproduce on 4.17.19.

Can you bisect between 4.16.18 and 4.17.19?

(I see some HPD filtering related changes between them, Nicholas / Harry maybe you can take a look if anything jumps out?)
Comment 13 Nicholas Kazlauskas 2019-01-09 14:39:49 UTC
(In reply to Michel Dänzer from comment #12)
> (In reply to tme from comment #9)
> > Setting amdgpu.dc=1 on 4.15.18 and 4.16.18 does not reproduce the problem.
> > It does, however, reproduce on 4.17.19.
> 
> Can you bisect between 4.16.18 and 4.17.19?
> 
> (I see some HPD filtering related changes between them, Nicholas / Harry
> maybe you can take a look if anything jumps out?)

I haven't had a chance to look into the HPD changes yet, but we haven't seen this bug occur with our DPMS tests so I'm guessing that it's monitor specific. A system environment with Ubuntu/Plasma/xf86-video-amdgpu seems pretty standard at least.

A bisection point on amd-staging-drm-next would certainly help narrow this down.
Comment 14 krutoileshii 2019-01-19 05:52:37 UTC
I am actually experiencing simar issues. Two monitors using displayport to hdmi cable to connect Vega 64 to the monitors. No xorg logs as it's under Wayland but more than happy to test any suggestions. 

https://bbs.archlinux.org/viewtopic.php?id=243452


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.