Comment # 40 on bug 1222156 from Felix Miata

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.