I'm running into a major issue which seems to have been introduced with Kernel 4.19.1 and later (did not occur in 4.18.5). My OS is openSUSE Tumbleweed x64 with the last working snapshot being 20181112. My machine refuses to boot and remains stuck at a black screen after issuing the boot command in grub2. The HDD led flashes a few times shortly after grub2 disappears, but after that it will stay off and nothing new happens. I cannot use "control + alt + fN" to switch to a different runlevel either, however I'm still able to toggle the NumLock / CapsLock leds which means the system isn't freezing up entirely. The computer won't respond to the power button and has to be restarted via the reset button. The issue is specific to the amdgpu module: Kernel 4.19 will boot successfully if using the radeon and not amdgpu driver. I'm able to load it after removing the following parameters from my Kernel command line: radeon.si_support=0 radeon.cik_support=0 amdgpu.si_support=1 amdgpu.cik_support=1 I can confirm that the problem is video card specific: My mother's computer also uses openSUSE Tumbleweed and has the latest snapshot, as well as the same kernel parameters for amdgpu. For her there are absolutely no issues when booting with 4.19. I'm pondering whether this Kernel introduces an issue in amdgpu which affects GCN 2.0 video cards explicitly. My affected video card is a Radeon R9 390 8GB (GCN 2.0). My mother's working video card is a Radeon R7 370 2GB (GCN 1.0).
Sounds like it's probably failing to load some microcode files. The amdgpu driver in 4.19 started loading some of them from .../firmware/amdgpu/ instead of .../firmware/radeon/. If you don't have the former files yet, you can create symlinks for them pointing to the radeon directory for now.
It seems further debugging might not be needed: As of kernel 4.19.7 the issue appears to go away, I'm able to boot with amdgpu normally like before. The last kernel I still saw the problem with is 4.19.5. Anyone know what could have changed in between them, so perhaps we can keep a lookout for such an issue in the future and prevent it? Perhaps this might have been a package issue in openSUSE: Michel Dänzer suggested that as of 4.19, the kernel loads all firmware from "path/firmware/amdgpu/" instead of falling back to "path/firmware/radeon/" when something is missing. Did the Tumbleweed snapshot 20181208 make any updates in this regard? In any case, I'll mark this as resolved and reopen in case the issue ever returns.
Seems to be resolved in openSUSE Tumbleweed snapshot 20181208.
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.