After update, FW 13 AMD Fedora 41 screen goes black after login

Framework Laptop 13 Linux
1

I have a FW laptop 13 AMD running Fedora Workstation Linux 41 (KDE, Wayland). I just did a system update, which apparently upped the kernel from 6.12.9 to 6.12.11. Now, after booting and successfully logging in, the laptop screen goes black after a few seconds. The external display (HDMI) remains fully functional. Sleeping/waking and fiddling with display controls doesn’t help. I can reboot into the previous kernel (6.12.9) by pressing esc during boot and selecting the previous kernel from the grub menu and the displays work as expected, but fingerprint unlock is not available after display sleep. I did see there was a UEFI update after I did the system update, but installing it did not help. Disconnecting the external monitor doesn’t improve things.

Edit: the rest of my post got cut off ?! Basically, does anyone have thoughts about what to try next?

2

Could be KDE-specific somehow, ran 6.12.11 on F41 workstation GNOME Wayland here on a FW13 7840U without issues (internal screen plus external via TB dock).

In case this is fixed in the kernel, 6.12.13 is now on testing (seems to be running fine here too) so you could try it before it hits stable:

sudo dnf --refresh --enablerepo updates-testing up kernel*

Also, FWIW, 6.13.x is probably going to reach stable later this week.

Edit: Maybe important: I have the older (matte 2256x1504) internal display.

3

Thanks. It was a good idea but no joy :frowning:.

I forgot about the display now being a variable. I also have the old display. I’ll switch to Gnome and see if that makes a difference.

Edit 20250210@14:46: Tried using Gnome and it seemed to work fine. Certainly ran for far longer than I ever got with KDE/Plasma. When I did a restart, though, the main screen went dark and the external continued to display, but things seemed crashed. So I’m not sure I’d call it “success,” but Gnome certainly worked better than Plasma.

4

Any obvious (ish) journal entries, especially from amdgpu, when this happens? Anything interesting in terms of workload (maybe exposing a graphics driver bug)?

6

I had a couple of applications set to autostart, so I removed them and still have the same problem. I don’t think there are any workload issues, as it’s pretty much a plain vanilla start and the screen loss occurs seconds after login. No journal entries referencing amdgpu around the failure except

Feb 10 17:49:15 framis.sacdoc.org gnome-shell[2145]: Added device '/dev/dri/card1' (amdgpu) using atomic mode setting.

I don’t have a lot of experience with desktop environments, but nothing jumps out at me from the journal at the time that the screen dies.

Thanks for the ideas. I’m still probing.

7

While testing, the problem occurred once while I was still entering my password, so before I actually got to the login process.

Some log entries that I didn’t expect but don’t understand:

Feb 10 18:06:18 framis.sacdoc.org kernel: ucsi_acpi USBC000:00: unknown error 0
Feb 10 18:06:18 framis.sacdoc.org kernel: ucsi_acpi USBC000:00: GET_CABLE_PROPERTY failed (-5)
Feb 10 18:06:18 framis.sacdoc.org kernel: ucsi_acpi USBC000:00: unknown error 256
Feb 10 18:06:18 framis.sacdoc.org kernel: ucsi_acpi USBC000:00: GET_CABLE_PROPERTY failed (-5)
Feb 10 18:06:18 framis.sacdoc.org kernel: ucsi_acpi USBC000:00: unknown error 256
Feb 10 18:06:18 framis.sacdoc.org kernel: ucsi_acpi USBC000:00: GET_CABLE_PROPERTY failed (-5)
8

The problem persists with the latest kernel 6.12.15-200.fc41.x86_64 (64-bit). I tried disabling powerdevil for the display (as it seems the display is just turned off; everything else works fine and the display comes back, at least briefly, after a sleep/wake cycle). As this is a fairly vanilla Fedora with KDE (installed 39 then updated to 40 and 41), I’m surprised I don’t see other reports of it.

If anyone reading this is successfully running Fedora 41 with KDE/Plasma on a FW-13 Ryzen and a kernel > 6.12.9, let me know because I think the next step is then a system re-install.

addendum 20250223@20:40

Turning the display off with kscreen-doctor --dpms off and back on again (with a keypress or kscreen-doctor --dpms on) will bring the black display back, at least for a while (seconds to minutes) so it seems to definitely be a power management problem.

9

I’ve been having the same problem for a while now, probably around the same kernel (or other?) upgrade as twoprops.
Also on an AMD FW13 with the old screen, with KDE/Plasma and Wayland, currently on Linux 6.13.7. My distro is Manjaro.

Something that I’ve noticed: It’s just the backlight that shuts off. In bright light (or using a flashlight) I can see that the rest of the screen still works fine.

I’ve been working around it by using an older LTS kernel (6.6.83 works). Lately (on 6.13), the screen stays on for longer whiles at a time, and shutting the lid for a second makes it work again, but is obviously very annoying. (Thanks for the hint about shutting the screen off with dpms, that’s a bit better.)

In terms of log entries, I keep on seeing this a few seconds after the backlight stops working:

Mär 27 12:55:44 felix-fw13 systemd[1]: dbus-:1.2-org.kde.powerdevil.backlighthelper@130.service: Deactivated successfully.
Mär 27 12:55:48 felix-fw13 systemd[1]: Started dbus-:1.2-org.kde.powerdevil.backlighthelper@131.service.

While writing and testing some live distros, just had some possibly related crash (?) happen:

Details

After a reboot, the backlight turned off as it does, but a few seconds after some stuff thoroughly crashed. The screen turned completely black, after a few seconds my external screen was painted completely and then partially white, I don’t exactly remember. Shutting the lid (going into suspend) and waking the laptop back up, and then waiting a minute or two, seems to have mostly fixed everything, except that the battery icon in the task bar is now missing. And plasma/kwin apparently restarted, Firefox opened a crash report screen, konsole just closed.
Taking a look at the logs, there’s some stuff about a page fault in kwin and pageflips timing out. kwin_wayland_drm says that the latter is a bug in the amdgpu kernel driver and to report it, so I’ll do that and link it here later.

EDIT: The pageflip timeouts are probably some other problem. I still reported them and the crash here: amdgpu / kwin_wayland_drm pageflip timed out and page faults with black/corrupted screen (#4086) · Issues · drm / amd · GitLab

10

I’m sorry that you’re seeing the same problem, but at least a little relieved as I’ve scoured the net and cannot find anyone else reporting it. Yes, it’s only a backlight issue on my machine as well. My system continues to fail with all these kernels:

kernel-6.12.11-200.fc41.x86_64
kernel-6.12.13-200.fc41.x86_64
kernel-6.12.15-200.fc41.x86_64
kernel-6.13.4-200.fc41.x86_64
kernel-6.13.5-200.fc41.x86_64
kernel-6.13.6-200.fc41.x86_64
kernel-6.13.7-200.fc41.x86_64
kernel-6.13.8-200.fc41.x86_64

As of now (20250327@07:33) 6.13.8 is the latest released kernel for Fedora 41. Only kernel 6.12.9 seems to work. At this point, I’m going to wait until Fedora 42 is released and then reinstall the whole system and see if that clears things up.

I should also note that, just yesterday, my display started acting up in other ways (horizontal and vertical lines and shadows). I doubt they’re related, but of course I’ll report here if reseating the display cable or replacing the display or whatever I end up doing has any effect on this problem.

1 Like
11

Okay, so. The crash seems to have killed powerdevil, and after that, for more than two hours, I didn’t get the backlight problem anymore.

On the other hand, after a while I restarted powerdevil (systemctl --user start plasma-powerdevil.service) and it still doesn’t seem to be making any trouble, so this might be a red herring after all.

Then, after a few hours in standby, the problem was back, and worse than ever. The screen goes black almost immediately, and a reboot didn’t change anything!
Your comment made me start to think that this might be a hardware-related problem. I did have a small drop a while ago… Maybe some connection is loose/bad, that causes communication errors, and then something after 6.12.9 changed how those are handled or something? Sound kind of silly, but it would explain the rarity of the issue, and how it seems to randomly get worse and better for me.

12

Re-seating the display connector neither improved my display problems nor cured the display backlight issue.

I also tried deactivating powerdevil

systemctl --user stop plasma-powerdevil.service

Subjectively, the screen is blanking much less often now, but it’s still happening. Given the variability in the problem, it’s possible that killing powerdevil did nothing at all.

13

This is weird. As my main display continues to deteriorate, I decided to switch to my external monitor as the “Primary” display. After I did so, I rebooted using kernel 6.13.8 – a version that always caused the display backlight failure after a minute or two. Ran for two days and no backlight loss. Switched back to the internal display as primary, and it’s still working correctly (well, not the display which is still broken, but I haven’t had the backlight go out in over a day).

I have no idea whether changing the primary display had anything to do with the sudden improvement in behavior, but this has been a hard failure for close to two months now, and the change in display was the only change I’d made between having solid failures on 6.13.8 and having it work correctly.

Note that powerdevil was restarted by the reboot.

14

If you’re having trouble with graphical corruption, this might be a recent driver (or whatever) issue, see https://gitlab.freedesktop.org/mesa/mesa/-/issues/12848#note_2841535
I just tried the downgrade to 24.3.4-1 and that seems to have made the glitches go away.

15

Thanks for the thought, and would that it were so, but I’m 99+% certain this is a hardware issue. It shows up even on the BIOS setup screen. My new display module is supposed to arrive tomorrow.