| Bug ID | 109246 |
|---|---|
| Summary | HDMI connected monitors fail to sleep and instead turn back o= n when amdgpu.dc=3D1 |
| Product | DRI |
| Version | unspecified |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | DRM/AMDgpu |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | t00m4nyerr0rs@gmail.com |
Original launchpad thread: ht= tps://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 un= til 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 connect= ed using HDMI. Connecting only one monitor using HDMI will trigger the problem. Connecting either one using DVI does not trigger the problem.=20 I am unable to test if DisplayPort triggers the problem, as I have no compatible monitors. Setting the kernel parameter amdgpu.dc=3D0 does not cause the problem to tr= igger. I haven't confirmed if the other affected users in the launchpad thread are using HDMI, so I'm only reporting my experience.
Forgot to mention that I have tested and reproduced this bug o= n kernel versions 4.18, 4.20, and 5.0-rc1.
I am tired to automatic monitor sleep problems and made a laun= cher to manually sleep the monitor. #! /bin/bash sleep 5s xset dpms force standby
| What | Removed | Added |
|---|---|---|
| CC | harry.wentland@amd.com, nicholas.kazlauskas@amd.com |
Please attach the output of dmesg and the Xorg log file, captu= red after reproducing the problem.
Use the DVI connector then. The HDMI development has a low pri= ority. 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.
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.
Created attachment 143014 [detai=
ls]
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.
From the Xorg log file: [ 212.439] (II) AMDGPU(0): Allocate new frame buffer 1440x900 [ 212.439] (II) AMDGPU(0): =3D> pitch 6144 bytes [ 212.639] (II) AMDGPU(0): Allocate new frame buffer 3360x1080 [ 212.639] (II) AMDGPU(0): =3D> pitch 14336 bytes This does look like there are hotplug events, and the HDMI output is consid= ered disconnected for a moment. (In reply to Alex Deucher from comm= ent #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)
I've tested some more kernels, all from https://kernel.= ubuntu.com/~kernel-ppa/mainline/. Setting amdgpu.dc=3D1 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.
(In reply to Michel D=C3=A4nzer from comment #8) >=20 > 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. >=20 > (In reply to Alex Deucher from comment #5) > > Some monitors poll inputs which sometimes causes the hpd pin to f= ire which > > looks like a hotplug event to the driver. >=20 > 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 susp= ect tuning those settings would fix the issue, but I don't know if it would bre= ak other things.
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
(In reply to tme from = comment #9) > Setting amdgpu.dc=3D1 on 4.15.18 and 4.16.18 doe= s 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 ma= ybe you can take a look if anything jumps out?)
(In reply to Michel D=C3=A4nzer from comment #12) > (In reply to tme from comment #9) > > Setting amdgpu.dc=3D1 on 4.15.18 and 4.16.18 does not reproduce t= he problem. > > It does, however, reproduce on 4.17.19. >=20 > Can you bisect between 4.16.18 and 4.17.19? >=20 > (I see some HPD filtering related changes between them, Nicholas / Har= ry > 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 specif= ic. A system environment with Ubuntu/Plasma/xf86-video-amdgpu seems pretty stan= dard at least. A bisection point on amd-staging-drm-next would certainly help narrow this down.
I am actually experiencing simar issues. Two monitors using di= splayport 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.=20 https://bbs= .archlinux.org/viewtopic.php?id=3D243452
I've been attempting to perform a bisect on an off for a while= now with no success. The main problem I'm running into is this error when trying to compile. RELOCS arch/x86/boot/compressed/vmlinux.relocs Unsupported relocation type: R_X86_64_PLT32 (4) make[4]: *** [arch/x86/boot/compressed/Makefile:123: arch/x86/boot/compressed/vmlinux.relocs] Error 1 make[3]: *** [arch/x86/boot/Makefile:112: arch/x86/boot/compressed/vmlinux] Error 2 make[2]: *** [arch/x86/Makefile:299: bzImage] Error 2 make[1]: *** [scripts/package/Makefile:96: bindeb-pkg] Error 2 make: *** [Makefile:1386: bindeb-pkg] Error 2 I've tried searching for solutions for this problem, but I haven't found anything. It occurs when I run "make -j4 deb-pkg" and "make = bzImage". If anyone can help me solve this, I'd be happy to start bisecting again.
Found a partial solution that seems to address the instant wak= e up under Wayland. It seems that by default, the AOS2770SHE starts polling once display disconnects on one of its inputs. This seems to cause the actual system to = wake up. However, this was not an issue before and used to function with no prob= lems previously. It seems that something in amgdpu DC code changed that is picki= ng up these polling requests. To get the monitors to sleep properly, I did the following: Set "Input Select": Auto -> HDMI1 Set "DDC/CI": Yes -> No Now the display sleeps as expected and wakes up with no issues. Still would like to know what changed to cause this to appear. I usually need to have t= he inputs set to Auto as I have a docking station plugged into the monitors for the work laptop. Also amdgpu.dc=3D0 hands the system and it's only becomes accessable throug= h ssh. However no errors are present in any logs. But I'll file a different bug on= ce I nail it down to a specific component.
I think this could be related to this commit b0c4e977522c34e20ad54ff4ca104129a7cfdeca which removed the delay.: Below patchset seems to be the likely cause as it touches the HDMI portion. https://lists.freedesktop.org/archives/amd-gfx/2018-February/0189= 56.html
The function that sets the delay (dc_link_enable_hpd_filter), = doesn't seem to be called anywhere as far as I can see. But I'm a complete noob here so mig= ht be missing something. (In reply to krutoileshii from comment #17) > I think this could be related to this commit > b0c4e977522c34e20ad54ff4ca104129a7cfdeca which removed the delay.: Bel= ow > patchset seems to be the likely cause as it touches the HDMI portion. >=20 > https://lists.freedesktop.org/archives/amd-gfx/2018-February= /018956.html
(In reply to tme from comment #15) > I've been attempting to perform a bisect on an o= ff for a while now with no > success. The main problem I'm running into is this error when trying to > compile. >=20 > RELOCS arch/x86/boot/compressed/vmlinux.relocs > Unsupported relocation type: R_X86_64_PLT32 (4) > make[4]: *** [arch/x86/boot/compressed/Makefile:123: > arch/x86/boot/compressed/vmlinux.relocs] Error 1 > make[3]: *** [arch/x86/boot/Makefile:112: arch/x86/boot/compressed/vml= inux] > Error 2 > make[2]: *** [arch/x86/Makefile:299: bzImage] Error 2 > make[1]: *** [scripts/package/Makefile:96: bindeb-pkg] Error 2 > make: *** [Makefile:1386: bindeb-pkg] Error 2 >=20 > I've tried searching for solutions for this problem, but I haven't fou= nd > anything. It occurs when I run "make -j4 deb-pkg" and "= make bzImage". If > anyone can help me solve this, I'd be happy to start bisecting again.<= /span > Any luck bisecting?
(In reply to tme from comment #15) > I've been attempting to perform a bisect on an o= ff for a while now with no > success. The main problem I'm running into is this error when trying to > compile. >=20 > RELOCS arch/x86/boot/compressed/vmlinux.relocs > Unsupported relocation type: R_X86_64_PLT32 (4) > make[4]: *** [arch/x86/boot/compressed/Makefile:123: > arch/x86/boot/compressed/vmlinux.relocs] Error 1 > make[3]: *** [arch/x86/boot/Makefile:112: arch/x86/boot/compressed/vml= inux] > Error 2 > make[2]: *** [arch/x86/Makefile:299: bzImage] Error 2 > make[1]: *** [scripts/package/Makefile:96: bindeb-pkg] Error 2 > make: *** [Makefile:1386: bindeb-pkg] Error 2 >=20 > I've tried searching for solutions for this problem, but I haven't fou= nd > anything. It occurs when I run "make -j4 deb-pkg" and "= make bzImage". If > anyone can help me solve this, I'd be happy to start bisecting again.<= /span > Hey i am bisecting the same commits for another problem and i am getting the same error: https://bugzilla.kernel.org/show_bug.cgi?id=3D201077#c26
I've tried to revert commit b0c4e977522c34e20ad54ff4ca104129a7= cfdeca but I haven't been able to successfully compile afterwards, running into the same issue as before. Setting it as the head still causes the bug to replicate w= hen amdgpu.dc=3D1, however.
This is happening to me as well. RX570 w/ Acer H236HL Dual head, both inputs HDMI I didn't have this issue with the same monitors and an nvidia card, so it s= eems specific to the amdgpu driver. The monitors seem to lose signal (which is normal), then perform an auto in= put cycle which then wakes the monitors back up. The backlight will come on and display the mouse cursor on a black screen. I experience this with both Xorg and Wayland. Unfortunately I can't disable auto input on my monitors, as the previous workaround suggests. Just disabling DDC/CI didn't help. Adding amdgpu.dc=3D0 to linux cmdline resolves the issue for me, but I'm concerned that may preclude my system from gaining newer features.