Summary: | [DC] Polaris10: Missing modes when enabling DC | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | Dominik Paulus <freedesktop-bugzilla> | ||||||||||
Component: | DRM/AMDgpu | Assignee: | Default DRI bug account <dri-devel> | ||||||||||
Status: | RESOLVED FIXED | QA Contact: | |||||||||||
Severity: | normal | ||||||||||||
Priority: | medium | CC: | alex3kov, cousinmarc, fdsfgs | ||||||||||
Version: | unspecified | ||||||||||||
Hardware: | x86-64 (AMD64) | ||||||||||||
OS: | Linux (All) | ||||||||||||
Whiteboard: | |||||||||||||
i915 platform: | i915 features: | ||||||||||||
Bug Depends on: | |||||||||||||
Bug Blocks: | 109238 | ||||||||||||
Attachments: |
|
Created attachment 135752 [details]
dmesg with default settings
Created attachment 135753 [details]
Xorg.log with dc enabled
Created attachment 135754 [details]
Xorg.log with dc disabled
Having the exact same bug, but with a RX570… DVI-D, 4.15 kernel, xorg 1.19.6, mesa 17.3.5… 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? I've tested commit 17fd4b27d8d0698e42095796a3758bbc841d3a6c from amd-staging-drm-next and can confirm that it fixes the described bug on my system. Thanks! 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? (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. Bug solved for me too with amd-staging-drm-next. Thanks a lot. Marking this fixed as multiple people confirmed fix is in amd-staging-drm-next. 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. (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. (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.
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.