Bug 219116

Summary:	6.10+ breaks plymouth boot splash if CONFIG_MODULE_COMPRESS_NONE
Product:	Drivers	Reporter:	Nowa Ammerlaan (nowa)
Component:	Console/Framebuffers	Assignee:	James Simmons (jsimmons)
Status:	NEW ---
Severity:	normal	CC:	regressions
Priority:	P3
Hardware:	All
OS:	Linux
Kernel Version:		Subsystem:
Regression:	No	Bisected commit-id:
Attachments:	kernel config dmesg

Description Nowa Ammerlaan 2024-08-01 09:18:57 UTC

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.

Comment 1 Nowa Ammerlaan 2024-08-01 09:19:14 UTC

Created attachment 306652 [details]
kernel config

Comment 2 Nowa Ammerlaan 2024-08-01 09:21:01 UTC

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.

Comment 3 Nowa Ammerlaan 2024-08-01 19:29:58 UTC

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.

Comment 4 The Linux kernel's regression tracker (Thorsten Leemhuis) 2024-08-04 10:43:26 UTC

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.

Comment 5 The Linux kernel's regression tracker (Thorsten Leemhuis) 2024-08-04 10:46:38 UTC

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.

Comment 6 Nowa Ammerlaan 2024-08-04 10:53:11 UTC

(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.

Comment 7 Nowa Ammerlaan 2024-08-04 20:06:00 UTC

I can still reproduce this issue with: 
- plymouth v24.004.60
- plymouth v24.004.60 + patch
- plymouth live git version

Comment 8 The Linux kernel's regression tracker (Thorsten Leemhuis) 2024-08-05 11:08:25 UTC

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.