Hello. I would like to report a problem with the inability to boot from the latest update of OpenSUSE, with Linux version 5.2.10. The last log message is “fb: switching to radeondrmfb from EFI VGA”. (I was booting up the kernel without a quiet flag). After that message everything freezes - I can’t login to the SSH or tty. Normally, after this message, the screen switches to graphic mode with higher resolution (1080p). The problem occurs on all my machines - desktop with AMD RX 560 graphics card and Lenovo Ideapad 720s laptop (Integrated Radeon Vega 10 Graphics). On version 5.2.9 the problem does not occur at all. I do not use amdgpu-pro, only open-source solution. I have a friend who’s also recently had the same problem, but for the older version of OpenSUSE (and kernel) . For this reason, I am convinced that the problem exists on many machines with Radeon graphics.
Output from lspci (desktop computer, Linux 5.2.9):
08:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Baffin [Radeon RX 460/560D / Pro 450/455/460/555/555X/560/560X] (rev cf)
Output from glxinfo | grep OpenGL:
OpenGL vendor string: X.Org
OpenGL renderer string: AMD Radeon ™ RX 460 Graphics (POLARIS11, DRM 3.32.0, 5.2.9-1-default, LLVM 8.0.1)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.1.5
OpenGL core profile shading language version string: 4.50
OpenGL shading language version string: 4.50
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 19.1.5
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
The computer boots properly with the “nomodeset” flag, but this is not the solution to the problem due to lack of graphical acceleration and low resolution (1024x768).
Have you tried appending either amdgpu.dc=0 or amdgpu.dc=1 instead of nomodeset? Nomodeset is for troubleshooting and rescue, while amdgpu.dc= can be a satisfactory workaround with some AMD graphics devices.
What is output from:
inxi -Gxx
run from older kernel in X environment terminal (Konsole, XTerm, Gnome-Terminal, etc.)? Inxi and/or Mesa-demo-x might not be already installed.
I should mention that the BIOS on this laptop cannot be changed to Legacy boot mode.
There are a few other problems because of this, such as a non-working touchpad after booting (in 95% of cases), but that’s another topic.
I’ll try these flags (amdgpu.dc= 0 or 1) in a moment.
Unusual for xdpyinfo to not be installed. Did this start out as a minimal installation with norecommends, or have solver.onlyRequires = true in zypp.conf afterward?
I haven’t changed anything in the amdgpu packages, everything is the same since the installation. After installing xdpyinfo the output is OK, I didn’t find anything suspicious.
I didn’t expect it - 5.3.10-1 on LiveUSB boots correctly (except for VERY heavy graphic artifacts/corruption, but that can be fixed completely with the iommu=pt flag (I wonder why it is enabled by default). Even touchpad works!
(I tried xdpyinfo command, it is not installed there either.)
I wonder where the problem might be, because I am not going to reinstall the whole system from scratch.
Is there any tool to check kernel module differences? Maybe the update hasn’t unpacked something that should be required for the amdgpu to work properly?
It is also possible that the difference in the file versions of the amdgpu modules may cause it. It is hard to say.
What I really wanted to see was inxi -GxxSaz with all its recommends installed, but the version of inxi in TW is too old to do that. Upstream added info from -a shortly after 3.0.32 (it’s just a script).
This has to be specific either to the latest Radeon graphics hardware, or to UEFI, as I have an older Oland GCN using amdgpu DDX working fine with both 2560x1440 on DisplayPort and 1920x1200 on DVI with 20190708, kernel 5.1.16 and firmware 20190618 before, and 20190829, kernel 5.2.10 and firmware 20190815 after:
# inxi -V | head -n1
inxi 3.0.36-00 (2019-08-14)
# inxi -GxxSaz
System: Host: big31 Kernel: 5.2.10-1-default x86_64 bits: 64 compiler: gcc v: 9.2.1
parameters: root=LABEL=sda30 ipv6.disable=1 net.ifnames=0 noresume mitigations=auto consoleblank=0
radeon.si_support=0 amdgpu.si_support=1 vga=791 video=1280x720@60 video=1024x768@60 video=1440x900@60 5
Desktop: KDE 3 wm: kwin dm: N/A Distro: openSUSE Tumbleweed 20190829
Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Oland [Radeon HD 8570 / R7 240/340 OEM] vendor: Dell driver: amdgpu
v: kernel bus ID: 01:00.0 chip ID: 1002:6611
Display: x11 server: X.Org 1.20.5 driver: amdgpu unloaded: fbdev,modesetting,vesa alternate: ati
resolution: 2560x1440~60Hz, 1920x1200~60Hz
OpenGL: renderer: AMD Radeon HD 8500 Series (OLAND DRM 3.32.0 5.2.10-1-default LLVM 8.0.1) v: 4.5 Mesa 19.1.5
direct render: Yes
# xrandr | egrep 'onnect|creen|\*' | grep -v disconn | sort -r
Screen 0: minimum 320 x 200, current 2560 x 2640, maximum 16384 x 16384
DisplayPort-0 connected primary 2560x1440+0+1200 (normal left inverted right x axis y axis) 598mm x 336mm
DVI-I-0 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 519mm x 324mm
2560x1440 59.95*+ 74.92
1920x1200 59.95*+
I just want to announce that in the recently released version of kernel 5.2.11-1 the problem still exists. Because of the update, the working version 5.2.9 was automatically removed from /boot. Now I can’t turn on the system at all without nomodeset.
It looks like the GPU driver works only on version 5.2.9 only (neither older nor newer kernels work).
I would also like to say that this is the same version of Linux I had after installing the system a few weeks ago.
Earlier in my work I had to program in graphic mode 1024x768 without GPU acceleration for 7 hours. It was not pleasant rotfl!
I installed this .rpm - the system started to turn on correctly. But this is only a temporary solution.
Then I decided to go deeper into the subject, why doesn’t the amdgpu firmware load in the newest kernel.
What I did, it really worked.
After many hours of trying, I managed to fix the problem.
The problem most likely occurs ONLY in OpenSUSE (bug?).
I noticed that the files in the folder /lib/firmware/5.2.9-1/amdgpu/ are from June 6, 2019. Most interestingly, the files in the folder /lib/firmware/5.2.10-1/amdgpu/ have the same modification date and content.
The same applies to all files in the folder /lib/firmware/amdgpu/
Zypper doesn’t update them at all.
The only time they are installed is during the first installation of the system.
I flashed LiveUSB on a flash drive with kernel version 5.2.11-1 (currently it is the newest one)
Then I removed ABSOLUTELY ALL files from /lib/firmware/<xxx>/amdgpu and /lib/firmware/amdgpu and then replaced them with LiveUSB files.
I also copied Linux image with 5.2.11 kernel to /boot.
Then I booted the computer normally (still with nomodeset), made a grub2-mkconfig (to detect the latest kernel), restarted the computer with normal kernel parameters and… It works!
I can safely say that the problem lies in opensuse, that it is not able to update the firmware for some reason, leaving it untouched from the beginning of the system installation.
P.S. Touchpad doesn’t work again, but it’s a different topic
(image of a working updated kernel with glxinfo, glxgears and inxi on KDE Plasma) https://imgur.com/a/aWclQUU
Flashing .iso and copying files is also a some kind of solution, but I doubt that someone would like it
I wonder where exactly the problem is.
The idea is to keep a known working kernel around.
Every now and then I will manually delete the oldest kernel, so that a more recent kernel becomes the new “oldest”. But I only do that when that is known to be a good working kernel.
5.2.9 is still available in the boot menu, the last option. For Lenovo, we have the same system, must use iommu=soft to boot in Linux, if not the laptop won’t boot = black screen.
