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.
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.
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.
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.
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.
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?
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.
~~I’ve tried multiple combinations and omitting the parameters again but no luck. Replacing quiet with verbose and adding plymouth:debug shows some boot code with the famous red hat green OK outputs but the screen goes black again without warning. My guess is that getting the console in framebuffer mode with higher resolutions breaks the kernel.
Its a kernel crash because I can’t SSH into the system. Any useful info that could help me a kernel stack trace if there is one. The motherboard doesn’t have a serial console.~~
Update: Upgrading the kernel to 4.19.8-1-default (from 4.19.5-x) and omitting dpm fixed it!
