Hmm. radeonsi_dri.so sounds more like a regression in Mesa, than a firmware issue.

If you need a workaround please let me know. We'll find sth.

Thanks Stefan for your interest.

As for a workaround I can do a "rollback snapper", do you suggest something different?

Do you expect the bug fix to be long?
Because obviously at the moment I have the updates blocked (unfortunately I have other similar notebooks).

TIA
Roberto

If you can do a rollback snapper does, use this. I can't say when the regression in Mesa will be fixed.

Workaround would be to remove/hide radeonsi DRI driver, so swrast DRI (software rendering/llvmpipe) will be active.

I have the same issue and in the beginning I thought that was sth to do with the kde6 upgrade but looks more likely to radeon in Mesa I you suggest.

kernel: show_signal_msg: 59 callbacks suppressed
Mar 31 12:20:56 desktop.dinamizm.com kernel: QSGRenderThread[1998]: segfault at 40 ip 00007ff12e32b98d sp 00007ff0d8dff1d0 error 4 in radeonsi_dri.so[7ff12dc91000+1476000] likely on CPU 1 >
Mar 31 12:20:56 desktop.dinamizm.com kernel: Code: 8b 6f 30 85 ed 0f 84 e5 00 00 00 31 db 49 89 e5 eb 34 0f 1f 00 4d 03 77 38 49 8b 36 48 85 f6 74 0e f0 83 2e 01 75 08 4c 89 e7 <41> ff 54 >
Mar 31 12:20:56 desktop.dinamizm.com sddm-helper[1885]: 


As a workaround I used the following cmdline options radeon.si_support=0 amdgpu.si_support=1

This enables at least the graphical environment but it is not the ideal solution

(In reply to Togan Muftuoglu from comment #5)
> I have the same issue and in the beginning I thought that was sth to do with
> the kde6 upgrade but looks more likely to radeon in Mesa I you suggest.
> 
> kernel: show_signal_msg: 59 callbacks suppressed
> Mar 31 12:20:56 desktop.dinamizm.com kernel: QSGRenderThread[1998]: segfault
> at 40 ip 00007ff12e32b98d sp 00007ff0d8dff1d0 error 4 in
> radeonsi_dri.so[7ff12dc91000+1476000] likely on CPU 1 >
> Mar 31 12:20:56 desktop.dinamizm.com kernel: Code: 8b 6f 30 85 ed 0f 84 e5
> 00 00 00 31 db 49 89 e5 eb 34 0f 1f 00 4d 03 77 38 49 8b 36 48 85 f6 74 0e
> f0 83 2e 01 75 08 4c 89 e7 <41> ff 54 >
> Mar 31 12:20:56 desktop.dinamizm.com sddm-helper[1885]: 
> 
> 
> As a workaround I used the following cmdline options radeon.si_support=0
> amdgpu.si_support=1
> 
> This enables at least the graphical environment but it is not the ideal
> solution

Hi Togan,

I thank you for your work around, I just can't understand in which configuration file I have to set the "radeon.si_support" and "amdgpu.si_support" options

As you say it's not the best solution, but if it allows me to work it's fine.

TIA Roberto

(In reply to Roberto Canella from comment #6)
> (In reply to Togan Muftuoglu from comment #5)
> > I have the same issue and in the beginning I thought that was sth to do with
> > the kde6 upgrade but looks more likely to radeon in Mesa I you suggest.
> > 
> > kernel: show_signal_msg: 59 callbacks suppressed
> > Mar 31 12:20:56 desktop.dinamizm.com kernel: QSGRenderThread[1998]: segfault
> > at 40 ip 00007ff12e32b98d sp 00007ff0d8dff1d0 error 4 in
> > radeonsi_dri.so[7ff12dc91000+1476000] likely on CPU 1 >
> > Mar 31 12:20:56 desktop.dinamizm.com kernel: Code: 8b 6f 30 85 ed 0f 84 e5
> > 00 00 00 31 db 49 89 e5 eb 34 0f 1f 00 4d 03 77 38 49 8b 36 48 85 f6 74 0e
> > f0 83 2e 01 75 08 4c 89 e7 <41> ff 54 >
> > Mar 31 12:20:56 desktop.dinamizm.com sddm-helper[1885]: 
> > 
> > 
> > As a workaround I used the following cmdline options radeon.si_support=0
> > amdgpu.si_support=1
> > 
> > This enables at least the graphical environment but it is not the ideal
> > solution
> 
> Hi Togan,
> 
> I thank you for your work around, I just can't understand in which
> configuration file I have to set the "radeon.si_support" and
> "amdgpu.si_support" options
> 
> As you say it's not the best solution, but if it allows me to work it's fine.
> 
> TIA Roberto


Add these options to your GRUB_CMDLINE_LINUX_DEFAULT that you find in /etc/default/grub and then run 'grub2-mkconfig -o /boot/grub2/grub.cfg' afterwards to update /boot/grub2/grub.cfg.

(In reply to Togan Muftuoglu from comment #7)
> (In reply to Roberto Canella from comment #6)
> > (In reply to Togan Muftuoglu from comment #5)
> > > I have the same issue and in the beginning I thought that was sth to do with
> > > the kde6 upgrade but looks more likely to radeon in Mesa I you suggest.
> > > 
> > > kernel: show_signal_msg: 59 callbacks suppressed
> > > Mar 31 12:20:56 desktop.dinamizm.com kernel: QSGRenderThread[1998]: segfault
> > > at 40 ip 00007ff12e32b98d sp 00007ff0d8dff1d0 error 4 in
> > > radeonsi_dri.so[7ff12dc91000+1476000] likely on CPU 1 >
> > > Mar 31 12:20:56 desktop.dinamizm.com kernel: Code: 8b 6f 30 85 ed 0f 84 e5
> > > 00 00 00 31 db 49 89 e5 eb 34 0f 1f 00 4d 03 77 38 49 8b 36 48 85 f6 74 0e
> > > f0 83 2e 01 75 08 4c 89 e7 <41> ff 54 >
> > > Mar 31 12:20:56 desktop.dinamizm.com sddm-helper[1885]: 
> > > 
> > > 
> > > As a workaround I used the following cmdline options radeon.si_support=0
> > > amdgpu.si_support=1
> > > 
> > > This enables at least the graphical environment but it is not the ideal
> > > solution
> > 
> > Hi Togan,
> > 
> > I thank you for your work around, I just can't understand in which
> > configuration file I have to set the "radeon.si_support" and
> > "amdgpu.si_support" options
> > 
> > As you say it's not the best solution, but if it allows me to work it's fine.
> > 
> > TIA Roberto
> 
> 
> Add these options to your GRUB_CMDLINE_LINUX_DEFAULT that you find in
> /etc/default/grub and then run 'grub2-mkconfig -o /boot/grub2/grub.cfg'
> afterwards to update /boot/grub2/grub.cfg.

Hi Soan,

tried your solution, but in my case it doesn't work; the parameters are set, as seen from the following cat /proc/cmdline:

cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.8.1-1-default root=UUID=f27938c4-c142-4dbf-836c-6862cc2630f9 radeon.si_support=0 amdgpu.si_support=1 splash=silent mitigations=auto quiet security=apparmor

But unfortunately the graphical interface does not start; sin...

Thank you

I'll add some information to the thread.

I replaced the laptop hard disk with a new one and tried to install tumbleweed from scratch and the problem occurred again.

The situation isn't great, but I'm happy that this is the result... some will think that the test was useless, but in my opinion the result wasn't a given.

Roberto

Togan switches with his option to the newer amdgpu Kernel driver (which isn't default for his Radeon GPU). I doubt this changes also the Mesa driver. But seems this prevents the segfault.

@Robert I think you have a different Radeon GPU, so you can't easily switch to amdgpu driver or the support for it isn't working (there is a reason that default kernel driver is radeon and not amdgpu). So this doesn't help.

I suggest to either do a rollback or disable radeon kernel driver completely with
adding 

  modprobe.blacklist=radeon

to GRUB_CMDLINE_LINUX_DEFAULT (see comment#7). With that you'll get simpledrm
on top of generic framebuffer. Means no 2d/3d acceleration and no multimonitor support, but you should have a stable desktop back.

And please remove this again

  radeon.si_support=0 amdgpu.si_support=1 

from GRUB_CMDLINE_LINUX_DEFAULT.

I guess our problem is similar to the one listed on https://gitlab.freedesktop.org/mesa/mesa/-/issues/10839

(In reply to Stefan Dirsch from comment #10)
> Togan switches with his option to the newer amdgpu Kernel driver (which
> isn't default for his Radeon GPU). I doubt this changes also the Mesa
> driver. But seems this prevents the segfault.
> 
> @Robert I think you have a different Radeon GPU, so you can't easily switch
> to amdgpu driver or the support for it isn't working (there is a reason that
> default kernel driver is radeon and not amdgpu). So this doesn't help.
> 
> I suggest to either do a rollback or disable radeon kernel driver completely
> with
> adding 
> 
>   modprobe.blacklist=radeon
> 
> to GRUB_CMDLINE_LINUX_DEFAULT (see comment#7). With that you'll get simpledrm
> on top of generic framebuffer. Means no 2d/3d acceleration and no
> multimonitor support, but you should have a stable desktop back.

Hi Stefan,
given the security problem that arose with xz, I preferred not to do the "snapper rollback" and update the system... so I did as you suggested and put the radeon on the blacklist. Now everything works correctly even if not at its best, however I prefer it this way and not have possible security problems.

Thank you

Ok. Makes sense. Thanks for feedback.

*** Bug 1222213 has been marked as a duplicate of this bug. ***

I'm still not sure whether it's a regression in Mesa (radeonsi DRI driver) or an issue in radeon kernel driver. I mean the issue doesn't occur for users being able to switch to amdgpu kernel driver and I'm pretty sure radeonsi DRI driver is still being used with that configuration.

(In reply to Stefan Dirsch from comment #16)
> I'm still not sure whether it's a regression in Mesa (radeonsi DRI driver)
> or an issue in radeon kernel driver. I mean the issue doesn't occur for
> users being able to switch to amdgpu kernel driver and I'm pretty sure
> radeonsi DRI driver is still being used with that configuration.

You are correct with the assumption as I see in lsmod

drm_display_helper    245760  2 amdgpu,radeon

and I can see in Xorg log

] (II) AMDGPU(0): [DRI2] Setup complete
[    15.655] (II) AMDGPU(0): [DRI2]   DRI driver: radeonsi
[    15.655] (II) AMDGPU(0): [DRI2]   VDPAU driver: radeonsi

So am I really using amdgpu or radeon weird

@Togan

You're using 

  radeon.si_support=0 amdgpu.si_support=1

right? I believe with that radeon kernel module is still being loaded but doesn't initialize anything. So just amdgpu is active in that case.

Usage of radeonsi DRI driver for 2D acceleration in Xserver is hardcoded. So this stays.

radeonsi also stays for Mesa, because that's the radeon driver for current AMD Radeon cards and r300 and r600 is only for older cards.

So could be that latest radeonsi Mesa driver triggers a bug in latest radeon kernel module.

To confirm that radeonsi DRI modules is still loaded you could run. strace needs to be installed though.

  strace -f -e trace=file glxinfo -B 2>&1 | grep radeonsi_dri

Could anyone try to boot with an older kernel to see if the regression is in the kernel? Unfortunately I don't know which kernel this would be. :-(

Adding our kernel guys. @Patrik @Thomas @Takashi Which information is needed?

(In reply to Stefan Dirsch from comment #18)
> @Togan
> 
> You're using 
> 
>   radeon.si_support=0 amdgpu.si_support=1
> 
> right? I believe with that radeon kernel module is still being loaded but
> doesn't initialize anything. So just amdgpu is active in that case.
> 
> Usage of radeonsi DRI driver for 2D acceleration in Xserver is hardcoded. So
> this stays.
> 
> radeonsi also stays for Mesa, because that's the radeon driver for current
> AMD Radeon cards and r300 and r600 is only for older cards.
> 
> So could be that latest radeonsi Mesa driver triggers a bug in latest radeon
> kernel module.

That is correct I am using the radeon.si_support=0 amdgpu.si_support=1 in the cmdline as it is the only way I can have a graphical display. Previously I didn'd need that.

(In reply to Stefan Dirsch from comment #19)
> To confirm that radeonsi DRI modules is still loaded you could run. strace
> needs to be installed though.
> 
>   strace -f -e trace=file glxinfo -B 2>&1 | grep radeonsi_dri

Here is the output 

openat(AT_FDCWD, "/usr/lib64/dri/tls/radeonsi_dri.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib64/dri/radeonsi_dri.so", O_RDONLY|O_CLOEXEC) = 5

If it's a kernel regression, please clarify which kernel still worked and which one started showing the problem.  You can find some older packages in TW history repo
  http://download.opensuse.org/history/
and install the older kernel packages with zypper install --oldpackage option.

(In reply to Togan Muftuoglu from comment #23)
> (In reply to Stefan Dirsch from comment #19)
> > To confirm that radeonsi DRI modules is still loaded you could run. strace
> > needs to be installed though.
> > 
> >   strace -f -e trace=file glxinfo -B 2>&1 | grep radeonsi_dri
> 
> Here is the output 
> 
> openat(AT_FDCWD, "/usr/lib64/dri/tls/radeonsi_dri.so", O_RDONLY|O_CLOEXEC) =
> -1 ENOENT (No such file or directory)
> openat(AT_FDCWD, "/usr/lib64/dri/radeonsi_dri.so", O_RDONLY|O_CLOEXEC) = 5

Thanks! This confirms my assumption.

(In reply to Stefan Dirsch from comment #10)
> Togan switches with his option to the newer amdgpu Kernel driver (which
> isn't default for his Radeon GPU). I doubt this changes also the Mesa
> driver. But seems this prevents the segfault.
> 
> @Robert I think you have a different Radeon GPU, so you can't easily switch
> to amdgpu driver or the support for it isn't working (there is a reason that
> default kernel driver is radeon and not amdgpu). So this doesn't help.
> 
> I suggest to either do a rollback or disable radeon kernel driver completely
> with
> adding 
> 
>   modprobe.blacklist=radeon
> 
> to GRUB_CMDLINE_LINUX_DEFAULT (see comment#7). With that you'll get simpledrm
> on top of generic framebuffer. Means no 2d/3d acceleration and no
> multimonitor support, but you should have a stable desktop back.

Adding modprobe.blacklist to the GRUB command makes my machine bootable in graphical target again. 

@Takashi the issues arose with the last complete rebuild image from Tumbleweed (VERSION="20270329"), due to XZ backdoor. It effects kernel 6.8.1-1-default. The last known kernel that I have to test with and works is 6.7.8.x

The last 6.7.x package found in TW history repo is 6.7.9.  It's appreciated if you can verify that it's a kernel regression and the regression range is between 6.7.9 and 6.8.1.

(In reply to Takashi Iwai from comment #27)
> The last 6.7.x package found in TW history repo is 6.7.9.  It's appreciated
> if you can verify that it's a kernel regression and the regression range is
> between 6.7.9 and 6.8.1.

I just tried kernel 6.7.7 from http://download.opensuse.org/history/20240305/tumbleweed/repo/oss/ and kernel 6.7.9 that I had still installed. Both showed the exact same behavior as kernel 6.8.1. With all three kernels, sddm-greeter-qt6 crashes if used with kernel driver "radeon".

Created attachment 874014 [details]
journalctl stack-trace of crashed process sddm-greeter-qt6 with kenrel 6.7.7

Created attachment 874016 [details]
journalctl stack-trace of crashed process sddm-greeter-qt6 with kenrel 6.7.9

According to this comment it is related to Mesa.
https://forums.opensuse.org/t/after-tw-update-i-cant-enter-anything-at-login-screen/173701/10

(The following is just conjecture, FYI)

Indeed, following t neo's last (#31) comment, I see that Mesa 24.0 and 24.01 have both had various radeonsi fixes.

- https://docs.mesa3d.org/relnotes/24.0.0.html

- https://docs.mesa3d.org/relnotes/24.0.1.html

And, as it states at the top of each of both pages:

---------------
"Mesa 24.0.1 implements the OpenGL 4.6 API, but the version reported by glGetString(GL_VERSION) or glGetIntegerv(GL_MAJOR_VERSION) / glGetIntegerv(GL_MINOR_VERSION) depends on the particular driver being used. Some drivers don’t support all the features required in OpenGL 4.6. OpenGL 4.6 is only available if requested at context creation. Compatibility contexts may report a lower version depending on each driver.

Mesa 24.0.1 implements the Vulkan 1.3 API, but the version reported by the apiVersion property of the VkPhysicalDeviceProperties struct depends on the particular driver being used."
---------------

And my /guess/ is this is the issue: Probably some feature of Vulkan is not (yet) implemented in this older radeon driver (?)

> Probably some feature of Vulkan is not (yet) implemented in this older radeon driver (?)

Vulkan or Mesa

(In reply to Jeff Stern from comment #32)
> (The following is just conjecture, FYI)
> 
> Indeed, following t neo's last (#31) comment, I see that Mesa 24.0 and 24.01
> have both had various radeonsi fixes.
> 
> - https://docs.mesa3d.org/relnotes/24.0.0.html
> 
> - https://docs.mesa3d.org/relnotes/24.0.1.html
> 
> And, as it states at the top of each of both pages:
> 
> ---------------
> "Mesa 24.0.1 implements the OpenGL 4.6 API, but the version reported by
> glGetString(GL_VERSION) or glGetIntegerv(GL_MAJOR_VERSION) /
> glGetIntegerv(GL_MINOR_VERSION) depends on the particular driver being used.
> Some drivers don’t support all the features required in OpenGL 4.6. OpenGL
> 4.6 is only available if requested at context creation. Compatibility
> contexts may report a lower version depending on each driver.
> 
> Mesa 24.0.1 implements the Vulkan 1.3 API, but the version reported by the
> apiVersion property of the VkPhysicalDeviceProperties struct depends on the
> particular driver being used."
> ---------------
> 
> And my /guess/ is this is the issue: Probably some feature of Vulkan is not
> (yet) implemented in this older radeon driver (?)

There was a similar problem in Flatpak as well previously and even though the normal graphic display would work with the radeon driver none of the flatpak apps that were using flatpak mesa packages were working. Before current situation flatpak had solved the radeon issue in 24.0.2 release. Could it what ever fixed was never upstreamed?

Is there a repo where I can download previous Mesa rpms that are not subject to xz backdoor?

You can check the slow-roll repo and get Mesa 23 from there.

No problems from Radeon GCN #1 here. Does this answer the needinfo?
# pinxi -GSaz --vs --zl --hostname
pinxi 3.3.33-08 (2024-03-28)
System:
  Host: fi965 Kernel: 6.6.25-1-longterm arch: x86_64 bits: 64 compiler: gcc
    v: 13.2.1 clocksource: tsc avail: hpet,acpi_pm
    parameters: root=LABEL=<filter> ipv6.disable=1 net.ifnames=0
    radeon.si_support=0 amdgpu.si_support=1 noresume consoleblank=0
    mitigations=off
  Desktop: KDE Plasma v: 5.27.10 tk: Qt v: 5.15.12 info: frameworks
    v: 5.115.0 wm: kwin_x11 vt: 7 dm: XDM Distro: openSUSE Tumbleweed-Slowroll
    20240405
Graphics:
  Device-1: AMD Oland [Radeon HD 8570 / R5 430 OEM R7 240/340 Radeon 520 OEM]
    vendor: Dell driver: amdgpu v: kernel alternate: radeon arch: GCN-1
    code: Southern Islands process: TSMC 28nm built: 2011-20 pcie: gen: 1
    speed: 2.5 GT/s lanes: 8 link-max: gen: 3 speed: 8 GT/s ports:
    active: DP-1,DVI-I-1 empty: none bus-ID: 01:00.0 chip-ID: 1002:6611
    class-ID: 0300 temp: 53.0 C
  Display: x11 server: X.Org v: 21.1.12 compositor: kwin_x11 driver: X:
    loaded: amdgpu unloaded: modesetting alternate: fbdev,vesa dri: radeonsi
    gpu: amdgpu display-ID: :0 screens: 1
  Screen-1: 0 s-res: 2560x2490 s-dpi: 120 s-size: 541x527mm (21.30x20.75")
    s-diag: 755mm (29.73")
  Monitor-1: DVI-I-1 mapped: DVI-I-0 pos: top model: Dell P2213
    serial: <filter> built: 2012 res: 1680x1050 hz: 60 dpi: 90 gamma: 1.2
    size: 473x296mm (18.62x11.65") diag: 558mm (22") ratio: 16:10 modes:
    max: 1680x1050 min: 720x400
  Monitor-2: DP-1 mapped: DisplayPort-0 pos: primary,bottom
    model: Acer K272HUL serial: <filter> built: 2018 res: 2560x1440 hz: 60
    dpi: 109 gamma: 1.2 size: 598x336mm (23.54x13.23") diag: 686mm (27")
    ratio: 16:9 modes: max: 2560x1440 min: 720x400
  API: EGL v: 1.5 hw: drv: amd radeonsi platforms: device: 0 drv: radeonsi
    device: 1 drv: swrast gbm: drv: radeonsi surfaceless: drv: radeonsi x11:
    drv: radeonsi inactive: wayland
  API: OpenGL v: 4.6 compat-v: 4.5 vendor: amd mesa v: 24.0.3 glx-v: 1.4
    direct-render: yes renderer: AMD Radeon R7 200 Series (radeonsi oland LLVM
    18.1.2 DRM 3.54 6.6.25-1-longterm) device-ID: 1002:6611 memory: 1000 MiB
    unified: no
  API: Vulkan v: 1.3.280 layers: 1 device: 0 type: discrete-gpu name: AMD
    Radeon R7 200 Series (RADV OLAND) driver: N/A device-ID: 1002:6611
    surfaces: xcb,xlib device: 1 type: cpu name: llvmpipe (LLVM 18.1.2 128
    bits) driver: N/A device-ID: 10005:0000 surfaces: xcb,xlib
# zypsei Mesa radeon
i  | Mesa                      | package | 24.0.3-372.1 | x86_64 | OSS
i  | Mesa                      | package | 24.0.3-372.1 | x86_64 | Update
i  | Mesa-dri                  | package | 24.0.3-372.1 | x86_64 | OSS
i  | Mesa-dri                  | package | 24.0.3-372.1 | x86_64 | Update
i  | Mesa-gallium              | package | 24.0.3-372.1 | x86_64 | OSS
i  | Mesa-gallium              | package | 24.0.3-372.1 | x86_64 | Update
i  | Mesa-libEGL1              | package | 24.0.3-372.1 | x86_64 | OSS
i  | Mesa-libEGL1              | package | 24.0.3-372.1 | x86_64 | Update
i  | Mesa-libGL1               | package | 24.0.3-372.1 | x86_64 | OSS
i  | Mesa-libGL1               | package | 24.0.3-372.1 | x86_64 | Update
i  | Mesa-libglapi0            | package | 24.0.3-372.1 | x86_64 | OSS
i  | Mesa-libglapi0            | package | 24.0.3-372.1 | x86_64 | Update
i  | kernel-firmware-radeon    | package | 20240322-2.1 | noarch | OSS
i  | libdrm_radeon1            | package | 2.4.120-1.3  | x86_64 | OSS
i  | libdrm_radeon1            | package | 2.4.120-1.3  | x86_64 | Update
i+ | Mesa-demo-egl             | package | 9.0.0-3.3    | x86_64 | OSS
i+ | Mesa-demo-egl             | package | 9.0.0-3.3    | x86_64 | Update
i+ | Mesa-demo-x               | package | 9.0.0-3.3    | x86_64 | OSS
i+ | Mesa-demo-x               | package | 9.0.0-3.3    | x86_64 | Update
i+ | Mesa-libOpenCL            | package | 24.0.3-372.1 | x86_64 | OSS
i+ | Mesa-libOpenCL            | package | 24.0.3-372.1 | x86_64 | Update
i+ | Mesa-libd3d               | package | 24.0.3-372.1 | x86_64 | OSS
i+ | Mesa-libd3d               | package | 24.0.3-372.1 | x86_64 | Update
i+ | Mesa-libva                | package | 24.0.3-372.1 | x86_64 | OSS
i+ | Mesa-libva                | package | 24.0.3-372.1 | x86_64 | Update
i+ | Mesa-vulkan-device-select | package | 24.0.3-372.1 | x86_64 | OSS
i+ | Mesa-vulkan-device-select | package | 24.0.3-372.1 | x86_64 | Update
i+ | libvulkan_radeon          | package | 24.0.3-372.1 | x86_64 | OSS
i+ | libvulkan_radeon          | package | 24.0.3-372.1 | x86_64 | Update
#

No, I think the needinfo was set for comment#24 / comment#27.

(In reply to Felix Miata from comment #37)
> No problems from Radeon GCN #1 here. Does this answer the needinfo?
> # pinxi -GSaz --vs --zl --hostname
> pinxi 3.3.33-08 (2024-03-28)
> System:
>   Host: fi965 Kernel: 6.6.25-1-longterm arch: x86_64 bits: 64 compiler: gcc
>     v: 13.2.1 clocksource: tsc avail: hpet,acpi_pm
>     parameters: root=LABEL=<filter> ipv6.disable=1 net.ifnames=0
>     radeon.si_support=0 amdgpu.si_support=1 noresume consoleblank=0
>     mitigations=off

Also you're overwriting the default of radeon kernel driver to use amdgpu kernel driver instead. We already know about this workaround where it is applicable.

Created attachment 874268 [details]
dataset - annotated output from "grep root cmd* > dirlist.txt"

I booted the comment #37 PC to Fedora 39 with Plasma 5.27.11 using 
radeon.si_support=1 amdgpu.si_support=0 amdgpu.modeset=0 modprobe.blacklist=amdgpu
to find all working as expected with every kernel tried:
kernel-core-6.6.14-200.fc39.x86_64
kernel-core-6.7.9-200.fc39.x86_64
kernel-core-6.7.10-200.fc39.x86_64
kernel-core-6.7.11-200.fc39.x86_64
kernel-core-6.7.12-200.fc39.x86_64
kernel-core-6.8.1-201.fc39.x86_64
kernel-core-6.8.5-200.fc39.x86_64
# rpm -qa | grep mesa | sort
mesa-dri-drivers-23.3.6-1.fc39.x86_64
mesa-filesystem-23.3.6-1.fc39.x86_64
mesa-libEGL-23.3.6-1.fc39.x86_64
mesa-libgbm-23.3.6-1.fc39.x86_64
mesa-libGL-23.3.6-1.fc39.x86_64
mesa-libglapi-23.3.6-1.fc39.x86_64
mesa-libGLU-9.0.3-1.fc39.x86_64
mesa-vulkan-drivers-23.3.6-1.fc39.x86_64
# lsmod | egrep 'rade|amd|vid' | sort # 6.8.5 running
drm_display_helper    237568  1 radeon
drm_suballoc_helper    12288  1 radeon
drm_ttm_helper         12288  1 radeon
i2c_algo_bit           20480  1 radeon
radeon               2076672  3
ttm                   110592  2 radeon,drm_ttm_helper
video                  77824  1 radeon
wmi                    36864  1 video
#
When I boot TW20240410 on same PC using kernel-default 6.6.11 with the same parameters as with Fedora
"radeon.si_support=1 amdgpu.si_support=0 modprobe.blacklist=amdgpu amdgpu.modeset=0"
VT I/O locks around the time KMS engagement is expected. Using only radeon.si_support=1 amdgpu.si_support=0" it does the same thing. So in order to try to answer comment #27 & 24, I continued to assume it was a kernel regression, just not one so recent. I booted every still installed kernel up to about 9 times on my two TW installations on my Oland PC looking for any change in behavior pattern. The attachment is my accumulated data set. Each line in the 86 boot set is the content of /proc/cmdline output saved to a separate file, and accumulated thus: "grep root cmd* > dirlist.txt". Each filename describes the boot thus:

"cmdline" | kernel ver | timestamp | behavior* | content of /proc/cmdline

The root parameter in each distinguishes which TW installation it came from.

My conclusion is that if this problem has anything to do with the kernel, it happened before 6.0.12, and it's apparently exclusive to openSUSE. The only means through cmdline parameters that I have found to have properly working Xorg in TW on my Oland is to include something to ensure the radeon kernel module is not responsible for KMS, either modprobe.blacklist=radeon and/or amdgpu.si_support=1. Attempting boot otherwise locks up local I/O around the KMS start point.

This took exceedingly long, much longer than expected, in large part because the PC is slow to restart, but also because I got unexpected failures from the sTWp21w71 that took a long time to find (which as yet I don't know how to properly fix). Starting with 6.2.12, it became necessary to boot with both  modprobe.blacklist=radeon *and* amdgpu.si_support=1 to succeed. Eventually I found that using sTWp21w71's 6.6.11 ~110k larger initrd would solve it. /etc/dracut.d/ on one is a twin of the other's, as are the /etc/dracut.confs. The only difference between the two installation's initrds I've been able to determine is sTWp21w71's dracut is not using Early CPIO and sTWp10w71's is. Why the difference I've also not yet been able to determine.

(In reply to Felix Miata from comment #40)
> Created attachment 874268 [details]
> dataset - annotated output from "grep root cmd* > dirlist.txt"
> 
> I booted the comment #37 PC to Fedora 39 with Plasma 5.27.11 using 
> radeon.si_support=1 amdgpu.si_support=0 amdgpu.modeset=0
> modprobe.blacklist=amdgpu
> to find all working as expected with every kernel tried:

> mesa-dri-drivers-23.3.6-1.fc39.x86_64
> mesa-filesystem-23.3.6-1.fc39.x86_64
> mesa-libEGL-23.3.6-1.fc39.x86_64
> mesa-libgbm-23.3.6-1.fc39.x86_64
> mesa-libGL-23.3.6-1.fc39.x86_64
> mesa-libglapi-23.3.6-1.fc39.x86_64
> mesa-libGLU-9.0.3-1.fc39.x86_64
> mesa-vulkan-drivers-23.3.6-1.fc39.x86_64

They are Mesa 23, and in Tumbleweed it is Mesa 24.0.3 there is your reasoning why it works with Fedora. I am inclined to assume Fedora with Mesa 24.0.3 will also have the same problem.

(In reply to Togan Muftuoglu from comment #41)
> They are Mesa 23, and in Tumbleweed it is Mesa 24.0.3 there is your
> reasoning why it works with Fedora. I am inclined to assume Fedora with Mesa
> 24.0.3 will also have the same problem.

It doesn't look like it, unless failure also depends on a newer X server than Fedora's antique:
# lsmod | egrep 'deon|amdg|vid'
radeon               2076672  3
i2c_algo_bit           20480  1 radeon
drm_suballoc_helper    12288  1 radeon
drm_ttm_helper         12288  1 radeon
ttm                   110592  2 radeon,drm_ttm_helper
drm_display_helper    229376  1 radeon
video                  77824  1 radeon
wmi                    45056  1 video
# inxi -GSaz --vs --zl --hostname
inxi 3.3.34-00 (2024-04-13)
System:
  Host: fi965 Kernel: 6.7.11-200.fc39.x86_64 arch: x86_64 bits: 64
    compiler: gcc v: 2.40-14.fc39 clocksource: tsc avail: hpet,acpi_pm
    parameters: ro root=LABEL=<filter> ipv6.disable=1 net.ifnames=0 audit=0
    selinux=0 noresume consoleblank=0 mitigations=off
    modprobe.blacklist=amdgpu radeon.si_support=1 amdgpu.si_support=0
  Desktop: IceWM v: 3.4.7 vt: 7 dm: 1: KDM 2: XDM Distro: Fedora Linux 40
    (Forty Prerelease)
Graphics:
  Device-1: AMD Oland [Radeon HD 8570 / R5 430 OEM R7 240/340 Radeon 520 OEM]
    vendor: Dell driver: radeon v: kernel alternate: amdgpu arch: GCN-1
    code: Southern Islands process: TSMC 28nm built: 2011-20 pcie: gen: 1
    speed: 2.5 GT/s lanes: 8 link-max: gen: 3 speed: 8 GT/s ports:
    active: DP-1,DVI-I-1 empty: none bus-ID: 01:00.0 chip-ID: 1002:6611
    class-ID: 0300 temp: 41.0 C
  Display: x11 server: X.Org v: 1.20.14 driver: X: loaded: modesetting
    unloaded: fbdev,vesa dri: radeonsi gpu: radeon display-ID: :0 screens: 1
  Screen-1: 0 s-res: 4240x1440 s-dpi: 120 s-size: 897x304mm (35.31x11.97")
    s-diag: 947mm (37.29")
  Monitor-1: DP-1 pos: primary,left model: Acer K272HUL serial: <filter>
    built: 2018 res: 2560x1440 hz: 60 dpi: 109 gamma: 1.2
    size: 598x336mm (23.54x13.23") diag: 686mm (27") ratio: 16:9 modes:
    max: 2560x1440 min: 720x400
  Monitor-2: DVI-I-1 pos: right model: Dell P2213 serial: <filter>
    built: 2012 res: 1680x1050 hz: 60 dpi: 90 gamma: 1.2
    size: 473x296mm (18.62x11.65") diag: 558mm (22") ratio: 16:10 modes:
    max: 1680x1050 min: 720x400
  API: EGL v: 1.5 hw: drv: amd radeonsi platforms: device: 0 drv: radeonsi
    device: 1 drv: swrast gbm: drv: radeonsi surfaceless: drv: radeonsi x11:
    drv: radeonsi inactive: wayland
  API: OpenGL v: 4.5 vendor: amd mesa v: 24.0.3 glx-v: 1.4
    direct-render: yes renderer: OLAND (radeonsi LLVM 18.1.0 DRM 2.50
    6.7.11-200.fc39.x86_64) device-ID: 1002:6611 memory: 1000 MiB unified: no
#

I am facing the same issue.

My system:

Operating System: openSUSE Tumbleweed 20240418
KDE Plasma Version: 6.0.4
KDE Frameworks Version: 6.1.0
Qt Version: 6.7.0
Kernel Version: 6.8.6-1-default (64-bit)
Graphics Platform: X11
Processors: 4 × AMD A8-7650K Radeon R7, 10 Compute Cores 4C+6G
Memory: 14.6 GiB of RAM
Graphics Processor: llvmpipe

Don't know if relevant, but for the time being, my workaround is with MESA/Vulkan 24.1.0 from repo home:Herbster0815. That the only chance to get to a graphical interface.

Vulkaninfo comes with the error message:
ERROR: [../src/amd/vulkan/radv_physical_device.c:1935] Code 0 : Device '/dev/dri/renderD128' is not using the AMDGPU kernel driver: Invalid argument (VK_ERROR_INCOMPATIBLE_DRIVER)

The system is very slow. It seems that the GPU is not used at all (as indicated by the error message).

(In reply to Sebastian Kuhne from comment #43)
> I am facing the same issue.
> 
> My system:
> 
> Operating System: openSUSE Tumbleweed 20240418
> KDE Plasma Version: 6.0.4
> KDE Frameworks Version: 6.1.0
> Qt Version: 6.7.0
> Kernel Version: 6.8.6-1-default (64-bit)
> Graphics Platform: X11
> Processors: 4 × AMD A8-7650K Radeon R7, 10 Compute Cores 4C+6G
> Memory: 14.6 GiB of RAM
> Graphics Processor: llvmpipe
> 
> Don't know if relevant, but for the time being, my workaround is with
> MESA/Vulkan 24.1.0 from repo home:Herbster0815. That the only chance to get
> to a graphical interface.
> 
> Vulkaninfo comes with the error message:
> ERROR: [../src/amd/vulkan/radv_physical_device.c:1935] Code 0 : Device
> '/dev/dri/renderD128' is not using the AMDGPU kernel driver: Invalid
> argument (VK_ERROR_INCOMPATIBLE_DRIVER)
> 
> The system is very slow. It seems that the GPU is not used at all (as
> indicated by the error message).

Is this with Mesa 24.0.1 of repo home:Herbster0815 or with the 24.0.3 of Tumbleweed?

(In reply to Stefan Dirsch from comment #44)
> (In reply to Sebastian Kuhne from comment #43)
> > I am facing the same issue.
> > 
> > My system:
> > 
> > Operating System: openSUSE Tumbleweed 20240418
> > KDE Plasma Version: 6.0.4
> > KDE Frameworks Version: 6.1.0
> > Qt Version: 6.7.0
> > Kernel Version: 6.8.6-1-default (64-bit)
> > Graphics Platform: X11
> > Processors: 4 × AMD A8-7650K Radeon R7, 10 Compute Cores 4C+6G
> > Memory: 14.6 GiB of RAM
> > Graphics Processor: llvmpipe
> > 
> > Don't know if relevant, but for the time being, my workaround is with
> > MESA/Vulkan 24.1.0 from repo home:Herbster0815. That the only chance to get
> > to a graphical interface.
> > 
> > Vulkaninfo comes with the error message:
> > ERROR: [../src/amd/vulkan/radv_physical_device.c:1935] Code 0 : Device
> > '/dev/dri/renderD128' is not using the AMDGPU kernel driver: Invalid
> > argument (VK_ERROR_INCOMPATIBLE_DRIVER)
> > 
> > The system is very slow. It seems that the GPU is not used at all (as
> > indicated by the error message).
> 
> Is this with Mesa 24.0.1 of repo home:Herbster0815 or with the 24.0.3 of
> Tumbleweed?

Neither nor. It is with Mesa 41.1.0 from home:Herbster0815 repo.

(In reply to Sebastian Kuhne from comment #45)
> (In reply to Stefan Dirsch from comment #44)
> > (In reply to Sebastian Kuhne from comment #43)
> > > I am facing the same issue.
> > > 
> > > My system:
> > > 
> > > Operating System: openSUSE Tumbleweed 20240418
> > > KDE Plasma Version: 6.0.4
> > > KDE Frameworks Version: 6.1.0
> > > Qt Version: 6.7.0
> > > Kernel Version: 6.8.6-1-default (64-bit)
> > > Graphics Platform: X11
> > > Processors: 4 × AMD A8-7650K Radeon R7, 10 Compute Cores 4C+6G
> > > Memory: 14.6 GiB of RAM
> > > Graphics Processor: llvmpipe
> > > 
> > > Don't know if relevant, but for the time being, my workaround is with
> > > MESA/Vulkan 24.1.0 from repo home:Herbster0815. That the only chance to get
> > > to a graphical interface.
> > > 
> > > Vulkaninfo comes with the error message:
> > > ERROR: [../src/amd/vulkan/radv_physical_device.c:1935] Code 0 : Device
> > > '/dev/dri/renderD128' is not using the AMDGPU kernel driver: Invalid
> > > argument (VK_ERROR_INCOMPATIBLE_DRIVER)
> > > 
> > > The system is very slow. It seems that the GPU is not used at all (as
> > > indicated by the error message).
> > 
> > Is this with Mesa 24.0.1 of repo home:Herbster0815 or with the 24.0.3 of
> > Tumbleweed?
> 
> Neither nor. It is with Mesa 41.1.0 from home:Herbster0815 repo.
Sorry 24.1.0.

Hmm. There is no 24.1.0. Latest is 24.0.5. home:Herbster0815 appears to use some git version/branch and calls it 24.1.0.

(In reply to Stefan Dirsch from comment #47)
> Hmm. There is no 24.1.0. Latest is 24.0.5. home:Herbster0815 appears to use
> some git version/branch and calls it 24.1.0.

Ok, this is possible of course. I can just see what is named there (attached a screenshot of YAST).

Created attachment 874391 [details]
Herbster0815

(In reply to Sebastian Kuhne from comment #48)
> (In reply to Stefan Dirsch from comment #47)
> > Hmm. There is no 24.1.0. Latest is 24.0.5. home:Herbster0815 appears to use
> > some git version/branch and calls it 24.1.0.
> 
> Ok, this is possible of course. I can just see what is named there (attached
> a screenshot of YAST).

Maybe worth to be mentioned - I have no additional boot options added, such as radeon.si_support=0 amdgpu.si_support=1, or similar.
My workaround only comes with home:Herbster0815 only. This is, as said, no solution as the system remains slow but at least I am capable to log in via the graphical interface. Also - this workaround works only on X11, not on Wayland. On Wayland, I still end up with a black screen.

Then, yesterday, I ran a Live CD with openSUSE TW, to ensure nothing is wrong with my installation. Stuck with a black screen.

Thanks. For some reason this Mesa git version let you switch to software only rendering (llvmpipe). So it's no solution either to update to Mesa git.

(In reply to Stefan Dirsch from comment #51)
> Thanks. For some reason this Mesa git version let you switch to software
> only rendering (llvmpipe). So it's no solution either to update to Mesa git.

Yes, that's right. Let me know if you need more information.

Created attachment 874395 [details]
coredump .zst file from tw20240419 & kernel 6.6.28 on GCN #2 Kaveri R7

modprobe.blacklist=radeon + amdgpu.cik_support=1 are a cmdline option pair that keeps my GCN #2 from crashing:

CPU: AMD A10-7850K Radeon R7
# inxi -GSaz --vs --hostname
inxi 3.3.34-00 (2024-04-13)
System:
  Host: ara88 Kernel: 6.6.28-1-longterm arch: x86_64 bits: 64 compiler: gcc
    v: 13.2.1 clocksource: tsc avail: hpet,acpi_pm
    parameters: BOOT_IMAGE=/boot/vmlinuz root=LABEL=zd8p07stw noresume
    ipv6.disable=1 net.ifnames=0 modprobe.blacklist=radeon
    amdgpu.cik_support=1
  Desktop: TDE (Trinity) v: R14.1.1 tk: Qt v: 3.5.0 wm: Twin v: 3.0
    with: kicker vt: 7 dm: 1: TDM 2: XDM Distro: openSUSE Tumbleweed 20240419
Graphics:
  Device-1: AMD Kaveri [Radeon R7 Graphics] vendor: ASRock driver: amdgpu
    v: kernel alternate: radeon arch: GCN-2 code: Sea Islands
    process: GF/TSMC 16-28nm built: 2013-17 ports: active: DP-1, DVI-D-1,
    HDMI-A-1, VGA-1 empty: none bus-ID: 00:01.0 chip-ID: 1002:130f
    class-ID: 0300
  Display: x11 server: X.Org v: 21.1.12 compositor: Twin v: 3.0 driver: X:
    loaded: amdgpu unloaded: fbdev,modesetting,vesa dri: radeonsi gpu: amdgpu
    display-ID: :0 screens: 1
  Screen-1: 0 s-res: 3600x2640 s-dpi: 120 s-size: 760x557mm (29.92x21.93")
    s-diag: 942mm (37.1")
  Monitor-1: DVI-D-1 mapped: DVI-D-0 pos: top-right model: Dell P2213
    serial: <filter> built: 2012 res: 1680x1050 hz: 60 dpi: 90 gamma: 1.2
    size: 473x296mm (18.62x11.65") diag: 558mm (22") ratio: 16:10 modes:
    max: 1680x1050 min: 720x400
  Monitor-2: DP-1 mapped: DisplayPort-0 pos: primary,bottom-l
    model: Acer K272HUL serial: <filter> built: 2018 res: 2560x1440 hz: 60
    dpi: 109 gamma: 1.2 size: 598x336mm (23.54x13.23") diag: 686mm (27")
    ratio: 16:9 modes: max: 2560x1440 min: 720x400
  Monitor-3: HDMI-A-1 mapped: HDMI-A-0 pos: top-left model: NEC EA243WM
    serial: <filter> built: 2011 res: 1920x1200 hz: 60 dpi: 94 gamma: 1.2
    size: 519x324mm (20.43x12.76") diag: 612mm (24.1") ratio: 16:10 modes:
    max: 1920x1200 min: 640x480
  Monitor-4: VGA-1 mapped: VGA-0 pos: middle-r model: Lenovo L2251x Wide
    serial: <filter> built: 2011 res: 1680x1050 hz: 60 dpi: 90 gamma: 1.2
    size: 474x296mm (18.66x11.65") diag: 559mm (22") ratio: 16:10 modes:
    max: 1680x1050 min: 720x400
  API: EGL v: 1.5 hw: drv: amd radeonsi platforms: device: 0 drv: radeonsi
    device: 1 drv: swrast surfaceless: drv: radeonsi x11: drv: radeonsi
    inactive: gbm,wayland
  API: OpenGL v: 4.6 compat-v: 4.5 vendor: amd mesa v: 24.0.3 glx-v: 1.4
    direct-render: yes renderer: AMD Radeon R7 Graphics (radeonsi kaveri LLVM
    18.1.3 DRM 3.54 6.6.28-1-longterm) device-ID: 1002:130f memory: 1000 MiB
    unified: no
#
All seems good this way, as does radeon.si_support=0 amdgpu.si_support=1 instead of modprobe.blacklist=radeon amdgpu.si_support=1.

modprobe.blacklist=radeon alone limits resolution to 1024x768.

amdgpu.si_support=1 alone caused:
...
[   21.933631] Call Trace:
[   21.933635]  <TASK>
[   21.933638]  ? ttm_bo_release+0x289/0x2e0 [ttm ac0e54544e650886c878aca3b786644b3b30272f]
[   21.933662]  ? __warn+0x81/0x130
[   21.933672]  ? ttm_bo_release+0x289/0x2e0 [ttm ac0e54544e650886c878aca3b786644b3b30272f]
[   21.933696]  ? report_bug+0x171/0x1a0
[   21.933705]  ? handle_bug+0x3c/0x80
[   21.933711]  ? exc_invalid_op+0x17/0x70
[   21.933716]  ? asm_exc_invalid_op+0x1a/0x20
[   21.933724]  ? ttm_bo_release+0x289/0x2e0 [ttm ac0e54544e650886c878aca3b786644b3b30272f]
[   21.933747]  ? drm_vma_offset_remove+0x18/0x70
[   21.933756]  radeon_bo_unref+0x1e/0x30 [radeon 1bb9cfc42a76bbd81c166e544d0bebf8c515b77d]
[   21.933909]  radeon_vm_fini+0x182/0x250 [radeon 1bb9cfc42a76bbd81c166e544d0bebf8c515b77d]
[   21.934054]  radeon_driver_postclose_kms+0x164/0x190 [radeon 1bb9cfc42a76bbd81c166e544d0bebf8c515b77d]
[   21.934172]  drm_file_free+0x1f7/0x250
[   21.934181]  drm_release+0xc0/0x140
[   21.934185]  __fput+0xf5/0x290
[   21.934193]  task_work_run+0x5d/0x90
[   21.934201]  do_exit+0x350/0xa80
[   21.934205]  ? futex_unqueue+0x3c/0x60
[   21.934213]  do_group_exit+0x31/0x80
[   21.934218]  get_signal+0x9f4/0xa30
[   21.934224]  arch_do_signal_or_restart+0x2e/0x260
[   21.934233]  exit_to_user_mode_prepare+0x19d/0x200
...
in dmesg and
# coredumpctl | tail
Sun 2024-04-21 00:33:10 EDT 6663   0   0 SIGABRT missing  /usr/bin/Xorg.bin    -
Sun 2024-04-21 00:33:14 EDT 6708   0   0 SIGABRT missing  /usr/bin/Xorg.bin    -
Sun 2024-04-21 00:33:18 EDT 6755   0   0 SIGABRT missing  /usr/bin/Xorg.bin    -
Sun 2024-04-21 00:33:22 EDT 6804   0   0 SIGABRT missing  /usr/bin/Xorg.bin    -
Sun 2024-04-21 00:33:26 EDT 6853   0   0 SIGABRT missing  /usr/bin/Xorg.bin    -
Sun 2024-04-21 00:33:30 EDT 6898   0   0 SIGABRT missing  /usr/bin/Xorg.bin    -
Sun 2024-04-21 00:33:34 EDT 6945   0   0 SIGABRT missing  /usr/bin/Xorg.bin    -
Sun 2024-04-21 00:33:38 EDT 6992   0   0 SIGABRT missing  /usr/bin/Xorg.bin    -
Sun 2024-04-21 00:33:42 EDT 7039   0   0 SIGABRT missing  /usr/bin/Xorg.bin    -
-- Notice: 1 systemd-coredump@.service unit is running, output may be incomplete.
#

  modprobe.blacklist=radeon + amdgpu.cik_support=1

is just the same as 

  radeon.si_support=0 amdgpu.si_support=1

It just disables load of radeon modules completely and enables load of amdgpu module.

  modprobe.blacklist=radeon

alone disables radeon KMS completely (amdgpu not being the default for your GPU)
and you end up in simpledrm running on top of framebuffer. Seems BIOS/UEFI firmware selects 1024x768 by default in your case. 

  amdgpu.si_support=1

alone enabled a second driver. I guess they don't like each other. radeon and amdgpu. Well you forced to load and initialize both.

Whatever, we cannot make loading amdgpu driver for everyone.

(In reply to t neo from comment #26)
> Adding modprobe.blacklist to the GRUB command makes my machine bootable in
> graphical target again. 
> 
> @Takashi the issues arose with the last complete rebuild image from
> Tumbleweed (VERSION="20270329"), due to XZ backdoor. It effects kernel
> 6.8.1-1-default. The last known kernel that I have to test with and works is
> 6.7.8.x

So the culprit appears to be the update of Mesa to version 24 together with kernels > 6.7.8.x.

Unfortunately I can't investigate this myself,since I no longer have radeon hardware available still supported by radeon driver (only amdgpu). :-(

(In reply to Stefan Dirsch from comment #55)
> So the culprit appears to be the update of Mesa to version 24 together with
> kernels > 6.7.8.x.

Seems that description only applies to GCN #1 & #2 cards (radeonsi_dri rather than r600_dri?), so not to ATI "Radeon" cards, rather only to AMD "Radeon" cards. Terascale 2 here is OK, unless there is something different about Slowroll's 24.0.3 (or ???):

# pinxi -GSaz --vs --zl --hostname
pinxi 3.3.34-01 (2024-04-13)
System:
  Host: gx78b.ij.net Kernel: 6.7.9-1-default arch: x86_64 bits: 64
    compiler: gcc v: 13.2.1 clocksource: tsc avail: hpet,acpi_pm
    parameters: root=/dev/sda19 noresume net.ifnames=0 ipv6.disable=1
  Desktop: IceWM v: 3.4.5 vt: 7 dm: LightDM v: 1.32.0 Distro: openSUSE
    Tumbleweed-Slowroll 20240405
Graphics:
  Device-1: AMD Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM] vendor: Dell
    driver: radeon v: kernel alternate: amdgpu arch: TeraScale-2 code: Evergreen
    process: TSMC 32-40nm built: 2009-15 pcie: gen: 2 speed: 5 GT/s lanes: 16
    ports: active: DP-1,DVI-I-1 empty: none bus-ID: 01:00.0 chip-ID: 1002:6779
    class-ID: 0300 temp: 55.0 C
  Display: x11 server: X.Org v: 21.1.12 driver: X: loaded: modesetting
    dri: r600 gpu: radeon display-ID: :0 screens: 1
  Screen-1: 0 s-res: 3600x1200 s-dpi: 120 s-size: 762x254mm (30.00x10.00")
    s-diag: 803mm (31.62")
  Monitor-1: DP-1 pos: primary,left model: NEC EA243WM serial: <filter>
    built: 2011 res: 1920x1200 hz: 60 dpi: 94 gamma: 1.2
    size: 519x324mm (20.43x12.76") diag: 612mm (24.1") ratio: 16:10 modes:
    max: 1920x1200 min: 640x480
  Monitor-2: DVI-I-1 pos: right model: Dell P2213 serial: <filter>
    built: 2012 res: 1680x1050 hz: 60 dpi: 90 gamma: 1.2
    size: 473x296mm (18.62x11.65") diag: 558mm (22") ratio: 16:10 modes:
    max: 1680x1050 min: 720x400
  API: EGL v: 1.5 hw: drv: amd r600 platforms: device: 0 drv: r600 device: 1
    drv: swrast gbm: drv: r600 surfaceless: drv: r600 x11: drv: r600
    inactive: wayland
  API: OpenGL v: 4.5 vendor: mesa v: 24.0.3 glx-v: 1.4 direct-render: yes
    renderer: AMD CAICOS (DRM 2.50.0 / 6.7.9-1-default LLVM 18.1.2)
    device-ID: 1002:6779 memory: 1000 MiB unified: no
  API: Vulkan v: 1.3.280 layers: 1 device: 0 type: cpu name: llvmpipe (LLVM
    18.1.2 128 bits) driver: N/A device-ID: 10005:0000 surfaces: xcb,xlib
# lsmod | egrep 'rade|vid|amdg' | sort
amdgpu              13303808  0
amdxcp                 12288  1 amdgpu
drm_buddy              20480  1 amdgpu
drm_display_helper    237568  2 amdgpu,radeon
drm_exec               16384  1 amdgpu
drm_suballoc_helper    12288  2 amdgpu,radeon
drm_ttm_helper         12288  2 amdgpu,radeon
gpu_sched              65536  1 amdgpu
i2c_algo_bit           20480  2 amdgpu,radeon
radeon               2068480  3
ttm                   102400  3 amdgpu,radeon,drm_ttm_helper
video                  77824  3 dell_wmi,amdgpu,radeon
wmi                    45056  5 video,dell_wmi,wmi_bmof,dell_smbios,dell_wmi_descriptor
#

Just fyi - I moved back from home:Herbster0815 to Tumbleweed 24.0.3 with all MESA / Vulkan packages.

After the move, I can confirm that 
- radeon.si_support=0
- amdgpu.si_support=1
did not help for whatever reason (still ended up in a black screen)

whereas 
- modprobe.blacklist=radeon
- amdgpu.cik_support=1
solved the issue so far. The GPU is obviously back to work - the computer runs far more smoothly, and the CPU load is reduced significantly.

(In reply to Sebastian Kuhne from comment #58)
> After the move, I can confirm that 
> - radeon.si_support=0
> - amdgpu.si_support=1
> did not help for whatever reason (still ended up in a black screen)

Those are for Southern Islands/GCN #1 GPUs. Your GPU is a Sea Islands/GCN #2, so would need instead:
 - radeon.cik_support=0
 - amdgpu.cik_support=1

Hmm. Seems with newer kernels. Both SI and CIK support has been disabled in amdgpu driver?

tw:/how/tux # uname -r
6.7.9-1-default
tw:/home/tux # modinfo radeon|grep -e si_support -e cik_support
parm:           si_support:SI support (1 = enabled (default), 0 = disabled) (int)
parm:           cik_support:CIK support (1 = enabled (default), 0 = disabled) (int)
tw:/home/tux # modinfo amdgpu|grep -e si_support -e cik_support
parm:           si_support:SI support (1 = enabled, 0 = disabled (default)) (int)
parm:           cik_support:CIK support (1 = enabled, 0 = disabled (default)) (int)

I thought radeon would support SI by default and disable CIK by default, whereas amdgpu would disable SI by default and enable CIK by default. Apparently I'm totally wrong.

(In reply to Stefan Dirsch from comment #60)
> Hmm. Seems with newer kernels. Both SI and CIK support has been disabled in
> amdgpu driver?
> 
> tw:/how/tux # uname -r
> 6.7.9-1-default
> tw:/home/tux # modinfo radeon|grep -e si_support -e cik_support
> parm:           si_support:SI support (1 = enabled (default), 0 = disabled)
> (int)
> parm:           cik_support:CIK support (1 = enabled (default), 0 =
> disabled) (int)
> tw:/home/tux # modinfo amdgpu|grep -e si_support -e cik_support
> parm:           si_support:SI support (1 = enabled, 0 = disabled (default))
> (int)
> parm:           cik_support:CIK support (1 = enabled, 0 = disabled
> (default)) (int)
> 
> I thought radeon would support SI by default and disable CIK by default,
> whereas amdgpu would disable SI by default and enable CIK by default.
> Apparently I'm totally wrong.

But isn't this one part of the puzzle, don't we need to find the cultprit in Mesa as well. Or does kernel 6.7.8 with  Mesa 24.0.3 work?

(In reply to Togan Muftuoglu from comment #61)
> (In reply to Stefan Dirsch from comment #60)
> > Hmm. Seems with newer kernels. Both SI and CIK support has been disabled in
> > amdgpu driver?
> > 
> > tw:/how/tux # uname -r
> > 6.7.9-1-default
> > tw:/home/tux # modinfo radeon|grep -e si_support -e cik_support
> > parm:           si_support:SI support (1 = enabled (default), 0 = disabled)
> > (int)
> > parm:           cik_support:CIK support (1 = enabled (default), 0 =
> > disabled) (int)
> > tw:/home/tux # modinfo amdgpu|grep -e si_support -e cik_support
> > parm:           si_support:SI support (1 = enabled, 0 = disabled (default))
> > (int)
> > parm:           cik_support:CIK support (1 = enabled, 0 = disabled
> > (default)) (int)
> > 
> > I thought radeon would support SI by default and disable CIK by default,
> > whereas amdgpu would disable SI by default and enable CIK by default.
> > Apparently I'm totally wrong.
> 
> But isn't this one part of the puzzle, don't we need to find the cultprit in
> Mesa as well. Or does kernel 6.7.8 with  Mesa 24.0.3 work?

That was claimed yes. See comment#26 and comment#55

(In reply to Togan Muftuoglu from comment #61)
> does kernel 6.7.8 with  Mesa 24.0.3 work?

6.7.9 does, as long as appropriate kernel cmdline options are applied:
# inxi -GSaz
System:
  Kernel: 6.7.9-1-default arch: x86_64 bits: 64 compiler: gcc v: 13.2.1
    clocksource: tsc avail: hpet,acpi_pm parameters: BOOT_IMAGE=/boot/vmlinuz
    root=LABEL=zd8p19sslo noresume ipv6.disable=1 net.ifnames=0
    modprobe.blacklist=radeon amdgpu.cik_support=1
  Console: pty pts/1 (vt 7) vt: 7 DM: XDM Distro: openSUSE
    Tumbleweed-Slowroll 20240405
Graphics:
  Device-1: AMD Kaveri [Radeon R7 Graphics] vendor: ASRock driver: amdgpu
    v: kernel alternate: radeon arch: GCN-2 code: Sea Islands
    process: GF/TSMC 16-28nm built: 2013-17 ports: active: DP-1, DVI-D-1,
    HDMI-A-1, VGA-1 empty: none bus-ID: 00:01.0 chip-ID: 1002:130f
    class-ID: 0300
  Display: x11 server: X.Org v: 21.1.12 driver: X: loaded: amdgpu
    unloaded: fbdev,modesetting,vesa dri: radeonsi gpu: amdgpu display-ID: :0
    screens: 1
  Screen-1: 0 s-res: 3600x2640 s-dpi: 120 s-size: 762x558mm (30.00x21.97")
    s-diag: 944mm (37.18")
  Monitor-1: DVI-D-1 mapped: DVI-D-0 pos: top-right model: Dell P2213
    serial: <filter> built: 2012 res: 1680x1050 hz: 60 dpi: 90 gamma: 1.2
    size: 473x296mm (18.62x11.65") diag: 558mm (22") ratio: 16:10 modes:
    max: 1680x1050 min: 720x400
  Monitor-2: DP-1 mapped: DisplayPort-0 pos: primary,bottom-l
    model: Acer K272HUL serial: <filter> built: 2018 res: 2560x1440 hz: 60
    dpi: 109 gamma: 1.2 size: 598x336mm (23.54x13.23") diag: 686mm (27")
    ratio: 16:9 modes: max: 2560x1440 min: 720x400
  Monitor-3: HDMI-A-1 mapped: HDMI-A-0 pos: top-left model: NEC EA243WM
    serial: <filter> built: 2011 res: 1920x1200 hz: 60 dpi: 94 gamma: 1.2
    size: 519x324mm (20.43x12.76") diag: 612mm (24.1") ratio: 16:10 modes:
    max: 1920x1200 min: 640x480
  Monitor-4: VGA-1 mapped: VGA-0 pos: middle-r model: Lenovo L2251x Wide
    serial: <filter> built: 2011 res: 1680x1050 hz: 60 dpi: 90 gamma: 1.2
    size: 474x296mm (18.66x11.65") diag: 559mm (22") ratio: 16:10 modes:
    max: 1680x1050 min: 720x400
  API: EGL v: 1.5 hw: drv: amd radeonsi platforms: device: 0 drv: radeonsi
    device: 1 drv: swrast surfaceless: drv: radeonsi x11: drv: radeonsi
    inactive: gbm,wayland
  API: OpenGL v: 4.6 compat-v: 4.5 vendor: amd mesa v: 24.0.3 glx-v: 1.4
    direct-render: yes renderer: AMD Radeon R7 Graphics (radeonsi kaveri LLVM
    18.1.2 DRM 3.57 6.7.9-1-default) device-ID: 1002:130f memory: 1000 MiB
    unified: no
  API: Vulkan v: 1.3.280 layers: 1 device: 0 type: integrated-gpu name: AMD
    Radeon R7 Graphics (RADV KAVERI) driver: N/A device-ID: 1002:130f
    surfaces: xcb,xlib
# lsmod | egrep 'vid|amdg|deon' | sort
amdgpu              13303808  2
amdxcp                 12288  1 amdgpu
drm_buddy              20480  1 amdgpu
drm_display_helper    237568  1 amdgpu
drm_exec               16384  1 amdgpu
drm_suballoc_helper    12288  1 amdgpu
drm_ttm_helper         12288  1 amdgpu
gpu_sched              65536  1 amdgpu
i2c_algo_bit           20480  1 amdgpu
ttm                   102400  2 amdgpu,drm_ttm_helper
video                  77824  1 amdgpu
wmi                    45056  1 video
#

It looks to me like the primary problem, if there is more than one problem here, is the radeon kernel module is incompatible with radeonsi_dri:
/var/log/xdm.log excerpt from 1st try using radeon.cik_support=1 modprobe.blacklist=amdgpu:
xdm info (pid 838): Starting X server on :0

X.Org X Server 1.21.1.12
X Protocol Version 11, Revision 0
Current Operating System: Linux ara88 6.7.9-1-default #1 SMP PREEMPT_DYNAMIC Thu Mar  7 06:07:11 UTC 2024 (6049de6) x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz root=LABEL=zd8p19sslo noresume ipv6.disable=1 net.ifnames=0 radeon.cik_support=1 modprobe.blacklist=amdgpu

Current version of pixman: 0.43.2
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Sun Apr 21 18:58:15 2024
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
xdm info (pid 974): sourcing /usr/etc/X11/xdm/Xsetup
(EE)
(EE) Backtrace:
(EE) 0: /usr/bin/Xorg.bin (xorg_backtrace+0x7e) [0x55a280575b6e]
(EE) 1: /usr/bin/Xorg.bin (0x55a28039f000+0x1df5d9) [0x55a28057e5d9]
(EE) 2: /lib64/libc.so.6 (0x7fe3be200000+0x41240) [0x7fe3be241240]
(EE) 3: /usr/lib64/dri/radeonsi_dri.so (0x7fe3bb600000+0x72b98d) [0x7fe3bbd2b98d]
(EE) 4: /usr/lib64/dri/radeonsi_dri.so (0x7fe3bb600000+0x72bb49) [0x7fe3bbd2bb49]
(EE) 5: /usr/lib64/dri/radeonsi_dri.so (0x7fe3bb600000+0xb90686) [0x7fe3bc190686]
(EE) 6: /usr/lib64/dri/radeonsi_dri.so (0x7fe3bb600000+0xb90819) [0x7fe3bc190819]
(EE) 7: /usr/lib64/dri/radeonsi_dri.so (0x7fe3bb600000+0x73957b) [0x7fe3bbd3957b]
(EE) 8: /usr/lib64/dri/radeonsi_dri.so (0x7fe3bb600000+0x8818bf) [0x7fe3bbe818bf]
(EE) 9: /usr/lib64/dri/radeonsi_dri.so (0x7fe3bb600000+0x840f4a) [0x7fe3bbe40f4a]
(EE) 10: /usr/lib64/dri/radeonsi_dri.so (0x7fe3bb600000+0x842391) [0x7fe3bbe42391]
(EE) 11: /usr/lib64/dri/radeonsi_dri.so (0x7fe3bb600000+0x83ee28) [0x7fe3bbe3ee28]
(EE) 12: /usr/lib64/dri/radeonsi_dri.so (0x7fe3bb600000+0xb8b4f3) [0x7fe3bc18b4f3]
(EE) 13: /usr/lib64/dri/radeonsi_dri.so (0x7fe3bb600000+0x178889) [0x7fe3bb778889]
(EE) 14: /usr/lib64/dri/radeonsi_dri.so (0x7fe3bb600000+0x140ead) [0x7fe3bb740ead]
(EE) 15: /usr/lib64/dri/radeonsi_dri.so (0x7fe3bb600000+0x149b8d) [0x7fe3bb749b8d]
(EE) 16: /usr/lib64/dri/radeonsi_dri.so (0x7fe3bb600000+0x149c78) [0x7fe3bb749c78]
(EE) 17: /usr/lib64/xorg/modules/libglamoregl.so (0x7fe3bdb8c000+0x282e2) [0x7fe3bdbb42e2]
(EE) 18: /usr/lib64/xorg/modules/libglamoregl.so (0x7fe3bdb8c000+0xf7e6) [0x7fe3bdb9b7e6]
(EE) 19: /usr/bin/Xorg.bin (0x55a28039f000+0x149904) [0x55a2804e8904]
(EE) 20: /usr/bin/Xorg.bin (0x55a28039f000+0x13af03) [0x55a2804d9f03]
(EE) 21: /usr/bin/Xorg.bin (0x55a28039f000+0x4d707) [0x55a2803ec707]
(EE) 22: /lib64/libc.so.6 (0x7fe3be200000+0x2a1f0) [0x7fe3be22a1f0]
(EE) 23: /lib64/libc.so.6 (__libc_start_main+0x8b) [0x7fe3be22a2b9]
(EE) 24: /usr/bin/Xorg.bin (_start+0x27) [0x55a2803eca35]
(EE)
(EE) Segmentation fault at address 0x40
(EE)
Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting
(EE)
(EE)
Please consult the The X.Org Foundation support
         at http://wiki.x.org
 for help.
(EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
(EE)
(II) AIGLX: Suspending AIGLX clients for VT switch
(EE) Server terminated with error (1). Closing log file.
X connection to :0 broken (explicit kill or server shutdown).
xdm error (pid 974): fatal IO error 104 (Connection reset by peer)
xdm info (pid 838): Starting X server on :0
#

2nd try using radeon.cik_support=1 modprobe.blacklist=amdgpu produced 1024x768:
# inxi -GSaz
System:
  Kernel: 6.7.9-1-default arch: x86_64 bits: 64 compiler: gcc v: 13.2.1
    clocksource: tsc avail: hpet,acpi_pm parameters: BOOT_IMAGE=/boot/vmlinuz
    root=LABEL=zd8p19sslo noresume ipv6.disable=1 net.ifnames=0
    radeon.cik_support=0 modprobe.blacklist=amdgpu
  Desktop: IceWM v: 3.4.5 vt: 7 dm: XDM Distro: openSUSE
    Tumbleweed-Slowroll 20240405
Graphics:
  Device-1: AMD Kaveri [Radeon R7 Graphics] vendor: ASRock driver: N/A
    alternate: radeon, amdgpu arch: GCN-2 code: Sea Islands
    process: GF/TSMC 16-28nm built: 2013-17 bus-ID: 00:01.0 chip-ID: 1002:130f
    class-ID: 0300
  Display: x11 server: X.Org v: 21.1.12 driver: X: loaded: modesetting,vesa
    unloaded: fbdev dri: swrast gpu: N/A display-ID: :1 screens: 1
  Screen-1: 0 s-res: 1024x768 s-dpi: 96 s-size: 270x203mm (10.63x7.99")
    s-diag: 338mm (13.3")
  Monitor-1: Unknown-1 mapped: None-1 res: 1024x768 hz: 60 size: N/A
    modes: 1024x768
  API: EGL v: 1.5 platforms: device: 0 drv: swrast gbm: drv: kms_swrast
    surfaceless: drv: swrast x11: drv: swrast inactive: wayland
  API: OpenGL v: 4.5 vendor: mesa v: 24.0.3 glx-v: 1.4 direct-render: yes
    renderer: llvmpipe (LLVM 18.1.2 256 bits) device-ID: ffffffff:ffffffff
    memory: 6.55 GiB unified: yes
# rpmqa mwar
alsa-firmware-1.2.4-4.6.noarch
kernel-firmware-amdgpu-20240322-2.1.noarch
kernel-firmware-radeon-20240322-2.1.noarch
sof-firmware-2023.12.1-1.1.noarch
# journalctl | grep radeonsi
# grep deonsi /var/log/Xorg.0.log
# lsmod | egrep 'vid|amdg|deon' | sort
drm_display_helper    237568  1 radeon
drm_suballoc_helper    12288  1 radeon
drm_ttm_helper         12288  1 radeon
i2c_algo_bit           20480  1 radeon
radeon               2068480  0
ttm                   102400  2 radeon,drm_ttm_helper
video                  77824  1 radeon
wmi                    45056  1 video
#

3rd & 4th tries using radeon.cik_support=1 modprobe.blacklist=amdgpu produced 1024x768 again.

radeon.cik_support=1 amdgpu.cik_support=0 instead of radeon.cik_support=1 modprobe.blacklist=amdgpu immediatly locks up this GCN #2 ara88 host with black screens, same as including neither *radeon* nor *amdgpu*.

At this point I installed kernel-default-6.8.7. No outright X11/XDM failures result booting with:
1-radeon.cik_support=0 amdgpu.cik_support=1, or
2-modprobe.blacklist=radeon amdgpu.cik_support=1. 

X11/XDM failures result from:
1-including neither *radeon* nor *amdgpu*
2-radeon.cik_support=1 amdgpu.cik_support=0
3-radeon.cik_support=1 modprobe.blacklist=amdgpu
4-radeon.cik_support=1
5-modprobe.blacklist=amdgpu
6-modprobe.blacklist=radeon
7-amdgpu.cik_support=1

I see no apparent impact of choice of kernel from 6.5.9 through 6.8.7. All behave the same WRT kernel cmdline requirements for successful X11/XDM behavior.

I can confirm:

(1) Does not work:
- radeon.si_support=0
- amdgpu.si_support=1

(2) Works:
- modprobe.blacklist=radeon
- amdgpu.cik_support=1

(3) Works:
- radeon.cik_support=0
- amdgpu.cik_support=1

Attached the two inxi_GSaz outputs for (2) and for (3), and the diff.

Created attachment 874402 [details]
inxi_GSaz output for (2)

Created attachment 874403 [details]
inxi_GSaz output for (3)

Created attachment 874404 [details]
Diff (2) (3)

(In reply to Stefan Dirsch from comment #62)
> (In reply to Togan Muftuoglu from comment #61)
> > (In reply to Stefan Dirsch from comment #60)
> > > Hmm. Seems with newer kernels. Both SI and CIK support has been disabled in
> > > amdgpu driver?
> > > 
> > > tw:/how/tux # uname -r
> > > 6.7.9-1-default
> > > tw:/home/tux # modinfo radeon|grep -e si_support -e cik_support
> > > parm:           si_support:SI support (1 = enabled (default), 0 = disabled)
> > > (int)
> > > parm:           cik_support:CIK support (1 = enabled (default), 0 =
> > > disabled) (int)
> > > tw:/home/tux # modinfo amdgpu|grep -e si_support -e cik_support
> > > parm:           si_support:SI support (1 = enabled, 0 = disabled (default))
> > > (int)
> > > parm:           cik_support:CIK support (1 = enabled, 0 = disabled
> > > (default)) (int)
> > > 
> > > I thought radeon would support SI by default and disable CIK by default,
> > > whereas amdgpu would disable SI by default and enable CIK by default.
> > > Apparently I'm totally wrong.
> > 
> > But isn't this one part of the puzzle, don't we need to find the cultprit in
> > Mesa as well. Or does kernel 6.7.8 with  Mesa 24.0.3 work?
> 
> That was claimed yes. See comment#26 and comment#55

Well in my case it doesn't even work in 6.7.7 kernel with Mesa 24.0.3 I still need to add the radeon.si_support=0 amdgpu.si_support=1 even to 6.7.7 kernel version

[Mon Apr 22 09:04:23 2024] QSGRenderThread[1969]: segfault at 40 ip 00007f1b6932ba1d sp 00007f1b2a9fd9d0 error 4 in radeonsi_dri.so[7f1b68c91000+1477000] likely on CPU 5 (core 1, socket 0)
[Mon Apr 22 09:04:23 2024] Code: 8b 6f 30 85 ed 0f 84 e5 00 00 00 31 db 49 89 e5 eb 34 0f 1f 00 4d 03 77 38 49 8b 36 48 85 f6 74 0e f0 83 2e 01 75 08 4c 89 e7 <41> ff 54 24 40 49 c7 06 00 00 00 00 41 8b 57 30 48 83 c3 01 39 d3

System:
Kernel: 6.7.7-1-default arch: x86_64 bits: 64 compiler: gcc v: 13.2.1 clocksource: tsc
avail: hpet,acpi_pm parameters: BOOT_IMAGE=/boot/vmlinuz-6.7.7-1-default
root=UUID=f5f5c2e6-78db-42c1-af58-d73dc71f58ef splash=silent
resume=/dev/disk/by-uuid/9400120e-afe4-47a1-b9e7-583e36c49aef quiet security=apparmor
mitigations=auto
Console: tty 3 DM: SDDM Distro: openSUSE Tumbleweed 20240418
Graphics:
Device-1: AMD Tahiti PRO [Radeon HD 7950/8950 OEM / R9 280] vendor: ASUSTeK driver: radeon
v: kernel alternate: amdgpu arch: GCN-1 code: Southern Islands process: TSMC 28nm built: 2011-20
pcie: gen: 3 speed: 8 GT/s lanes: 8 link-max: lanes: 16 ports: active: DP-1,HDMI-A-1
empty: DVI-D-1,DVI-I-1 bus-ID: 01:00.0 chip-ID: 1002:679a class-ID: 0300 temp: 48.0 C
Display: server: X.org v: 1.21.1.12 with: Xwayland v: 23.2.6 driver: X: loaded: radeon
unloaded: fbdev,modesetting,vesa dri: radeonsi gpu: radeon tty: 240x67
Monitor-1: DP-1 model: EIZO NANAO CX241 serial: <filter> built: 2014 res: 1920x1200 dpi: 94
gamma: 1.2 size: 519x324mm (20.43x12.76") diag: 616mm (24.2") ratio: 16:10 modes: max: 1920x1200
min: 720x400
Monitor-2: HDMI-A-1 model: Idek Iiyama PL2292H serial: <filter> built: 2019 res: 1920x1080
dpi: 102 gamma: 1.2 size: 476x268mm (18.74x10.55") diag: 546mm (21.5") ratio: 16:9 modes:
max: 1920x1080 min: 720x400
API: EGL v: 1.5 hw: drv: amd radeonsi platforms: device: 0 drv: radeonsi device: 1 drv: swrast
gbm: drv: radeonsi surfaceless: drv: radeonsi inactive: wayland,x11
API: OpenGL v: 4.5 vendor: mesa v: 24.0.3 note: console (EGL sourced) renderer: TAHITI
(radeonsi LLVM 18.1.3 DRM 2.50 6.7.7-1-default), llvmpipe (LLVM 18.1.3 256 bits)
API: Vulkan Message: No Vulkan data available.

I was able to revert on my GCN #1 Slowroll installation to the following:
Mesa-23.3.6-367.1.x86_64.rpm
Mesa-dri-23.3.6-367.1.x86_64.rpm
Mesa-gallium-23.3.6-367.1.x86_64.rpm
Mesa-libEGL1-23.3.6-367.1.x86_64.rpm
Mesa-libGL1-23.3.6-367.1.x86_64.rpm
Mesa-libOpenCL-23.3.6-367.1.x86_64.rpm
Mesa-libd3d-23.3.6-367.1.x86_64.rpm
Mesa-libglapi0-23.3.6-367.1.x86_64.rpm
Mesa-libva-23.3.6-367.1.x86_64.rpm
Mesa-vulkan-device-select-23.3.6-367.1.x86_64.rpm
Mesa-vulkan-overlay-23.3.6-367.1.x86_64.rpm
libLLVM17-17.0.6-1.16.x86_64.rpm
libLLVMSPIRVLib17-17.0.0-3.2.x86_64.rpm
libSPIRV-Tools-2023_6_rc1-2023.6~rc1-4.2.x86_64.rpm
libclang-cpp17-17.0.6-1.16.x86_64.rpm
libclc-0.2.0+llvm17.0.1-2.2.noarch.rpm

The result is it is not now required to use any radeon or amdgpu graphics options on kernel cmdline for X11/XDM to function normally:
# inxi -GSaz --vs
inxi 3.3.34-00 (2024-04-13)
System:
  Kernel: 6.8.7-1-default arch: x86_64 bits: 64 compiler: gcc v: 13.2.1
    clocksource: tsc avail: hpet,acpi_pm parameters: root=LABEL=w71p19sslo
    ipv6.disable=1 net.ifnames=0 noresume
  Desktop: KDE Plasma v: 5.27.10 tk: Qt v: 5.15.12 info: frameworks
    v: 5.115.0 wm: kwin_x11 vt: 7 dm: XDM Distro: openSUSE Tumbleweed-Slowroll
    20240405
Graphics:
  Device-1: AMD Oland [Radeon HD 8570 / R5 430 OEM R7 240/340 Radeon 520 OEM]
    vendor: Dell driver: radeon v: kernel alternate: amdgpu arch: GCN-1
    code: Southern Islands process: TSMC 28nm built: 2011-20 pcie: gen: 1
    speed: 2.5 GT/s lanes: 8 link-max: gen: 3 speed: 8 GT/s ports:
    active: DP-1,DVI-I-1 empty: none bus-ID: 01:00.0 chip-ID: 1002:6611
    class-ID: 0300 temp: 51.0 C
  Display: x11 server: X.Org v: 21.1.12 compositor: kwin_x11 driver: X:
    loaded: radeon unloaded: modesetting alternate: fbdev,vesa dri: swrast
    gpu: radeon display-ID: :0 screens: 1
  Screen-1: 0 s-res: 4240x1440 s-dpi: 120 s-size: 897x304mm (35.31x11.97")
    s-diag: 947mm (37.29")
  Monitor-1: DVI-I-1 mapped: DVI-0 pos: right model: Dell P2213
    serial: <filter> built: 2012 res: 1680x1050 hz: 60 dpi: 90 gamma: 1.2
    size: 473x296mm (18.62x11.65") diag: 558mm (22") ratio: 16:10 modes:
    max: 1680x1050 min: 720x400
  Monitor-2: DP-1 mapped: DisplayPort-0 pos: primary,left
    model: Acer K272HUL serial: <filter> built: 2018 res: 2560x1440 hz: 60
    dpi: 109 gamma: 1.2 size: 598x336mm (23.54x13.23") diag: 686mm (27")
    ratio: 16:9 modes: max: 2560x1440 min: 720x400
  API: EGL v: 1.5 hw: drv: amd radeonsi platforms: device: 0 drv: radeonsi
    device: 1 drv: swrast surfaceless: drv: radeonsi x11: drv: swrast
    inactive: gbm,wayland
  API: OpenGL v: 4.5 vendor: mesa v: 23.3.6 glx-v: 1.4 direct-render: yes
    renderer: llvmpipe (LLVM 17.0.6 128 bits) device-ID: ffffffff:ffffffff
    memory: 7.58 GiB unified: yes
  API: Vulkan v: 1.3.280 layers: 1 device: 0 type: cpu name: llvmpipe (LLVM
    18.1.2 128 bits) driver: N/A device-ID: 10005:0000 surfaces: xcb,xlib
#

(In reply to Stefan Dirsch from comment #55)
> (In reply to t neo from comment #26)
> > Adding modprobe.blacklist to the GRUB command makes my machine bootable in
> > graphical target again. 
> > 
> > @Takashi the issues arose with the last complete rebuild image from
> > Tumbleweed (VERSION="20270329"), due to XZ backdoor. It effects kernel
> > 6.8.1-1-default. The last known kernel that I have to test with and works is
> > 6.7.8.x
> 
> So the culprit appears to be the update of Mesa to version 24 together with
> kernels > 6.7.8.x.

Seems this information was wrong or at least misleading. Maybe things were tested with kernel 6.7.8.x together with old Mesa 23.x.

Just a heads-up: For my two radeonsi machines, this problem has been fixed in the most recent updates.

Many thanks for the hint.

I have removed the kernel parameters radeon.cik_support=0 amdgpu.cik_support=1. I can confirm that this setup is working for me, too. It works on both, X11 and Wayland.

I have compared the two inxi -GSaz outputs (with radeon.cik_support=0 amdgpu.cik_support=1 and without):


6c6
<     loglevel=3 radeon.cik_support=0 amdgpu.cik_support=1
---
>     loglevel=3
9c9
<     Tumbleweed 20240419
---
>     Tumbleweed 20240429
11,12c11,12
<   Device-1: AMD Kaveri [Radeon R7 Graphics] vendor: ASRock driver: amdgpu
<     v: kernel alternate: radeon arch: GCN-2 code: Sea Islands
---
>   Device-1: AMD Kaveri [Radeon R7 Graphics] vendor: ASRock driver: radeon
>     v: kernel alternate: amdgpu arch: GCN-2 code: Sea Islands

So, now the kernel loads the radeon module by default.

I have two questions where I would appreciate your feedback.
- Since I had never investigated in that before, is this the desired behavior, such as for new installations?
- Shouldn't I/we/all rather stay with amdgpu (by considering the information on 'https://wiki.archlinux.org/title/AMDGPU'?

I can confirm also under X11 I don't need to force amdgpu. Didn't try wayland as I am not using it 

System:
Kernel: 6.8.7-1-default arch: x86_64 bits: 64 compiler: gcc v: 13.2.1
clocksource: tsc avail: hpet,acpi_pm
parameters: BOOT_IMAGE=/boot/vmlinuz-6.8.7-1-default
root=UUID=f5f5c2e6-78db-42c1-af58-d73dc71f58ef splash=silent
resume=/dev/disk/by-uuid/9400120e-afe4-47a1-b9e7-583e36c49aef quiet
security=apparmor mitigations=auto
Desktop: KDE Plasma v: 6.0.4 tk: Qt v: N/A info: frameworks v: 6.1.0
wm: kwin_x11 with: krunner tools: avail: xscreensaver vt: 2 dm: SDDM
Distro: openSUSE Tumbleweed 20240429
Graphics:
Device-1: AMD Tahiti PRO [Radeon HD 7950/8950 OEM / R9 280] vendor: ASUSTeK
driver: radeon v: kernel alternate: amdgpu arch: GCN-1
code: Southern Islands process: TSMC 28nm built: 2011-20 pcie: gen: 3
speed: 8 GT/s lanes: 8 link-max: lanes: 16 ports: active: DP-1,HDMI-A-1
empty: DVI-D-1,DVI-I-1 bus-ID: 01:00.0 chip-ID: 1002:679a class-ID: 0300
temp: 53.0 C
Display: x11 server: X.Org v: 21.1.12 with: Xwayland v: 23.2.6
compositor: kwin_x11 driver: X: loaded: radeon
unloaded: fbdev,modesetting,vesa dri: radeonsi gpu: radeon display-ID: :0
screens: 1
Screen-1: 0 s-res: 3840x1200 s-dpi: 96 s-size: 1016x317mm (40.00x12.48")
s-diag: 1064mm (41.9")
Monitor-1: DP-1 mapped: DisplayPort-0 pos: primary,left
model: EIZO NANAO CX241 serial: <filter> built: 2014 res: 1920x1200 hz: 60
dpi: 94 gamma: 1.2 size: 519x324mm (20.43x12.76") diag: 616mm (24.2")
ratio: 16:10 modes: max: 1920x1200 min: 720x400
Monitor-2: HDMI-A-1 mapped: HDMI-0 pos: right model: Idek Iiyama PL2292H
serial: <filter> built: 2019 res: 1920x1080 hz: 60 dpi: 102 gamma: 1.2
size: 476x268mm (18.74x10.55") diag: 546mm (21.5") ratio: 16:9 modes:
max: 1920x1080 min: 720x400
API: EGL v: 1.5 hw: drv: amd radeonsi platforms: device: 0 drv: radeonsi
device: 1 drv: swrast gbm: drv: kms_swrast surfaceless: drv: radeonsi x11:
drv: radeonsi inactive: wayland
API: OpenGL v: 4.5 vendor: amd mesa v: 24.0.5 glx-v: 1.4
direct-render: yes renderer: TAHITI (radeonsi LLVM 18.1.4 DRM 2.50
6.8.7-1-default) device-ID: 1002:679a memory: 2.93 GiB unified: no
API: Vulkan Message: No Vulkan data available.

I've updated Mesa from 24.0.3 to 24.0.5 in TW. I guess this has fixed the issue, when it's no longer needed to force usage of amdgpu kernel driver.

(In reply to Sebastian Kuhne from comment #72)
> So, now the kernel loads the radeon module by default.
> I have two questions where I would appreciate your feedback.
> - Since I had never investigated in that before, is this the desired
> behavior, such as for new installations?

Yes, that's correct behaviour for Southern/Sea Islands GPUs. Previously I claimed it to be different, but I was proven wrong. Sorry for the confusion!

> - Shouldn't I/we/all rather stay with amdgpu (by considering the information
> on 'https://wiki.archlinux.org/title/AMDGPU'?

I don't think we should change upstream behaviour here.

Ok. So we see confirmations for Southern and Sea Islands this regression has been fixed with latest Mesa 24.0.5. So closing as fixed.

*** Bug 1222410 has been marked as a duplicate of this bug. ***

Unfortunately, I have to reopen this issue. After the recent upgrade on TW, login after SDDM via Wayland failed completely, whereas login via X11 was working but showed artifacts. Even the SDDM showed some artifacts - the placeholder for the user images were noisy. 

My system hasn't changed - I still use the same Radeon R7 that is a Sea Islands/GCN #2 (cik), and not a Southern Islands/GCN #1 (si). The standard driver is radeon (and not amdgpu).

Based on the discussion we had within this thread, I forced the use of amdgpu via the boot options 'radeon.cik_support=0 amdgpu.cik_support=1'.

As a result, the system is running properly under both graphic approaches, Wayland and X11. No artifacts are visible under X11 and in the SDDM.

So, obviously there is again an issue with the radeon driver.

I question again whether we should move by default to the amdgpu driver even for Sea Islands. And, it is probably worth to investigate how to fix this in a more stable way.

Many thanks!

We had another regression with Mesa, which was addressed with this change in packages.


-------------------------------------------------------------------
Wed Jun 19 17:31:26 UTC 2024 - Mikhail Paulyshka <me@mixaill.net>

- Disable LTO on %ix86/x86_64 due to rendering bugs on Radeon
  graphics (boo#1226462)

Please check, if you already have this change in your RPM changelog.

(In reply to Stefan Dirsch from comment #79)
> We had another regression with Mesa, which was addressed with this change in
> packages.
> 
> 
> -------------------------------------------------------------------
> Wed Jun 19 17:31:26 UTC 2024 - Mikhail Paulyshka <me@mixaill.net>
> 
> - Disable LTO on %ix86/x86_64 due to rendering bugs on Radeon
>   graphics (boo#1226462)
> 
> Please check, if you already have this change in your RPM changelog.


Thank you very much, Stefan. Sorry, I had looked for an existing report but couldn't find anything. But now it's clear. Changing this thread back to "Resolved".

Refer to https://bugzilla.opensuse.org/show_bug.cgi?id=1226462

Need to open again. Same issue.

Installed is Mesa 24.1.2-382.1 and dependencies from openSUSE packages (and not from Packman).

My current system:
Operating System: openSUSE Tumbleweed 20240624
KDE Plasma Version: 6.1.0
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.2
Kernel Version: 6.9.5-1-default (64-bit)
Graphics Platform: Wayland
Processors: 4 × AMD A8-7650K Radeon R7, 10 Compute Cores 4C+6G
Memory: 14.6 GiB of RAM
Graphics Processor: AMD Radeon R7 Graphics

Without the boot options 'radeon.cik_support=0 amdgpu.cik_support=1', Wayland fails completely after login at SDDM. X11 does work.

With the boot options 'radeon.cik_support=0 amdgpu.cik_support=1', Wayland does work as expected after login at SDDM.

Basically, I am ok with keeping 'radeon.cik_support=0 amdgpu.cik_support=1' activated; however, this might not be a satisfying approach for other users.

I am a bit unhappy about this back and forth situation - every update of Mesa is a gamble whether the system will continue to work or not.

Any recommendation is appreciated!

So you mean you had it working with Mesa 24.1.1 and LTO disabled and now with Mesa 24.1.2 (LTO still disabled) it got broken again?

(In reply to Stefan Dirsch from comment #83)
> So you mean you had it working with Mesa 24.1.1 and LTO disabled and now
> with Mesa 24.1.2 (LTO still disabled) it got broken again?

Yes, exactly, this is what happened.

Ok. There were a few changes, which might be related to this regression.

https://docs.mesa3d.org/relnotes/24.1.2

radeonsi: Fix si_compute_clear_render_target with 422 subsampled formats
radeonsi: set COMPUTE_STATIC_THREAD_MGMT_SE2-3 correctly on gfx10-11
Revert “radeonsi: fix initialization of occlusion query buffers for disabled RBs”
radeonsi: fix assert triggered on gfx6 after the tessellation update
radeonsi: add missing nir_intrinsic_bindless_image_descriptor_amd

No breakage here using Kaveri Sea Islands GCN#2 and 6.8.9 kernel. Could problem be 6.9.x kernel rather than Mesa?
# xdriinfo
Screen 0: radeonsi
# inxi -CM --vs --zl --hostname
inxi 3.3.35-00 (2024-06-18)
Machine:
  Type: Desktop Mobo: ASRock model: FM2A88X Extreme6+ serial: E80-38024200616
    UEFI: American Megatrends v: P4.20 date: 01/13/2016
CPU:
  Info: quad core model: AMD A10-7850K Radeon R7 12 Compute Cores 4C+8G
    bits: 64 type: MT MCP cache: L2: 4 MiB
  Speed (MHz): avg: 1875 min/max: 1700/4000 cores: 1: 1700 2: 2400 3: 1700
    4: 1700
# inxi -GSaz
System:
  Kernel: 6.8.9-1-default arch: x86_64 bits: 64 compiler: gcc v: 13.2.1
    clocksource: tsc avail: hpet,acpi_pm parameters: BOOT_IMAGE=/boot/vmlinuz
    root=LABEL=zd8p07stw noresume ipv6.disable=1 net.ifnames=0 consoleblank=0
    preempt=full mitigations=off
  Desktop: TDE (Trinity) v: R14.1.2 tk: Qt v: 3.5.0 wm: Twin v: 3.0
    with: kicker vt: 7 dm: 1: TDM 2: XDM Distro: openSUSE Tumbleweed 20240624
Graphics:
  Device-1: AMD Kaveri [Radeon R7 Graphics] vendor: ASRock driver: radeon
    v: kernel alternate: amdgpu arch: GCN-2 code: Sea Islands
    process: GF/TSMC 16-28nm built: 2013-17 ports: active: DP-1, DVI-D-1,
    HDMI-A-1, VGA-1 empty: none bus-ID: 00:01.0 chip-ID: 1002:130f
    class-ID: 0300
  Display: x11 server: X.Org v: 21.1.12 compositor: Twin v: 3.0 driver: X:
    loaded: modesetting dri: radeonsi gpu: radeon display-ID: :0 screens: 1
  Screen-1: 0 s-res: 4240x2340 s-dpi: 120 s-size: 895x494mm (35.24x19.45")
    s-diag: 1022mm (40.25")
  Monitor-1: DP-1 pos: primary,middle-c model: Acer K272HUL serial: <filter>
    built: 2018 res: 2560x1440 hz: 60 dpi: 109 gamma: 1.2
    size: 598x336mm (23.54x13.23") diag: 686mm (27") ratio: 16:9 modes:
    max: 2560x1440 min: 720x400
  Monitor-2: DVI-D-1 pos: bottom-l model: Dell P2213 serial: <filter>
    built: 2012 res: 1680x1050 hz: 60 dpi: 90 gamma: 1.2
    size: 473x296mm (18.62x11.65") diag: 558mm (22") ratio: 16:10 modes:
    max: 1680x1050 min: 720x400
  Monitor-3: HDMI-A-1 mapped: HDMI-1 pos: top-left model: NEC EA243WM
    serial: <filter> built: 2011 res: 1920x1200 hz: 60 dpi: 94 gamma: 1.2
    size: 519x324mm (20.43x12.76") diag: 612mm (24.1") ratio: 16:10 modes:
    max: 1920x1200 min: 640x480
  Monitor-4: VGA-1 pos: top-right model: FLM-1911 serial: <filter>
    built: 2006 res: 1440x900 hz: 75 dpi: 89 gamma: 1.4
    size: 410x260mm (16.14x10.24") diag: 485mm (19.1") ratio: 16:10 modes:
    max: 1280x1024 min: 720x400
  API: EGL v: 1.5 hw: drv: amd radeonsi platforms: device: 0 drv: radeonsi
    device: 1 drv: swrast gbm: drv: radeonsi surfaceless: drv: radeonsi x11:
    drv: radeonsi inactive: wayland
  API: OpenGL v: 4.5 vendor: amd mesa v: 24.1.2 glx-v: 1.4
    direct-render: yes renderer: KAVERI (radeonsi LLVM 18.1.6 DRM 2.50
    6.8.9-1-default) device-ID: 1002:130f memory: 1000 MiB unified: no
  API: Vulkan v: 1.3.283 layers: 2 device: 0 type: cpu name: llvmpipe (LLVM
    18.1.6 256 bits) driver: N/A device-ID: 10005:0000 surfaces: xcb,xlib
#

I am using the same command. Hope that is helpful.

#nxi -CM --vs --zl --hostname
Machine:
  Type: Desktop Mobo: ASRock model: FM2A78M Pro4+ serial: M80-3C012001343
    UEFI-[Legacy]: American Megatrends v: P2.40 date: 02/05/2016
CPU:
  Info: quad core model: AMD A8-7650K Radeon R7 10 Compute Cores 4C+6G
    bits: 64 type: MCP cache: L2: 4 MiB
  Speed (MHz): avg: 2025 min/max: 1900/3800 cores: 1: 1900 2: 1900 3: 2400
    4: 1900

# inxi -GSaz
System:
  Kernel: 6.9.5-1-default arch: x86_64 bits: 64 compiler: gcc v: 13.3.0
    clocksource: tsc avail: hpet,acpi_pm
    parameters: BOOT_IMAGE=/boot/vmlinuz-6.9.5-1-default
    root=UUID=46dfafac-fbe2-48eb-b037-156c4bb3d053 resume=/dev/sda1 showopts
    loglevel=3 radeon.cik_support=0 amdgpu.cik_support=1
  Desktop: KDE Plasma v: 6.1.0 tk: Qt v: N/A info: frameworks v: 6.3.0
    wm: kwin_wayland tools: avail: xlock,xscreensaver vt: 3 dm: SDDM
    Distro: openSUSE Tumbleweed 20240624
Graphics:
  Device-1: AMD Kaveri [Radeon R7 Graphics] vendor: ASRock driver: amdgpu
    v: kernel alternate: radeon arch: GCN-2 code: Sea Islands
    process: GF/TSMC 16-28nm built: 2013-17 ports: active: HDMI-A-1
    empty: DVI-D-1,VGA-1 bus-ID: 00:01.0 chip-ID: 1002:1313 class-ID: 0300
  Device-2: Sunplus Innovation hama C-600 Pro Webcam
    driver: snd-usb-audio,uvcvideo type: USB rev: 2.0 speed: 480 Mb/s lanes: 1
    mode: 2.0 bus-ID: 3-4:4 chip-ID: 1bcf:28c4 class-ID: 0102 serial: <filter>
  Display: wayland server: X.org v: 1.21.1.12 with: Xwayland v: 24.1.0
    compositor: kwin_wayland driver: X: loaded: amdgpu
    unloaded: fbdev,modesetting,vesa dri: radeonsi gpu: amdgpu display-ID: 0
  Monitor-1: HDMI-A-1 res: 1920x1080 size: N/A modes: N/A
  API: EGL v: 1.5 hw: drv: amd radeonsi platforms: device: 0 drv: radeonsi
    device: 1 drv: swrast surfaceless: drv: radeonsi wayland: drv: radeonsi x11:
    drv: radeonsi inactive: gbm
  API: OpenGL v: 4.6 compat-v: 4.5 vendor: amd mesa v: 24.1.2 glx-v: 1.4
    direct-render: yes renderer: AMD Radeon R7 Graphics (radeonsi kaveri LLVM
    18.1.6 DRM 3.57 6.9.5-1-default) device-ID: 1002:1313 memory: 1000 MiB
    unified: no display-ID: :1.0
  API: Vulkan v: 1.3.283 layers: 2 device: 0 type: integrated-gpu name: AMD
    Radeon R7 Graphics (RADV KAVERI) driver: N/A device-ID: 1002:1313
    surfaces: xcb,xlib,wayland device: 1 type: cpu name: llvmpipe (LLVM
    18.1.6 256 bits) driver: N/A device-ID: 10005:0000
    surfaces: xcb,xlib,wayland

Please note: This is all with boot options 'radeon.cik_support=0 amdgpu.cik_support=1'.

(In reply to Felix Miata from comment #86)
> No breakage here using Kaveri Sea Islands GCN#2 and 6.8.9 kernel. Could
> problem be 6.9.x kernel rather than Mesa?

Yes, this should be checked. Here you still find older kernel releases 6.8.9.

https://download.opensuse.org/history/20240523/tumbleweed/repo/oss/x86_64/

Of course without boot options 'radeon.cik_support=0 amdgpu.cik_support=1'.

Oland Southern Islands GCN#1 is OK with 6.9.5:
# inxi -CM --vs --zl --hostname
inxi 3.3.35-00 (2024-06-18)
Machine:
  Type: Desktop Mobo: ASUSTeK model: P5B-Deluxe v: Rev 1.xx
    serial: MB-1234567890 BIOS: American Megatrends v: 1238 date: 09/30/2008
CPU:
  Info: dual core model: Intel Core2 6700 bits: 64 type: MCP cache: L2: 4 MiB
  Speed (MHz): avg: 1596 min/max: 1596/2660 cores: 1: 1596 2: 1596
# inxi -GSaz
System:
  Kernel: 6.9.5-1-default arch: x86_64 bits: 64 compiler: gcc v: 13.3.0
    clocksource: tsc avail: hpet,acpi_pm parameters: root=LABEL=sTWp21w71
    ipv6.disable=1 net.ifnames=0 noresume consoleblank=0 mitigations=off
  Desktop: KDE Plasma v: 5.27.10 tk: Qt v: 5.15.12 info: frameworks
    v: 5.115.0 wm: kwin_x11 vt: 7 dm: 1: KDM 2: XDM Distro: openSUSE Tumbleweed
    20240624
Graphics:
  Device-1: AMD Oland [Radeon HD 8570 / R5 430 OEM R7 240/340 Radeon 520 OEM]
    vendor: Dell driver: radeon v: kernel alternate: amdgpu arch: GCN-1
    code: Southern Islands process: TSMC 28nm built: 2011-20 pcie: gen: 1
    speed: 2.5 GT/s lanes: 8 link-max: gen: 3 speed: 8 GT/s ports:
    active: DP-1,DVI-I-1 empty: none bus-ID: 01:00.0 chip-ID: 1002:6611
    class-ID: 0300 temp: 53.0 C
  Display: x11 server: X.Org v: 21.1.12 compositor: kwin_x11 driver: X:
    loaded: modesetting unloaded: fbdev,vesa dri: radeonsi gpu: radeon
    display-ID: :0 screens: 1
  Screen-1: 0 s-res: 4240x1440 s-dpi: 120 s-size: 897x304mm (35.31x11.97")
    s-diag: 947mm (37.29")
  Monitor-1: DP-1 pos: primary,left model: Acer K272HUL serial: <filter>
    built: 2018 res: 2560x1440 hz: 60 dpi: 109 gamma: 1.2
    size: 598x336mm (23.54x13.23") diag: 686mm (27") ratio: 16:9 modes:
    max: 2560x1440 min: 720x400
  Monitor-2: DVI-I-1 pos: right model: Dell P2213 serial: <filter>
    built: 2012 res: 1680x1050 hz: 60 dpi: 90 gamma: 1.2
    size: 473x296mm (18.62x11.65") diag: 558mm (22") ratio: 16:10 modes:
    max: 1680x1050 min: 720x400
  API: EGL v: 1.5 hw: drv: amd radeonsi platforms: device: 0 drv: radeonsi
    device: 1 drv: swrast gbm: drv: radeonsi surfaceless: drv: radeonsi x11:
    drv: radeonsi inactive: wayland
  API: OpenGL v: 4.5 vendor: amd mesa v: 24.1.2 glx-v: 1.4
    direct-render: yes renderer: OLAND (radeonsi LLVM 18.1.6 DRM 2.50
    6.9.5-1-default) device-ID: 1002:6611 memory: 1000 MiB unified: no
  API: Vulkan v: 1.3.283 layers: 1 device: 0 type: cpu name: llvmpipe (LLVM
    18.1.6 128 bits) driver: N/A device-ID: 10005:0000 surfaces: xcb,xlib
# lsmod | egrep 'vid|amdg|deon' | sort
amdgpu              13832192  0
amdxcp                 12288  1 amdgpu
drm_buddy              20480  1 amdgpu
drm_display_helper    262144  2 amdgpu,radeon
drm_exec               12288  1 amdgpu
drm_suballoc_helper    12288  2 amdgpu,radeon
drm_ttm_helper         12288  2 amdgpu,radeon
gpu_sched              69632  1 amdgpu
i2c_algo_bit           20480  2 amdgpu,radeon
radeon               2088960  18
ttm                   102400  3 amdgpu,radeon,drm_ttm_helper
video                  77824  2 amdgpu,radeon
wmi                    32768  1 video
#

(In reply to Stefan Dirsch from comment #90)
> (In reply to Felix Miata from comment #86)
> > No breakage here using Kaveri Sea Islands GCN#2 and 6.8.9 kernel. Could
> > problem be 6.9.x kernel rather than Mesa?
> 
> Yes, this should be checked. Here you still find older kernel releases 6.8.9.
> 
> https://download.opensuse.org/history/20240523/tumbleweed/repo/oss/x86_64/
> 
> Of course without boot options 'radeon.cik_support=0 amdgpu.cik_support=1'.


I have used the link, and downgraded; however ended up with kernel 6.9.1 (and not with 6.8.9). This is not useful since we assumed 6.9.x having an issue; so I need help how to come to 6.8.9. Maybe I did something wrong with adding the repo 
(there was an error, and I included this URL instead:
URL: https://download.opensuse.org/history/20240523/tumbleweed/repo/oss/
)


However, here are the findings with 6.9.1:

Issue remains with Wayland. X11 is working

inxi 3.3.35-00 (2024-06-18)
Machine:
  Type: Desktop Mobo: ASRock model: FM2A78M Pro4+ serial: M80-3C012001343
    UEFI-[Legacy]: American Megatrends v: P2.40 date: 02/05/2016
CPU:
  Info: dual core model: AMD A8-7650K Radeon R7 10 Compute Cores 4C+6G bits: 64 type: MT MCP
    cache: L2: 4 MiB
  Speed (MHz): avg: 1900 min/max: 1900/3800 cores: 1: 1900 2: 1900 3: 1900 4: 1900

inxi -GSaz
System:
  Kernel: 6.9.1-1-default arch: x86_64 bits: 64 compiler: gcc v: 13.2.1 clocksource: tsc
    avail: hpet,acpi_pm parameters: BOOT_IMAGE=/boot/vmlinuz-6.9.1-1-default
    root=UUID=46dfafac-fbe2-48eb-b037-156c4bb3d053 resume=/dev/sda1 showopts loglevel=3
  Console: pty pts/2 DM: SDDM Distro: openSUSE Tumbleweed 20240624
Graphics:
  Device-1: AMD Kaveri [Radeon R7 Graphics] vendor: ASRock driver: radeon v: kernel
    alternate: amdgpu arch: GCN-2 code: Sea Islands process: GF/TSMC 16-28nm built: 2013-17 ports:
    active: HDMI-A-1 empty: DVI-D-1,VGA-1 bus-ID: 00:01.0 chip-ID: 1002:1313 class-ID: 0300
  Device-2: Sunplus Innovation hama C-600 Pro Webcam driver: snd-usb-audio,uvcvideo type: USB
    rev: 2.0 speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 1-4:4 chip-ID: 1bcf:28c4 class-ID: 0102
    serial: <filter>
  Display: server: X.org v: 1.21.1.12 with: Xwayland v: 24.1.0 compositor: kwin_x11 driver: X:
    loaded: radeon unloaded: fbdev,modesetting,vesa dri: radeonsi gpu: radeon tty: 270x68
  Monitor-1: HDMI-A-1 model: Asus VS247 serial: <filter> built: 2015 res: 1920x1080 dpi: 94
    gamma: 1.2 size: 521x293mm (20.51x11.54") diag: 598mm (23.5") ratio: 16:9 modes: max: 1920x1080
    min: 720x400
  API: EGL v: 1.5 hw: drv: amd radeonsi platforms: device: 0 drv: radeonsi device: 1 drv: swrast
    gbm: drv: radeonsi surfaceless: drv: radeonsi inactive: wayland,x11
  API: OpenGL v: 4.5 vendor: mesa v: 24.1.2 note: console (EGL sourced) renderer: KAVERI
    (radeonsi LLVM 18.1.6 DRM 2.50 6.9.1-1-default), llvmpipe (LLVM 18.1.6 256 bits)
  API: Vulkan v: 1.3.283 layers: 2 device: 0 type: cpu name: llvmpipe (LLVM 18.1.6 256 bits)
    driver: N/A device-ID: 10005:0000 surfaces: N/A

(In reply to Sebastian Kuhne from comment #92)
> (there was an error, and I included this URL instead:
> URL: https://download.opensuse.org/history/20240523/tumbleweed/repo/oss/

That repo shows me the following:
kernel-default-base-6.8.9-1.1.31.21.x86_64.rpm 5/14/2024, 9:12 AM 44.1 MB
kernel-default-base-6.9.1-1.1.31.22.x86_64.rpm 5/20/2024, 2:10 PM 44.7 MB

Get it quick, as that repo is about to expire.

Finally, I made it to 6.8.9:

Operating System: openSUSE Tumbleweed 20240624
KDE Plasma Version: 6.1.0
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.2
Kernel Version: 6.8.9-1-default (64-bit)
Graphics Platform: X11
Processors: 4 × AMD A8-7650K Radeon R7, 10 Compute Cores 4C+6G
Memory: 14.6 GiB of RAM
Graphics Processor: KAVERI


Findings:

Wayland is not working, X11 does. No change in behaviour.

sudo inxi 3.3.35-00 (2024-06-18)
Machine:
  Type: Desktop Mobo: ASRock model: FM2A78M Pro4+ serial: M80-3C012001343
    UEFI-[Legacy]: American Megatrends v: P2.40 date: 02/05/2016
CPU:
  Info: quad core model: AMD A8-7650K Radeon R7 10 Compute Cores 4C+6G bits: 64 type: MT MCP
    cache: L2: 4 MiB
  Speed (MHz): avg: 1900 min/max: 1900/3800 cores: 1: 1900 2: 1900 3: 1900 4: 1900

sudo inxi -GSaz
System:
  Kernel: 6.8.9-1-default arch: x86_64 bits: 64 compiler: gcc v: 13.2.1 clocksource: tsc
    avail: hpet,acpi_pm parameters: BOOT_IMAGE=/boot/vmlinuz-6.8.9-1-default
    root=UUID=46dfafac-fbe2-48eb-b037-156c4bb3d053 resume=/dev/sda1 showopts loglevel=3
  Console: pty pts/2 DM: SDDM Distro: openSUSE Tumbleweed 20240624
Graphics:
  Device-1: AMD Kaveri [Radeon R7 Graphics] vendor: ASRock driver: radeon v: kernel
    alternate: amdgpu arch: GCN-2 code: Sea Islands process: GF/TSMC 16-28nm built: 2013-17 ports:
    active: HDMI-A-1 empty: DVI-D-1,VGA-1 bus-ID: 00:01.0 chip-ID: 1002:1313 class-ID: 0300
  Device-2: Sunplus Innovation hama C-600 Pro Webcam driver: snd-usb-audio,uvcvideo type: USB
    rev: 2.0 speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 1-4:4 chip-ID: 1bcf:28c4 class-ID: 0102
    serial: <filter>
  Display: server: X.org v: 1.21.1.12 with: Xwayland v: 24.1.0 compositor: kwin_x11 driver: X:
    loaded: radeon unloaded: fbdev,modesetting,vesa dri: radeonsi gpu: radeon tty: 270x68
  Monitor-1: HDMI-A-1 model: Asus VS247 serial: <filter> built: 2015 res: 1920x1080 dpi: 94
    gamma: 1.2 size: 521x293mm (20.51x11.54") diag: 598mm (23.5") ratio: 16:9 modes: max: 1920x1080
    min: 720x400
  API: EGL v: 1.5 hw: drv: amd radeonsi platforms: device: 0 drv: radeonsi device: 1 drv: swrast
    gbm: drv: radeonsi surfaceless: drv: radeonsi inactive: wayland,x11
  API: OpenGL v: 4.5 vendor: mesa v: 24.1.2 note: console (EGL sourced) renderer: KAVERI
    (radeonsi LLVM 18.1.6 DRM 2.50 6.8.9-1-default), llvmpipe (LLVM 18.1.6 256 bits)
  API: Vulkan v: 1.3.283 layers: 2 device: 0 type: cpu name: llvmpipe (LLVM 18.1.6 256 bits)
    driver: N/A device-ID: 10005:0000 surfaces: N/A

Potential summary: The kernel is not the root cause(?)

Ok. Things are working fine on X11 for Felix with the same GPU (same Mesa version, same kernel). I guess Felix is not using Wayland and didn't use with the older Mesa versions either. At least with this kernel option there is a workaround for Sebastian available.

Yes, that's right - the kernel option is the current workaround. And it is acceptable, of course. So, in my view, we can close this thread (again). Many thanks for all your help and support!

Ok. As you wish.

https://forums.opensuse.org/t/cant-start-wayland-session-black-screen/176711 is a freshly reported instance of need in June for radeon.si_support=0 amdgpu.si_support=1 in TW with Oland, suggesting (broken libdrm_radeon1) not "fixed", just worked around via cmdline options.

(In reply to Felix Miata from comment #98)
> https://forums.opensuse.org/t/cant-start-wayland-session-black-screen/176711
> is a freshly reported instance of need in June for radeon.si_support=0
> amdgpu.si_support=1 in TW with Oland, suggesting (broken libdrm_radeon1) not
> "fixed", just worked around via cmdline options.

Thanks, Felix, for the information.

Driven by your comment, I checked if there is an improvement for Wayland / no Kernel options. Unfortunately, no change in behavior - same issue (with Mesa 24.1.3).