Bug 103953 - [DC] Polaris10: Missing modes when enabling DC
Summary: [DC] Polaris10: Missing modes when enabling DC
Status: RESOLVED FIXED
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: 109238
  Show dependency treegraph
 
Reported: 2017-11-28 13:05 UTC by Dominik Paulus
Modified: 2019-01-07 06:49 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg with amdgpu.dc=1 (48.64 KB, text/plain)
2017-11-28 13:05 UTC, Dominik Paulus
no flags Details
dmesg with default settings (48.17 KB, text/plain)
2017-11-28 13:05 UTC, Dominik Paulus
no flags Details
Xorg.log with dc enabled (33.20 KB, text/plain)
2017-11-28 13:05 UTC, Dominik Paulus
no flags Details
Xorg.log with dc disabled (27.44 KB, text/plain)
2017-11-28 13:06 UTC, Dominik Paulus
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dominik Paulus 2017-11-28 13:05:00 UTC
Created attachment 135751 [details]
dmesg with amdgpu.dc=1

I have a Dell U2713HM connected to a Radeon RX470 (MSI board, 'Radeon RX470 Gaming 4G') over dual-link DVI on Linux 4.15-rc1. When enabling DC (Kernel commandline amdgpu.dc=1), the monitors native resolution of 2560x1440 is not detected, when falling back to default modesetting, everything works fine. Xorg.log and (relevant parts) of dmesg for both amdgpu.dc=1 and =0 are attached.
Comment 1 Dominik Paulus 2017-11-28 13:05:25 UTC
Created attachment 135752 [details]
dmesg with default settings
Comment 2 Dominik Paulus 2017-11-28 13:05:49 UTC
Created attachment 135753 [details]
Xorg.log with dc enabled
Comment 3 Dominik Paulus 2017-11-28 13:06:11 UTC
Created attachment 135754 [details]
Xorg.log with dc disabled
Comment 4 Marc Cousin 2018-02-24 18:14:16 UTC
Having the exact same bug, but with a RX570… DVI-D, 4.15 kernel, xorg 1.19.6, mesa 17.3.5…
Comment 5 Harry Wentland 2018-02-27 20:07:58 UTC
This should be fixed on our staging branches.

Are you able to give Alex's amd-staging-drm-next or drm-next-4.17-wip branch
from https://cgit.freedesktop.org/~agd5f/linux/?h=amd-staging-drm-next a try?
Comment 6 Dominik Paulus 2018-02-27 23:03:44 UTC
I've tested commit 17fd4b27d8d0698e42095796a3758bbc841d3a6c from amd-staging-drm-next and can confirm that it fixes the described bug on my system. Thanks!
Comment 7 Luke McKee 2018-02-28 01:42:11 UTC
As suggested to the users here,

I've tried your latest staging branch with dc=1
On a Polaris RX560 latest everything (libva-git,vdpau-git,mesa-git,xf86-amdgpu-git,amd-drm-staging-next master 4.15-rc4).

It seems the other users here are using DRI2. I'll try again with DRI3.

What happens here is when gdm is used (with and without wayland compiled in enabled) I think it switches vt's when you sign in. After logging in the screen get's scrambled.

This is all I could find useful in the logs.

Feb 28 00:48:26 hojuruku /usr/libexec/gdm-x-session[20032]: (EE) AMDGPU(0): failed to set mode: Invalid argument
Feb 28 00:48:26 hojuruku /usr/libexec/gdm-x-session[20032]: (WW) AMDGPU(0): Failed to set mode on CRTC 0
Feb 28 00:48:26 hojuruku /usr/libexec/gdm-x-session[20032]: (EE) AMDGPU(0): Failed to enable any CRTC
Feb 28 00:48:26 hojuruku /usr/libexec/gdm-x-session[20032]: (EE)
Feb 28 00:48:26 hojuruku /usr/libexec/gdm-x-session[20032]: Fatal server error:
Feb 28 00:48:26 hojuruku /usr/libexec/gdm-x-session[20032]: (EE) EnterVT failed for screen 0
Feb 28 00:48:26 hojuruku /usr/libexec/gdm-x-session[20032]: (EE)
Feb 28 00:48:26 hojuruku /usr/libexec/gdm-x-session[20032]: Please consult the The X.Org Foundation support
Feb 28 00:48:26 hojuruku /usr/libexec/gdm-x-session[20032]:          at http://wiki.x.org
Feb 28 00:48:26 hojuruku /usr/libexec/gdm-x-session[20032]:  for help.
Feb 28 00:48:26 hojuruku /usr/libexec/gdm-x-session[20032]: (EE) Please also check the log file at "/var/log/Xorg.1.log" for additional information.
Feb 28 00:48:26 hojuruku /usr/libexec/gdm-x-session[20032]: (EE)
Feb 28 00:48:26 hojuruku /usr/libexec/gdm-x-session[20032]: (II) AIGLX: Suspending AIGLX clients for VT switch
Feb 28 00:48:26 hojuruku /usr/libexec/gdm-x-session[20032]: (EE) Server terminated with error (1). Closing log file.


The h265 will crash the pc too if you try and encode with ffmpeg. updating libva to git and trying again.
Feb 28 08:02:28 hojuruku kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring uvd timeout, last signaled seq=20269, last emitted seq=20270
Feb 28 08:02:28 hojuruku kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring uvd_enc0 timeout, last signaled seq=2306, last emitted seq=2308
Feb 28 08:02:28 hojuruku kernel: [drm] IP block:gmc_v8_0 is hung!
Feb 28 08:02:28 hojuruku kernel: [drm] IP block:gfx_v8_0 is hung!
Feb 28 08:02:28 hojuruku kernel: [drm] IP block:uvd_v6_0 is hung!
Feb 28 08:02:28 hojuruku kernel: [drm] IP block:gmc_v8_0 is hung!
Feb 28 08:02:28 hojuruku kernel: [drm] IP block:gfx_v8_0 is hung!
Feb 28 08:02:28 hojuruku kernel: [drm] GPU recovery disabled.
Feb 28 08:02:28 hojuruku kernel: [drm] IP block:uvd_v6_0 is hung!
Feb 28 08:02:28 hojuruku kernel: [drm] GPU recovery disabled.

Another issue I've noticed is that there are kernel panic's if amd-iommu isn't compiled as a kernel module even if you don't have the hardware. Shall I open another ticket about that?
Comment 8 Alex Deucher 2018-02-28 02:16:11 UTC
(In reply to Luke McKee from comment #7)
> As suggested to the users here,
> 

Please stop posting random crap on every bug report.  If you are seeing an issue please file your own bug reports.  If they are a duplicate of some other bug, they can be marked so.
Comment 9 Marc Cousin 2018-03-02 17:46:59 UTC
Bug solved for me too with amd-staging-drm-next. Thanks a lot.
Comment 10 Harry Wentland 2018-03-05 16:24:41 UTC
Marking this fixed as multiple people confirmed fix is in amd-staging-drm-next.
Comment 11 Aleksei 2018-03-08 12:56:46 UTC
I'm losing refresh rates higher than 60Hz with dc=1 on 4.15.6 kernel - is that fixed too?

Monitor 1920x1080 144Hz, GPU RX 560, connection over DVI-D. With dc=0 I can set 1920x1080 144Hz, with dc=1 only 1920x1080 60Hz.
Comment 12 Alex Deucher 2018-03-08 14:30:35 UTC
(In reply to Aleksei from comment #11)
> I'm losing refresh rates higher than 60Hz with dc=1 on 4.15.6 kernel - is
> that fixed too?
> 
> Monitor 1920x1080 144Hz, GPU RX 560, connection over DVI-D. With dc=0 I can
> set 1920x1080 144Hz, with dc=1 only 1920x1080 60Hz.

You'll need the latest 4.16 with the fixes I sent out yesterday.
Comment 13 Aleksei 2018-03-12 06:40:05 UTC
(In reply to Alex Deucher from comment #12)
> You'll need the latest 4.16 with the fixes I sent out yesterday.
Thanks, tested with latest amd-staging-drm-next - 144Hz works.


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.