You are not logged in.
I will add that my laptop did not have issues with sleep on Ubuntu 24.10 which used systemd 256 and kernel 6.11+ when I tried it out. I do not know why exactly but I wouldn't be surprised if Canonical might've put in their repos a version of systemd that excludes the features or commits that trigger this issue.
Offline
@ Shijikori: Did you already try the latest systemd release to verify if the issue is still present? v257 is quite a bite newer than the version that caused you the issue ..
I guess 256 introduced the sleep thing:
The behavior of systemd-sleep and systemd-homed has been updated to freeze user sessions when entering the various sleep modes or when locking a homed-managed home area. This is known to cause issues with the proprietary NVIDIA drivers. Packagers of the NVIDIA proprietary drivers may want to add drop-in configuration files that set SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=false for systemd-suspend.service and related services, and SYSTEMD_HOME_LOCK_FREEZE_SESSION=false for systemd-homed.service.
https://github.com/systemd/systemd/blob … 11-L969C33
So maybe setting one of the mentioned variables also helps your usecase?
Offline
@ Shijikori: Did you already try the latest systemd release to verify if the issue is still present? v257 is quite a bite newer than the version that caused you the issue ..
I guess 256 introduced the sleep thing:
The behavior of systemd-sleep and systemd-homed has been updated to freeze user sessions when entering the various sleep modes or when locking a homed-managed home area. This is known to cause issues with the proprietary NVIDIA drivers. Packagers of the NVIDIA proprietary drivers may want to add drop-in configuration files that set SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=false for systemd-suspend.service and related services, and SYSTEMD_HOME_LOCK_FREEZE_SESSION=false for systemd-homed.service.
https://github.com/systemd/systemd/blob … 11-L969C33
So maybe setting one of the mentioned variables also helps your usecase?
I tried v257 yeah. It's really easy to trigger a failure to wake from sleep with 256 and 257. With 255.7 and kernel newer than 6.10, it's a bit more random. Sometimes it will work but it may fail after a long sleep. I am going to downgrade to 6.10 again as 6.12.4 just had a failure to wake after a long sleep with systemd 255.7. Maybe there is an issue on both sides. I also have a MT7921E wifi chip in both of my devices, which could also be causing some issues. It's difficult to diagnose as the logs from journalctl do not have any traces of the wake up failure, they only show the system went to sleep without issues.
Overriding the variables does absolutely nothing in my case. I have tried and eventhough the change is recognised in the systemd unit, it does not materialise in a different behaviour.
Last edited by Shijikori (2024-12-14 20:36:22)
Offline
I am uncertain about firmware causing the issue. My laptop is running linux-firmware from september 2023, as it's the last known firmware to not cause significant issues with the APU's GPU from what I know, and my desktop is running latest linux-firmware. Both experience the same problem. Only way sleep works reliably on both is to use kernel 6.10.9 (seems like any version between 6.10.4 and 6.10.9 works fine though) and systemd 255.7 (or any other v255).
Last edited by Shijikori (2024-12-14 20:44:09)
Offline
The user slice freeze doesn't seem like a feature that should've been merged into main while being so broken.
The override does not work at all. Only reverting to kernel 6.10.3, systemd 255.7 and linux-firmware 20240703 restored sleep to prior functionality.
downgrading the kernel alone to 6.10.10 seems to be enough for me. no change when downgrading systemd or firmware. so sleep on systemd 256.7.1 is working ok with that kernel version
I also have a MT7921E wifi chip in both of my devices
It seemed to rather hinge on the BT component of that chip.
Offline
It seemed to rather hinge on the BT component of that chip.
I'm not sure. I have not seen anything in my logs that could support that. It's also pretty difficult to spot since there's absolutely no logs of the wake up attempt. All I know is that when I use systemd 256 or newer, regardless of kernel version, I have rather consistent wake up failures. When I use a newer kernel and systemd 255.7, I have inconsistent wake up failures.
I don't know how useful that can be but I have not observed issues on Ubuntu 24.10's kernel and systemd versions on my laptop.
Offline
Have you tried the impact of disabling bluetooth?
Offline
Hi, i have had the same issue as Shijikori on my Lenovo TB 15 ABA (AMD Ryzen 5 5625U) for several weeks now, I haven't had Bluetooth enabled since yesterday.
I also downgraded systemd, systemd-libs and systemd-sysvcompat to v 255.7 and IgnorePkg'd them, hope that will solve it for me aswell for now..
EDIT: Still having this issue, could be unrelated.. although symptoms are exactly the same (either frozen black screen with cursor or frozen at login screen upon rising from sleep). I'm also on kernel 6.12.4
EDIT2: I became suspicious because the issues I have been facing used to be sporadic, and since yesterday they occurred 100% so I just decided to stop bluetooth service, that fixes it for me
I suppose I will still have sporadic freezes but that could be due to a separate issue..
Last edited by jordy (2024-12-15 11:00:09)
Offline
Have you tried the impact of disabling bluetooth?
not yet. I will try with my laptop, I don't like messing too much with my desktop as I need it to work well 99% of the time.
I plan on probably attempting a kernel update only on the laptop and then see what happens and try disabling bluetooth. Then I'd try updating systemd.
To be sure, we're talking about the following workaround?
mt7921e.disable_aspm=Y
Still having this issue, could be unrelated.. although symptoms are exactly the same (either frozen black screen with cursor or frozen at login screen upon rising from sleep). I'm also on kernel 6.12.4
I downgraded to kernel 6.10.9 with systemd 255.7 to eliminate those issues.
Offline
We're talking about "completely disable bluetooth, either (preferably) in the BIOS or rfkill it, https://bbs.archlinux.org/viewtopic.php … 9#p2202379
Offline
We're talking about "completely disable bluetooth, either (preferably) in the BIOS or rfkill it, https://bbs.archlinux.org/viewtopic.php … 9#p2202379
well, that isn't an acceptable solution for me. I do need bluetooth every week so that won't do it.
Offline
Not "solution", "identify the cause"
Offline
Adding to the discussion as well with the same problem (since Linux 6.11+). Only one computer is affected (AMD Ryzen 5 5600G with Radeon Graphics, on a B550I AORUS PRO AX). Tested with Linux 6.12.4 and the problem persists: after waking up from sleep (KDE Plasma 6.2.4) the system freezes.
As a workaround, I've installed the Linux-lts kernel which doesn't have this problem (as well as an older kernel version I kept around, 6.10.3).
Offline
And does that computer have an mt7921e chip?
Offline
And does that computer have an mt7921e chip?
MT7921K
Offline
Yeah, fits - try to disable/rfkill BT and see whether that helps.
There's also https://bbs.archlinux.org/viewtopic.php?id=301691 where possibly stopping the connection and reloading the module can work around the issue.
Offline
Yeah, fits - try to disable/rfkill BT and see whether that helps.
There's also https://bbs.archlinux.org/viewtopic.php?id=301691 where possibly stopping the connection and reloading the module can work around the issue.
That does the trick! Just disabled Bluetooth followed by a reboot to check and, indeed, sleep works again. I guess for the time being I'll stick with Linux-lts. Seems to be some combo with the chip and Linux 6.11+?
Offline
This affected 6.11 already?
https://github.com/torvalds/linux/commi … 86e52eaf1e ?
Offline
Yes, but I don't remember the exact version (could've been 6.11 or 6.11.x) because the affected computer isn't mine (I just keep it updated). But definitely pre 6.12 and, as mentioned, 6.10.x was still working.
Offline
The linked commit might be worth a shot before anyone goes bisecting, then
Offline
Kernel 6.12.5 recently enabled the MediaTek MT7925 Bluetooth adapter on my Gigabyte X870E Aorus Elite Wifi 7 motherboard. As a result, I've also been experiencing failed suspends. My computer will click off whenever it goes to sleep, but it will fail to resume properly. My monitor has no signal and my system is completely unresponsive. Kernel 6.12.4 did not support my BT adapter and sleep was fine. Disabling the adapter in the BIOS makes suspend work properly on 6.12.5 and newer.
Here's the hardware info for the adapter
[user@arch-desktop ~]$ inxi -Eaz
Bluetooth:
Device-1: Foxconn / Hon Hai Wireless_Device driver: btusb v: 0.8 type: USB
rev: 2.1 speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 1-6:4 chip-ID: 0489:e124
class-ID: e001 serial: <filter>
Report: bt-adapter ID: hci0 rfk-id: 0 state: up address: <filter> status:
discoverable: no active: no pairing: yes class-ID: 6c0104
And here's the commit that enabled it: https://github.com/torvalds/linux/commi … 168642a8e6
Which was taken from this Arch forums thread: https://bbs.archlinux.org/viewtopic.php … 8#p2210358
Offline
Kernel 6.12.5 recently enabled the MediaTek MT7925 Bluetooth adapter on my Gigabyte X870E Aorus Elite Wifi 7 motherboard. As a result, I've also been experiencing failed suspends. My computer will click off whenever it goes to sleep, but it will fail to resume properly. My monitor has no signal and my system is completely unresponsive. Kernel 6.12.4 did not support my BT adapter and sleep was fine. Disabling the adapter in the BIOS makes suspend work properly on 6.12.5 and newer.
Here's the hardware info for the adapter
[user@arch-desktop ~]$ inxi -Eaz Bluetooth: Device-1: Foxconn / Hon Hai Wireless_Device driver: btusb v: 0.8 type: USB rev: 2.1 speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 1-6:4 chip-ID: 0489:e124 class-ID: e001 serial: <filter> Report: bt-adapter ID: hci0 rfk-id: 0 state: up address: <filter> status: discoverable: no active: no pairing: yes class-ID: 6c0104
And here's the commit that enabled it: https://github.com/torvalds/linux/commi … 168642a8e6
Which was taken from this Arch forums thread: https://bbs.archlinux.org/viewtopic.php … 8#p2210358
I seem to have this issue as well. I have an X870 Gigabyte board with the same chipset. I rolled back to Kernel 6.12.4 and I can resume from suspend without issue. At first I thought it was the latest mesa drivers; however, after rolling them back, my computer still freezes on wakeup from suspend when on kernel 6.12.6. Anyone running rc-6.13 have this issue?
Offline
I also have the ASUS X870-PLUS motherboard, the same problem. Switched kernel to 6.10.10 just in case, no problem ever since with resuming from suspend.
Offline
No need to rollback the kernel if the BT adapter is indeed the root cause of your issue like it is for me. Simply disable it in the BIOS or disable in your DE settings. In KDE, I can simply switch that adapter off, and now suspend works fine. I assume `rfkill` works just as well.
Offline
No need to rollback the kernel if the BT adapter is indeed the root cause of your issue like it is for me. Simply disable it in the BIOS or disable in your DE settings. In KDE, I can simply switch that adapter off, and now suspend works fine. I assume `rfkill` works just as well.
This seems to work as well. I just disable bluetooth in the DE. In my Gigabyte X870, I cannot find a way to disable the onboard wifi/BT chipset. Searching around on the internet, it seems that this option is not present on older motherboards.
edit: I tried to blacklist the module using a modprobe.d config and it doesn't seem to disable the device.
mkinitcpio -M shows mt7925e in the output. I made a conf file in modprobe.d with 'blacklist mt7925e' and rebuild the images. On reboot, the bluetooth device still is functional.
Adding module_blacklist=mt7925e to the kernel params in grub and rebuilding the cfg file doesn't work as well. The device still loads. Any ideas?
Last edited by archbusby (2024-12-28 18:46:18)
Offline