Hey its fine. We’re just glad you’re being tenacious about this.
I almost got a 390X back when they came out but I’m really glad I didn’t if its just now working correctly.
I’ve made some progress, it’s half working now. I can get my PC to boot to Gnome if I remove “rhgb quiet” from the kernel command line.
I am still using “amdgpu.dc=1 amdgpu.dpm=1 amdgpu.cik_support=1 radeon.cik_support=0” so everything is working as before once in Gnome I just can’t have a graphical boot anymore
… I am now researching Kernel Mode Setting to see what could have broken since kernel 4.18.7 because as far as I can see the problem seems to be related to the AMDGPU driver not being able to switch to graphics mode during boot.
The investigation continues 
2 Likes
Shecks, did you get any further with this? Seems like all the new kernels break the GPU drivers and to be honest performance is no where near windows. Honestly makes me wonder why i bother with Linux as windows just works.
1 Like
@markmozza yes everything’s working well now.
In my experience there were two issues introduced with different kernel updates. As far as I know the first one was an issue with the Plymouth graphical boot. With that issue the only way for me to boot my PC was to remove the rhgb option from the kernel parameter and use text only boot. This was resolved about a week after it was introduced so I was able so I add the rhgb option back in and all was well for a while.
A few weeks later that was another kernel release (I think it was the update from 4.18. to 4.19) that broke something in the AMDGPU driver again. This time it turned out to be a problem with AMD DPM setting and the amdgpu.dpm. Up until this point I was manually setting amdgpu.dpm=1 to force DPM to be enabled for my R9 390.
It seems that there have been some changes here and there is a known bug regarding the issue here.
As far as I can see it’s also affecting some of the newer AMD GPUs too. Some people are reporting that setting amdgpu.dpm=1 allows them to boot but their GPU will run in a low power state so performance is poor.
In my case the only way to boot with my R9 390 is to remove the amdgpu.dpm setting completely (neither setting =1 or =0) from the kernel parameters.
For my R9 390 removing amdgpu.dpm doesn’t seem to have caused any performance issues because I am still getting the same results with the Unigine Heaven benchmark.
If you are having similar issues it might be worth taking a look at the amdgpu.dpm to see if any of the different combinations work for you.
For reference, I am currently running Fedora 29, kernel 4.19.8 using my MSI R9 390 with the following kernel parameters and everything is working well.
amdgpu.dc=1 radeon.cik_support=0 amdgpu.cik_support=1 quiet rhgb
Hope that helps,
Shecks
1 Like
I have a Sapphire Nitro 390X (Hawaii XT I believe) and I’m using the following args:
radeon.cik_support=0 amdgpu.cik_support=1 amdgpu.dc=1 amdgpu.dpm=1
But since I’ve upgraded to kernel 4.19 my system can’t boot with amdgpu enabled. It just shows black screen after grub with no logs and kernel dumps. It just freezes right after selecting Linux from boot. I’ve tried to play with these values but disabling dc and dpm and the problem persists.
Booting with radeon on 4.19 or amdgpu on 4.18 works perfectly.
I’m using OpenSuSE Tumbleweed. I wonder if there is an issue on my side.
Have you tried removing amdgpu.dpm completely rather than setting it =0 or =1 ?
Actually I didn’t tried forcingly disabling by supplying a zero value. I’ve tried booting without dpm and dc, without dpm or without dc. Maybe my computer is setting dpm as default?
I’ll try tonight and report my findings. Since I don’t have another GPU or a serial output I have no idea if the kernel is trying to output some error.
1 Like
If you’re using Plymouth as the graphical boot manager you could also try adding plymouth:debug to the kernel command parameters to see if it outputs any useful information.
@Shecks Im about to try your settings wish me luck!
UPDATE:
No luck, low res, cant detect monitor as always.
Is it possible that the firmware for your card is not installed? I was reading this bug report where people are experiencing similar issue with AMDGPU. Might be worth checking if your distro has the correct firmware for your GPU.
I’m currently using Elementary Juno, which is basically Ubuntu 18.04. That bug says black screen, i actually get a display but my monitor is unrecognized and the resolution is locked at something stupid 720p i think.
Here is a couple of benchmarks I’ve done on 4.18.7, Its the last kernel to work for me. Performance is not the best.
Tomb Raider
Counter Strike
Oh wow. I thought it had always worked. I really did dodge a bullet getting a 970 for cheaper a while ago then. Sad to hear. But glad to see it works!
@Shecks Have you managed to test the latest Kernels that have been released? I’m going to give it a go tonight. I’ll update with info.
Yes, I’ve been updating to each new kernel as it’s release, I am currently running kernel 4.19.9 (latest stable release for Fedora 29).
I am still running with the amdgpu.dpm kernel parameter completely removed. I’ve just checked this kernel with both amdgpu.dpm=0 and amdgpu.dpm=1 and the issue is still there, I can only boot with the option omitted from the command line.
Other than that, my PC is stable and I’ve had no issues running without amdgpu.dpm
You mentioned that you are not getting a black screen on boot so I am not sure if it’s the same issue but have you tried disabling the graphical boot loader to see if there’s any differences and if you get any errors displayed? On Fedora this is done by removing the rhgb kernel parameter, but I am not sure what the equivalent is for Elementary Juno, but I assume there is a similar option.
I was using 290s and a 270 with no problems on earlier kernels, but I haven’t played around with it since about 4.15 or so.
I was using radeon.cik_support=0 amdgpu.cik_support=1 and radeon.si_support=0 amdgpu.si_support=1 kernel params in the grub config, but not amdgpu.dpm or amdgpu.dc.
I guess they added some new stuff later and broke it?
1 Like
Yep, they definitely broke something, at one point (pre kernel 4.18.x) I had to use amdgpu.dpm=1 or my GPU would hang as soon as it tried to change power states, now I have remove it completely or my PC doesn’t get past the mode switch during boot up, there’s no performance issues without the switch though, so I guess they only half broke it.
Ahh that must be the wattman-like functionality is it?
I think so, it’s Dynamic Power Management and it’s taking them a long time to get right 