Stuck on 640x480 resolution after 4.19

[Dazage]

Since kernel version 4.19 my main rig has had this problem, where my screen is essentially stuck on a 640x480 resolution, it’s immediately noticeable in my login manager.

Hardware
GPU: Gigabyte Radeon RX VEGA 56
Motherboard: Asus Maximus VII RANGER
Monitor: Asus 27" PG278QR

Distro & Kernel
Distro: Fedora 29 Workstation, no real modifications other than Dash to Dock and a couple of snap packages.
The one that works: 4.18.16-300.fc29.x86_64
The one that doesn’t: 4.19 and afterwards

Video driver
03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Vega 10 XL/XT [Radeon RX Vega 56/64] (rev c3)
Subsystem: Gigabyte Technology Co., Ltd Device 230c
Kernel driver in use: amdgpu
Kernel modules: amdgpu

What I’ve tried
-I’ve attempted to force a resolution by using xrandr.
-Starting GNOME with Xorg.
-I installed KDE Plasma out of a naive desperation for a simple fix that I wouldn’t have to work/think for.

Any ideas as to what the problem here is?

[redgek]

anything incriminating in logs? dmesg?

[Dazage]

Is this what you mean? I’m not entirely sure what I’m looking for.

[ 1.964707] amdgpu 0000:03:00.0: fb0: amdgpudrmfb frame buffer device
[ 1.972095] amdgpu 0000:03:00.0: ring 0(gfx) uses VM inv eng 4 on hub 0
[ 1.972096] amdgpu 0000:03:00.0: ring 1(comp_1.0.0) uses VM inv eng 5 on hub 0
[ 1.972097] amdgpu 0000:03:00.0: ring 2(comp_1.1.0) uses VM inv eng 6 on hub 0
[ 1.972098] amdgpu 0000:03:00.0: ring 3(comp_1.2.0) uses VM inv eng 7 on hub 0
[ 1.972099] amdgpu 0000:03:00.0: ring 4(comp_1.3.0) uses VM inv eng 8 on hub 0
[ 1.972099] amdgpu 0000:03:00.0: ring 5(comp_1.0.1) uses VM inv eng 9 on hub 0
[ 1.972100] amdgpu 0000:03:00.0: ring 6(comp_1.1.1) uses VM inv eng 10 on hub 0
[ 1.972101] amdgpu 0000:03:00.0: ring 7(comp_1.2.1) uses VM inv eng 11 on hub 0
[ 1.972102] amdgpu 0000:03:00.0: ring 8(comp_1.3.1) uses VM inv eng 12 on hub 0
[ 1.972102] amdgpu 0000:03:00.0: ring 9(kiq_2.1.0) uses VM inv eng 13 on hub 0
[ 1.972103] amdgpu 0000:03:00.0: ring 10(sdma0) uses VM inv eng 4 on hub 1
[ 1.972104] amdgpu 0000:03:00.0: ring 11(sdma1) uses VM inv eng 5 on hub 1
[ 1.972105] amdgpu 0000:03:00.0: ring 12(uvd<0>) uses VM inv eng 6 on hub 1
[ 1.972106] amdgpu 0000:03:00.0: ring 13(uvd_enc0<0>) uses VM inv eng 7 on hub 1
[ 1.972107] amdgpu 0000:03:00.0: ring 14(uvd_enc1<0>) uses VM inv eng 8 on hub 1
[ 1.972107] amdgpu 0000:03:00.0: ring 15(vce0) uses VM inv eng 9 on hub 1
[ 1.972108] amdgpu 0000:03:00.0: ring 16(vce1) uses VM inv eng 10 on hub 1
[ 1.972109] amdgpu 0000:03:00.0: ring 17(vce2) uses VM inv eng 11 on hub 1

[redgek]

yeah, any errors there?

[Dazage]

Right, I’m retracted. Hold on, rebooting.

[Dazage]

Ok so yeah I did find an error:

[drm:dc_link_detect [amdgpu]] *ERROR* No EDID read.

[redgek]

seems like a known issue, from quick skim, no fix but reverting to older kernel.

https://bugzilla.kernel.org/show_bug.cgi?id=201497

[Dazage]

But thank you a lot for your help and quick response.

[redgek]

no problem, sorry couldn’t help more, and KOTOR was a great game. sips

[Mastic_Warrior]

There was a bug that was introduced in 4.19 dealing with AMDGPU. There is a patch for it but it has been corrected in 4.20/5.0

Are you using HDMI or DP. Are you using freesync monitor?

Basically it has to deal with the power management in the AMDPGU driver so you can add the following lines to your kernel commanline config

amdgpu.dc=0

For example. I am using amdgpu with my RadeonHD 7790 and with 4.19, it broke DC and DPM for me so I had to add the following to my boot config to be able to get to a desktop

radeon.cik_support=0 amdgpu.cik_support=1 amdgpu.dpm=0 amdgpu.dc=0

[noenken]

As far as I know Vega needs amdgpu.dc=1. Fiji, polaris and earlier don’t.

[Dazage]

Well, I’m able to get to a desktop, it just won’t go beyond 640x480 resolution, works fine otherwise.

I’m using DP and the monitor is G-sync; Asus 27" PG278QR

[noenken]

Did you try a newer kernel yet?

[Dazage]

Yeah, so far I’ve tried every kernel release from Fedora between 4.18 up to 5.0.8.

I’m beta testing Fedora 30 on my laptop which has recently given out 5.1, which doesn’t appear to fix this either, based on the lkml shortlog.