Frequent boot to black display

[theofficialgman]

Hardware: AMD Framework 13
OS: Ubuntu Noble 24.04
DE: Plasma Wayland
BIOS: version 3.03 and 3.05 (latest new release)
Kernel: 6.8.0-31-generic #31-Ubuntu SMP PREEMPT_DYNAMIC Sat Apr 20 00:40:06 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

This issue started about 2-3 weeks ago I believe around the time that Ubuntu updated Noble to linux kernel 6.8 and linux firmware packages. This issue may not be a kernel regression but instead a wayland regression but I am not certain and looking for help.

The issue is that on boot the (internal laptop and external displays if connected) are black but backlight is lit. I am able to boot into recovery mode without issue since the graphics drivers are not loaded in that case (only amd framebuffer driver and userspace mesa llvmpipe). Cold boot from OFF seems to be the most common case for this issue and it happens about 50-75% of the time from there. I have to force power the device off and try again in this case. I don't know how to get proper bootlogs from the previous boot when this is the case since /var/log only seems to contain logs from the current boot.

ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: xorg 1:7.7+23ubuntu3
ProcVersionSignature: Ubuntu 6.8.0-31.31-generic 6.8.1
Uname: Linux 6.8.0-31-generic x86_64
ApportVersion: 2.28.1-0ubuntu2
Architecture: amd64
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
CasperMD5CheckResult: unknown
CompositorRunning: None
CurrentDesktop: KDE
Date: Mon Apr 22 13:35:21 2024
DistUpgraded: Fresh install
DistroCodename: noble
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes
GpuHangFrequency: Several times a day
GpuHangReproducibility: Yes, I can easily reproduce it
GpuHangStarted: Since a couple weeks or more
GraphicsCard:
 Advanced Micro Devices, Inc. [AMD/ATI] Phoenix1 [1002:15bf] (rev cb) (prog-if 00 [VGA controller])
   Subsystem: Framework Computer Inc. Phoenix1 [f111:0006]
InstallationDate: Installed on 2023-11-16 (159 days ago)
InstallationMedia: Kubuntu 23.10 "Mantic Minotaur" - Release amd64 (20231010)
MachineType: Framework Laptop 13 (AMD Ryzen 7040Series)
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.8.0-31-generic root=UUID=8484eee5-4c87-4cb9-9f40-5f1c9a24db18 ro rtc_cmos.use_acpi_alarm=1 quiet splash vt.handoff=7
SourcePackage: xorg
Symptom: display
Title: Xorg freeze
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 10/17/2023
dmi.bios.release: 3.3
dmi.bios.vendor: INSYDE Corp.
dmi.bios.version: 03.03
dmi.board.asset.tag: *
dmi.board.name: FRANMDCP05
dmi.board.vendor: Framework
dmi.board.version: A5
dmi.chassis.asset.tag: FRANDGCPA5342400SJ
dmi.chassis.type: 10
dmi.chassis.vendor: Framework
dmi.chassis.version: A5
dmi.modalias: dmi:bvnINSYDECorp.:bvr03.03:bd10/17/2023:br3.3:svnFramework:pnLaptop13(AMDRyzen7040Series):pvrA5:rvnFramework:rnFRANMDCP05:rvrA5:cvnFramework:ct10:cvrA5:skuFRANDGCP05:
dmi.product.family: Laptop
dmi.product.name: Laptop 13 (AMD Ryzen 7040Series)
dmi.product.sku: FRANDGCP05
dmi.product.version: A5
dmi.sys.vendor: Framework
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.120-2build1
version.libgl1-mesa-dri: libgl1-mesa-dri 24.0.5-1ubuntu1
version.libgl1-mesa-glx: libgl1-mesa-glx N/A
version.xserver-xorg-core: xserver-xorg-core 2:21.1.12-1ubuntu1
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:22.0.0-1build1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20210115-1build1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-2build1

[Daniel van Vugt (vanvugt)]

Next time you have a failed boot followed by a successful boot, please run:

  journalctl -b-1 > prevboot.txt

and attach the resulting text file here.

[Daniel van Vugt (vanvugt)]

Also, are there any files in /var/crash ?

[theofficialgman (theofficialgman)]

Attached is the journalctl as instructed. I tried to power it off by short pressing the power button a few times (as you can see in the log at the end) while black screened but wasn't able to do that so hard to force power off.

There are no logs in /var/crash/

[theofficialgman (theofficialgman)]

Here is my current boot journalctl (where booting to a desktop succeeded) for comparison incase it helps.

I will also note that on the boot to black screen I never see any plymouth bootlogos or messages. The screen remains black after grub (with only backlight level changing). When I get a successful boot I see the plymouth bootlogos and messages and then get dropped to sddm login screen.

[Daniel van Vugt (vanvugt)]

Plymouth seems to be running, but also terminating within a couple of seconds. Since it's designed to not display anything if it thinks it won't run for very long then I think failing to see a Plymouth boot logo is OK in this case. You might like to try the workaround for bug 1869655 which is to add kernel parameter:

  plymouth.use-simpledrm

I don't know much about sddm, Plasma or KDE, but there's a clear difference in the logs. When the screen remains black you're also missing the sddm log message:

  Display server started.

So it looks like an sddm bug sometimes failing to launch X.

Have you installed a graphics driver manually, or are you using the Ubuntu default drivers?

[theofficialgman (theofficialgman)]

Going to change this back to linux as the plymouth failing to display indicates an issues with KMS (plymouth uses KMS to display graphics on earlyboot which is what is happening here). The bootlogo from plymouth always shows (even for a very brief time) when SDDM starts and when it boots to a black screen the bootlog NEVER shows from plymouth. Using your reasoning of the race condition I should see the bootlogo at least sometimes in the boot to black screen but this has never happened (I have booted dozens of times to black screen and have always never seen the bootlogo).

I do not think this has anything to do with sddm. If KMS is not working then of course everything else that relies on it later in the bootstack will also fail.

The Ubuntu default drivers are in use.

[theofficialgman (theofficialgman)]

this issue has appeared before on other AMD hardware but was closed due to lack of activity and driver changes. my issue shows that it has re-appeared on new hardware and drivers https://gitlab.freedesktop.org/drm/amd/-/issues/1256

[theofficialgman (theofficialgman)]

AMD kernel developer wants to classify this is as both SDDM bug and plymouth bug https://gitlab.freedesktop.org/drm/amd/-/issues/3341. amdgpu kernel driver is not ready by the time that sddm and plymouth are started in some cases (race condition). Marking this as a sddm and plymouth bug (in addition to linux) because of this.

To me it seems that at least a systemd service should be handling blocking starting GUI userspace services until the kernel drivers are actually loaded but that is just my thought. I guess the AMD developer sees this the same way you do Daniel.

[Mario Limonciello (superm1)]

For the plymouth part I think the suggestion above "plymouth.use-simpledrm" makes sense.

[theofficialgman (theofficialgman)]

I am hitting this on i915 as well with the same 50-75% frequency.

I think this need to be upgraded to critical status (at least for non GDM login managers where no mitigation exists) and potentially release blocker depending on how widespread this issue is.

Devices I have confirmed affected by this:
AMD Framework 13
HP Spectre X360

[theofficialgman (theofficialgman)]

here is i915 failed to boot in the same way. you can see the i915 kernel driver does not finish until much after sddm starts

[theofficialgman (theofficialgman)]

here is i915 with a successfull boot. the i915 driver finishes starting before sddm starts.

[Daniel van Vugt (vanvugt)]

Plymouth not displaying anything is covered by bug 1869655 already so please try kernel parameter:

  plymouth.use-simpledrm

which should solve that.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Mario Limonciello (superm1)]

The issue here is the same one that happened in gdm last year where the startup would race with the load of DRM graphics drivers.

GDM fixed it by essentially running the equivalent of 'udevadm settle'. The same kind of fix needs to be ported to sddm or systemd needs to be modified to not emit CanGraphical until DRM graphics drivers are fully loaded.