https://bugzilla.suse.com/show_bug.cgi?id=1222156 https://bugzilla.suse.com/show_bug.cgi?id=1222156#c40 --- Comment #40 from Felix Miata <mrmazda@earthlink.net> --- Created attachment 874268 --> https://bugzilla.suse.com/attachment.cgi?id=874268&action=edit 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. -- You are receiving this mail because: You are on the CC list for the bug.