Created attachment 139653 [details] dmesg on 4.17-rc6 Problem: After allowing both of my monitors to go to sleep, my HP w2207 is no longer detected as being connected to the computer, and cannot be woken up. Its display cable must be removed and reinserted into my AMD gpu for it to be detected. Expected: The monitor, like my other samsung, will wake up and the OS will see it as connected. Why I think this is possible to fix in software: The problem does not occur when using my 660Ti with Nvidia's 390.x driver. Hardware: GPU: RX 560 4GB Monitor 1: HP w2207 (Affected) Monitor 2: Samsung S23A700 (*Not* affected) I have tried DVI->DVI and DVI->HDMI cables with the HP w2207, no change in behavior. The monitor will not wake even when it is the only monitor connected. I have tested another monitor (an ancient 4:3 dell) in conjunction with the S23A700, and both wake normally. Software: Mesa version: 18.0 X11 version: 1.19.6 Kernel commandline: See attachment for one example (I have tried disabling amdgpu.dpm and amdgpu.dc to no effect) EDID: See attachments Kernel config: see attachments The only dmesg output before and after the sleep is: [drm] SADs count is: -2, don't need to read it [drm] SADs count is: -2, don't need to read it Kernels tested: 4.16.9 4.16.10 4.17-rc6 amd-drm-staging-next (current as of May 18th 2018) No changes between any of them. I also see that the kernel renames the display after a reconnect, I'm not sure if that is normal either. e.g. At boot: card1-HDMI-A-3 After unplugging/replugging: card1-HDMI-A-4 Please let me know what additional information or troubleshooting steps you would like me to take. Thanks for your time.
Created attachment 139654 [details] current kernel commandline Attaching kernel commandline.
Created attachment 139655 [details] HP w2207 EDID Adding HP w2207 EDID
Created attachment 139656 [details] kernel config file Attaching config
I have a similar pb: once my monitor (iiyama g-master) gets into DPMS off mode from the xserver, _often_ (it does work sometimes) the monitor video mode won't be re-programmed and will display "no signal" (displayport whatever the refresh rate). But I can blindly type on the keyboard to reboot the computer when it happens. I am not really investigating since my monitor going in dpms off is quite rare in my computer usage. Just giving the info that there is maybe a lil pb here related to this bug. AMD TAHITI XT xserver: git mesa: git xf86-video-amdgpu: git linux amdgpu: amd-staging-next (I did update with git source code yesterday and performed no test yet on this matter with the new code). Nothing abnormal was reported in the logs (if you really want them, I'll reproduce the pb).
Created attachment 139664 [details] Xorg.log
Created attachment 139665 [details] kernel log
I provide the logs since it happened today with the latest code.
Tom, amdgpu.dc=0 might serve as a workaround for the time being. (In reply to Sylvain BERTRAND from comment #4) > I have a similar pb: [...] Please file your own report.
(In reply to Michel Dänzer from comment #8) > Tom, amdgpu.dc=0 might serve as a workaround for the time being. Thanks for the reply Michel, I had tried that earlier to no avail. Unfortunately I may have wasted everyone's time, the monitor in question appears to be failing. It cannot display an image for more than 3 seconds before going totally black. My guess is that the monitor is close to outright dying, so even if I did experience a bug, I can no longer use the monitor and therefore cannot continue testing this problem.
Monitor was physically failing, cannot reproduce on other monitors available.
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.