https://bugs.freedesktop.org/show_bug.cgi?id=105433
Bug ID: 105433 Summary: Unreliable Modesetting on Tonga with two DVI Screens Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: freedesktop-bugs@digital-trauma.de
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.
https://bugs.freedesktop.org/show_bug.cgi?id=105433
--- Comment #1 from Thomas R. freedesktop-bugs@digital-trauma.de --- Created attachment 137980 --> https://bugs.freedesktop.org/attachment.cgi?id=137980&action=edit dmesg of boot, start of X and xrandr
https://bugs.freedesktop.org/show_bug.cgi?id=105433
--- Comment #2 from Thomas R. freedesktop-bugs@digital-trauma.de --- Created attachment 139608 --> https://bugs.freedesktop.org/attachment.cgi?id=139608&action=edit dmesg of boot, start of X, xrandr with current staging
Still persists in commit dbf4f8b16fde from Tuesday, see dmesg.
https://bugs.freedesktop.org/show_bug.cgi?id=105433
--- Comment #3 from Thomas R. freedesktop-bugs@digital-trauma.de --- 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?
https://bugs.freedesktop.org/show_bug.cgi?id=105433
--- Comment #4 from Michel Dänzer michel@daenzer.net --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=105433
--- Comment #5 from Thomas R. freedesktop-bugs@digital-trauma.de --- 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 :/.
https://bugs.freedesktop.org/show_bug.cgi?id=105433
--- Comment #6 from Thomas R. freedesktop-bugs@digital-trauma.de --- Tested with 4.18.5, same behaviour.
https://bugs.freedesktop.org/show_bug.cgi?id=105433
--- Comment #7 from Thomas R. freedesktop-bugs@digital-trauma.de --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=105433
--- Comment #8 from Thomas R. freedesktop-bugs@digital-trauma.de --- Apart from bootup, coming back from suspend also has that one screen dead at first, and also fixable by changing resolution and back.
https://bugs.freedesktop.org/show_bug.cgi?id=105433
--- Comment #9 from Thomas R. freedesktop-bugs@digital-trauma.de --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=105433
Thomas R. freedesktop-bugs@digital-trauma.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #137980|0 |1 is obsolete| | Attachment #139608|0 |1 is obsolete| |
--- Comment #10 from Thomas R. freedesktop-bugs@digital-trauma.de --- Created attachment 143977 --> https://bugs.freedesktop.org/attachment.cgi?id=143977&action=edit Kernel log with debug of 4.19.20+ before patch, including screen reset to get it to work
https://bugs.freedesktop.org/show_bug.cgi?id=105433
--- Comment #11 from Thomas R. freedesktop-bugs@digital-trauma.de --- Created attachment 143978 --> https://bugs.freedesktop.org/attachment.cgi?id=143978&action=edit Kernel log with debug of 4.19.20+ after patch, including screen reset that does nothing
https://bugs.freedesktop.org/show_bug.cgi?id=105433
Martin Peres martin.peres@free.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |MOVED
--- Comment #12 from Martin Peres martin.peres@free.fr --- -- 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.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org