Two devices connected via DVI, one not coming up (powersave, no signal). On retry , they may swap their working state, or both go to energy save, or rarely, both work. This happens regardless of resolutions set on the screens in question. Screens: 2 x Benq G2222HDL Connected via DVI (both straight to card) Card: ASUS Strix R9285 DC2OC 2GD5 Kernel: amd-staging-drm-next 6e62bc7a123b "drm/amdgpu:Always save uvd vcpu_bo in VM Mode" Bug report as discussed in bug 100919. Possibly related to bug 91202.
Created attachment 137980 [details] dmesg of boot, start of X and xrandr
Created attachment 139608 [details] dmesg of boot, start of X, xrandr with current staging Still persists in commit dbf4f8b16fde from Tuesday, see dmesg.
As you can see, I still get [drm] dce_get_required_clocks_state: clocks unsupported disp_clk 681000 pix_clk 148500 Is there anything I can do to give you more information?
(In reply to Thomas R. from comment #3) > [drm] dce_get_required_clocks_state: clocks unsupported disp_clk 681000 > pix_clk 148500 FWIW, I get the same message with Tonga, with a single DVI connection. I haven't noticed any obvious ill effects related to it though, so it might not be relevant for this issue.
Hm. Well the current state of this machine is: I got an old working AMD DC kernel (4.11) that is starting to give me trouble, and nothing current that works. I'd be willing to bisect from there to current, but there are other bugs and problems in between (some linked in first post) that make me not very hopeful :/.
Tested with 4.18.5, same behaviour.
I've got news! With 4.19, the first modeset will still disable the second monitor, including when going into X (without mode change), but after changing the resolution to something else and back again, it now comes up reliably. This is much better than before. Also, I get this in dmesg [drm] dce110_link_encoder_construct: Failed to get encoder_cap_info from VBIOS with error code 4! on startup. I don't know if this helps, and I'd be still willing to help debug given instructions.
Apart from bootup, coming back from suspend also has that one screen dead at first, and also fixable by changing resolution and back.
I'm unsure if I should file a new bug at this point, but here is an update for the LTS kernel: 4.19.20 breaks functionality again, now the second screen is reliably dead at 1080p (native resolution). I could bisect down to 0857b8439b6b9ce388e47652420ac083ea5f08d6 by Yogesh Mohan Marimuthu - drm/amd/display: calculate stream->phy_pix_clk before clock mapping. It's the same for 4.20.17 and 5.0.6, I assume they contain the patch, too. I will attach debug kernel logs for both 4.19.20+ before the patch (working after screen reset as described above) and after.
Created attachment 143977 [details] Kernel log with debug of 4.19.20+ before patch, including screen reset to get it to work
Created attachment 143978 [details] Kernel log with debug of 4.19.20+ after patch, including screen reset that does nothing
-- 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/320.
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.