So, I know the Thinkpad x13s is ARM and it’s weird, but this issue doesn’t seem to be covered by any of the other issues I’ve found on the discussion forums.
I have an x13s running and booting on 6.8.5-301.fc40.aarch64 with these kernel args:
cat /proc/cmdline
BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.8.5-301.fc40.aarch64 root=UUID=09e894af-7387-49b4-a27c-b603d8e9df35 ro rootflags=subvol=root arm64.nopauth clk_ignore_unused pd_ignore_unused rd.driver.blacklist=msm
However, after a kernel update (I’ve tried both 6.10.6 and 6.10.7), it boots to a black screen. The journal logs are crammed full of errors for both successful and failed boots, but this is the only log message I’ve found in only failed boots on newer kernels:
Sep 08 08:40:14 fedora kernel: qnoc-sc8280xp interconnect-mc-virt: sync_state() pending due to 3d00000.gpu
Sep 08 08:40:14 fedora kernel: qnoc-sc8280xp interconnect-gem-noc: sync_state() pending due to 3d00000.gpu
Sep 08 08:40:14 fedora kernel: qnoc-sc8280xp interconnect-mc-virt: sync_state() pending due to ae00000.display-subsystem
Sep 08 08:40:14 fedora kernel: qnoc-sc8280xp interconnect-mmss-noc: sync_state() pending due to ae00000.display-subsystem
Sep 08 08:40:14 fedora kernel: qcom-rpmhpd 18200000.rsc:power-controller: sync_state() pending due to ae00000.display-subsystem
Sep 08 08:40:14 fedora kernel: qcom-rpmhpd 18200000.rsc:power-controller: sync_state() pending due to 3000000.remoteproc
As well as these messages:
Aug 04 17:00:01 fedora kernel: qcom_q6v5_pas 3000000.remoteproc: error -ENXIO: IRQ wdog not found
Sep 08 08:40:14 fedora org.gnome.Shell.desktop[4654]: MESA-LOADER: failed to open simpledrm: /usr/lib64/dri/simpledrm_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib64/dri, suffix _dri)
Sep 08 08:40:16 fedora org.gnome.Shell.desktop[5085]: MESA: error: ZINK: failed to choose pdev
Sep 08 08:40:16 fedora org.gnome.Shell.desktop[5085]: libEGL warning: egl: failed to create dri2 screen
Looking online, I’ve found a few other cases of this, but they were all fixed by adding the kernel args that I already added to the system post-boot.
The fact that this has happened with two newer kernels kind of suggests to me that it’s something in the kernel update protocol that’s failing or going wrong. Will continue to investigate, but I’m curious to see if anyone else has any ideas here.