After upgrading from the 6.9 to 6.10 series I noticed that plymouth is no longer displaying the proper boot splash. Instead of the usual bgrt+spinner I get what looks like a fallback theme. Note that during shutdown the proper theme is shown again, indicating that bgrt is still working. The problem seems to me to be related to the framebuffer initialization. I can reproduce this with 6.11_rc1, and downgrading to a fresh 6.9 resolves the problem. And I have tried both with CONFIG_FB_EFI=y only as well as with CONFIG_FB_EFI=y, CONFIG_DRM_SIMPLEDRM=y, and CONFIG_SYSFB_SIMPLEFB=y. By accident I discovered that enabling CONFIG_MODULE_COMPRESS_XZ=y resolves the problem. This makes me think that some race condition is responsible, and that the added delay of decompressing the (i915,xe) kernel modules somehow avoids this.
Created attachment 306652 [details] kernel config
Created attachment 306653 [details] dmesg Note that the issue reproduces both with and without 'i915.enable_guc=3' and both with Xe and i915 kernel drivers for 56a0.
I can reproduce this issue on my laptop (Dynabook Satellite Pro L50-G) as well, the same workaround (enabling xz module compression) somehow resolves the problem.
Which distro are you using and is you plymouth up2date? There iirc was some bug in plymouth recently that sounded similar to this and was fixed; nobody ever checked what triggered this on the kernel level.
Ohh, seems the fix for that one did not make it into a release yet: https://gitlab.freedesktop.org/plymouth/plymouth/-/merge_requests/319 But your problem might be a different one anyway. Still might be worth trying that patch.
(In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from comment #4) > Which distro are you using and is you plymouth up2date? There iirc was some > bug in plymouth recently that sounded similar to this and was fixed; nobody > ever checked what triggered this on the kernel level. This is Gentoo Linux with plymouth 22.02.122-r1. I see we are behind a couple of versions so I'll test the latest plymouth code and see if I can still reproduce.
I can still reproduce this issue with: - plymouth v24.004.60 - plymouth v24.004.60 + patch - plymouth live git version
Thx for testing. Hmmmmm. The problem is: I'm suspect no developer will look into this without a bisection that identifies the commit that broke things. But as this is likely a race, I'm not sure if a bisection will help either -- but it might. But you are best to decide if that chance is worth investing time in a bisection.