Description of problem: When a user-session (not system-session!) libvirt virtual machine is running (in gnome-boxes/virt-manager) and the host system is suspended, the following happens: 1. the suspend takes 60 seconds instead of the regular several seconds (measured from the action to the power button indicating sleep). There is something timing out there. 2. after resume, the screen is black and the keyboard/mouse are unresponsive (even keyboard LEDs don't react to capslock etc, no keyboard shortcuts like Ctrl+Alt+Fn work). It seems completely frozen. 3. the system can be reached through ssh. The 'user.slice' is in "active (freezing)" state (i.e. it looks like it's still attempting to freeze it). 4. after `sudo systemctl thaw user.slice` is executed, the system monitor and peripherals come to life and can be finally used normally So in short, it looks like a user-session VM causes systemd to fail to freeze to user slice (causing the suspend timeout) and also prevents systemd from thawing the user slice when the system is resumed. Version-Release number of selected component (if applicable): systemd-256.7-1.fc41.x86_64 libvirt-daemon-10.6.0-5.fc41.x86_64 How reproducible: always Steps to Reproduce: 0. enable and start ssh in your system 1. run a user-session virtual machine either in gnome-boxes or virt-manager 2. while the VM is running, order the host system to suspend 3. see that the suspend takes 60 seconds 4. resume the system 5. see that the screen it black and input peripherals are unresposive 6. ssh in 7. run `sudo systemctl that user.slice` 8. see that monitor and peripherals can now be used normally 9. compare this to a case when user-session VM is not running Actual results: after resume, the user can't use the machine Expected results: after resume, the user can use the machine Additional info: This was initially reported by Alessio (kudos!) on the test list: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/LOMGDJ4TGM3V4RSHRHSUKRMNMIBA4OHP/
Created attachment 2053274 [details] session info from loginctl after resume The output of `loginctl show session 1` after resume (before manual thaw).
Created attachment 2053275 [details] session-1.scope status after resume The output of `systemctl status session-1.scope` after resume (before manual thaw).
Created attachment 2053276 [details] user-1000.slice status after resume The output of `systemctl status user-1000.scope` after resume (before manual thaw).
Created attachment 2053277 [details] user.slice status after resume The output of `systemctl status user.slice` after resume (before manual thaw).
Created attachment 2053278 [details] system journal after resume and manual thaw System journal after resume and manual thaw. The suspend is requested at 13:27:49 and seems to finish at 13:28:50. System resume is triggered at 13:29:31. Manual thaw is performed at 13:33:29.
Created attachment 2053279 [details] system journal (only warnings and up) The same journal as above, but includes only warnings and up.
Notable lines from the journal: Oct 23 13:27:49 chronos gnome-shell[1979]: Cursor update failed: drmModeAtomicCommit: Invalid argument Oct 23 13:28:16 chronos virtqemud[1768]: internal error: connection closed due to keepalive timeout Oct 23 13:28:50 chronos systemd-sleep[4119]: Failed to freeze unit 'user.slice': Connection timed out Oct 23 13:29:53 chronos systemd[1]: Cannot start frozen unit session-4.scope - Session 4 of User kparal. Oct 23 13:32:40 chronos systemd[1]: Cannot start frozen unit user-0.slice - User Slice of UID 0. Oct 23 13:32:40 chronos systemd[1]: Dependency failed for user - User Manager for UID 0. Oct 23 13:32:40 chronos systemd[1]: Dependency failed for session-c2.scope - Session c2 of User root. Oct 23 13:32:40 chronos systemd[1]: Dependency failed for user-runtime-dir - User Runtime Directory /run/user/0. Oct 23 13:32:40 chronos systemd[1]: user-0.slice: Cannot realize cgroup for frozen unit. Oct 23 13:32:40 chronos systemd[1]: user-0.slice: Cannot realize cgroup for frozen unit. ...
*** Bug 2314036 has been marked as a duplicate of this bug. ***
@Zbyszek We might want to disable user session freezing for F-41.
@dtardon @zbyszek.pl F41 is GO and so this can only go out as a subsequent update. Unless you want to submit the update really soon, I'm going to document it as a Common Issue. Is there any simple workaround that people can make to avoid this issue (e.g. adjust some systemd configuration)? Thanks!
This is now documented here: https://discussion.fedoraproject.org/t/system-is-frozen-after-resume-from-suspend-when-a-virtual-machine-is-running/134442 I'd appreciate any corrections, better workarounds, etc. (or, even better, an update that completely fixes it)
(In reply to Kamil Páral from comment #10) > @dtardon @zbyszek.pl > F41 is GO and so this can only go out as a subsequent update. Unless you > want to submit the update really soon, I'm going to document it as a Common > Issue. Is there any simple workaround that people can make to avoid this > issue (e.g. adjust some systemd configuration)? Thanks! This should work (untested): # systemctl edit --stdin --drop-in=50-keep-warm.conf systemd-sleep.service <<EOF [Service] Environment=SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=0 EOF That's for plain suspend. If one uses hibernation, then systemd-hibernate.service and systemd-suspend-then-hibernate.service need the same config override.
David, unfortunately this doesn't work: $ sudo systemctl edit --stdin --drop-in=50-keep-warm.conf systemd-sleep.service <<EOF ... No files found for systemd-sleep.service. Run 'systemctl edit --force --full systemd-sleep.service' to create a new unit. I also tried to add SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=0 to /etc/environment (and reboot), but no change either.
@kparal I saw the same thing, it should be done on _systemd-suspend.service_ instead. I also did a systemctl daemon-reload after that.
FWIW, there is an open issue on systemd that sounds possibly related: https://github.com/systemd/systemd/issues/33083 (via the Arch forums: https://bbs.archlinux.org/viewtopic.php?id=296954) People have suspected this to be related to NVidia drivers, bluetooth, AMD CPUs, or kernel version, but really the common factor seems to be systemd... I've personally encountered the issue on a Framework 13 laptop with an AMD CPU and Fedora Kinoite 41, not running any VMs, but maybe running a toolbox container. ("maybe" because I encountered this bug multiple times, and I don't fully recall the setup for all of them).
(In reply to Dimitris from comment #14) > @kparal I saw the same thing, it should be done on > _systemd-suspend.service_ instead. I also did a systemctl daemon-reload > after that. Thanks, that works. I updated the common issue description (see comment 11).
(In reply to Dimitris from comment #14) > @kparal I saw the same thing, it should be done on > _systemd-suspend.service_ instead. I also did a systemctl daemon-reload > after that. Thanks, It works.
systemd bug 33626[0] mentions a kernel patch that improves the issue, but apparently doesn't completely solve it. I am seeing the problem on a desktop with an AMD 5800x3d / 6800XT, and a laptop with an Intel i7-8550U (no dedicated GPU). So I don't believe this has anything to do with Nvidia. [0] - https://github.com/systemd/systemd/issues/33626
Another workaround from the kernel bugzilla[0]: echo "never" | sudo tee /sys/module/kvm/parameters/nx_huge_pages Works for me, though I'm not sure I fully understand why. [0] - https://bugzilla.kernel.org/show_bug.cgi?id=219112#c5
As a data point, with ThinkPad T14s Gen 2i, Ctrl+Alt+F3 actually gives me a login prompt, so it's possible to salvage the system without ssh with that sudo systemctl thaw user.slice that way.
(In reply to Jan Pazdziora from comment #20) > As a data point, with ThinkPad T14s Gen 2i, Ctrl+Alt+F3 actually gives me a > login prompt, so it's possible to salvage the system without ssh with that > sudo systemctl thaw user.slice that way. Thanks, I can add it as a possible workaround. But it doesn't work for me, so it's only applicable to some systems, it seems. Not sure what the difference could be.
(In reply to Kamil Páral from comment #21) > (In reply to Jan Pazdziora from comment #20) > > As a data point, with ThinkPad T14s Gen 2i, Ctrl+Alt+F3 actually gives me a > > login prompt, so it's possible to salvage the system without ssh with that > > sudo systemctl thaw user.slice that way. > > Thanks, I can add it as a possible workaround. But it doesn't work for me, > so it's only applicable to some systems, it seems. Not sure what the > difference could be. You need to do it before starting any VMs. It is also possible there are multiple issues at play here and I've just been lucky that it works for me.
Brandon, I was responding to Jan, not you :-) Thanks for your workaround as well, though! I didn't include it in the Common Issue, because I wasn't sure about the consequences and the systemd workaround seems good enough.
FEDORA-2024-48a0ce13b3 (systemd-256.8-1.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-48a0ce13b3
FEDORA-2024-48a0ce13b3 has been pushed to the Fedora 41 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-48a0ce13b3` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-48a0ce13b3 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
(In reply to Fedora Update System from comment #24) > FEDORA-2024-48a0ce13b3 (systemd-256.8-1.fc41) has been submitted as an > update to Fedora 41. > https://bodhi.fedoraproject.org/updates/FEDORA-2024-48a0ce13b3 This fixes the issue for me. Thanks.
FEDORA-2024-7ce0c0499e (systemd-257~rc2-2.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2024-7ce0c0499e
FEDORA-2024-48a0ce13b3 (systemd-256.8-1.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.
The problem still appears to persist here. Lenovo ThinkPad E14 Gen 3 (AMD Ryzen™ 7 5700U systemd.x86_64 256.8-1.fc41 installed from updates. I use podman, Boxes and VirtualBox at various times but most of the time I am on the core system with no containers or VMs running when the hang occurs. Turning off Bluetooth still works, not a major issue for me most of the time just awkward.
The issue persists when I have Bluetooth enabled here Acer aspire 5 Ryzen 7 5700u systemd.x86_64 256.8-1 on Silverblue testing
Paul, fastos: I think you might be seeing a different issue. 256.8-1.fc41 disabled freezing of user sessions.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #31) > Paul, fastos: I think you might be seeing a different issue. 256.8-1.fc41 > disabled freezing of user sessions. Sorry if I have misunderstood the problem. As my user session fails to restart and can be kicked on using ssh I had thought it was the same. Turning off Bluetooth fixed the issue for me, so I had put 1+1 together and concluded that the answer was indeed anything I wanted it to be. I admit I did not fit the whole scenario of the original query so I will continue to look for the cause of my issue. Thank you for pointing out my error of judgement.
FEDORA-2024-7ce0c0499e (systemd-257~rc2-2.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
Is it correct that the systemd service still exists on systems and remains active? If I am not mistaken, I did not manually add this service—it seems to have appeared after an update (please correct me if I’m wrong). I found the following configuration file: root@fedora ~ # cat /usr/lib/systemd/system/service.d/50-keep-warm.conf # Disable freezing of user sessions to work around kernel bugs. # See https://bugzilla.redhat.com/show_bug.cgi?id=2321268 [Service] Environment=SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=0 This is on Fedora 41 with the latest updates. Could you confirm whether this behavior is expected?
(In reply to redhat from comment #34) > Is it correct that the systemd service still exists on systems and remains > active? If you're referring to systemd ITSELF, that's the service that manages the entire system's startup and initialization (as well as managing runtime services). Your system doesn't run without it. If you're referring to a specific service like systemd-suspend.service or one of the other services managed by systemd, then yes those should still be active -- they're no longer causing issues now that the configuration provided by that drop-in file is included. > If I am not mistaken, I did not manually add this service—it seems > to have appeared after an update (please correct me if I’m wrong). > This is on Fedora 41 with the latest updates. Could you confirm whether this > behavior is expected? That configuration drop-in (the file you found) was added in the recent updates (linked above), it's attached to services running in systemd to work around the issue reported here. It's expected that it would be present on any system. It won't have any effect if you don't use hardware suspend features on your system, or if you do but were previously able to suspend without problems. However, if you were having issues with your system exhibiting long delays on suspend and/or being unresponsive on resume, with the added configuration they should no longer occur.
(In reply to "FeRD" (Frank Dana) from comment #35) > > If you're referring to a specific service like systemd-suspend.service or > one of the other services managed by systemd, then yes those should still be > active -- they're no longer causing issues now that the configuration > provided by that drop-in file is included. (Just to clarify, I misspoke in saying that systemd-hibernate or other systemd services were CAUSING issues. They were EXPERIENCING issues, which are now prevented by the addition of the SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=0 configuration.)
(In reply to "FeRD" (Frank Dana) from comment #35) > (In reply to redhat from comment #34) > > Is it correct that the systemd service still exists on systems and remains > > active? > > If you're referring to systemd ITSELF, that's the service that manages the > entire system's startup and initialization (as well as managing runtime > services). Your system doesn't run without it. > > If you're referring to a specific service like systemd-suspend.service or > one of the other services managed by systemd, then yes those should still be > active -- they're no longer causing issues now that the configuration > provided by that drop-in file is included. > > > If I am not mistaken, I did not manually add this service—it seems > > to have appeared after an update (please correct me if I’m wrong). > > > This is on Fedora 41 with the latest updates. Could you confirm whether this > > behavior is expected? > > That configuration drop-in (the file you found) was added in the recent > updates (linked above), it's attached to services running in systemd to work > around the issue reported here. It's expected that it would be present on > any system. It won't have any effect if you don't use hardware suspend > features on your system, or if you do but were previously able to suspend > without problems. However, if you were having issues with your system > exhibiting long delays on suspend and/or being unresponsive on resume, with > the added configuration they should no longer occur. Thank you for your response. My question was specifically about the '/usr/lib/systemd/system/service.d/50-keep-warm.conf' file, as it appears in dmesg/journalctl logs as a warning when suspending. I was wondering if the underlying issue that this configuration works around has already been resolved, making the workaround unnecessary. Regarding suspend, there are ongoing issues with the Lenovo P14s Gen4 AMD when used with docking stations. These issues have persisted for years across multiple AMD ThinkPad generations. However, this is outside the scope of this bug report. More information can be found on the (currently migrating) https://gitlab.freedesktop.org).
Not sure if this is somewhat related to what I am experiencing here, but the thing is that, on my system (ACER Ryzen 7 laptop, AMD Renoir iGPU, Nvidia GTX 1650 dGPU, Fedora 41, Nvidia opensource driver, no VMs running), *automatic* suspend fails 100% of the times with this: mar 24 15:56:34 systemd-sleep[46994]: User sessions remain unfrozen on explicit request ($SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=0). mar 24 15:56:34 systemd-sleep[46994]: This is not recommended, and might result in unexpected behavior, particularly mar 24 15:56:34 systemd-sleep[46994]: in suspend-then-hibernate operations or setups with encrypted home directories. mar 24 15:56:34 systemd-sleep[46994]: Performing sleep operation 'suspend'... mar 24 15:56:34 kernel: PM: suspend entry (deep) mar 24 15:56:34 kernel: Filesystems sync: 0.110 seconds mar 24 15:56:55 kernel: Freezing user space processes mar 24 15:56:55 kernel: Freezing user space processes failed after 20.006 seconds (1 tasks refusing to freeze, wq_busy=0): mar 24 15:56:55 kernel: task:gnome-shell state:R running task stack:0 pid:16534 tgid:16534 ppid:16398 flags:0x00004006 mar 24 15:56:55 kernel: Call Trace: mar 24 15:56:55 kernel: <TASK> mar 24 15:56:55 kernel: ? srso_return_thunk+0x5/0x5f mar 24 15:56:55 kernel: ? __schedule+0x2b5/0x5f0 mar 24 15:56:55 kernel: ? os_acquire_spinlock+0x12/0x30 [nvidia] mar 24 15:56:55 kernel: ? srso_return_thunk+0x5/0x5f mar 24 15:56:55 kernel: ? sysvec_reschedule_ipi+0x28/0xf0 mar 24 15:56:55 kernel: ? srso_return_thunk+0x5/0x5f mar 24 15:56:55 kernel: ? asm_sysvec_reschedule_ipi+0x1a/0x20 mar 24 15:56:55 kernel: ? srso_return_thunk+0x5/0x5f mar 24 15:56:55 kernel: ? sysvec_apic_timer_interrupt+0xe/0x90 mar 24 15:56:55 kernel: ? srso_return_thunk+0x5/0x5f mar 24 15:56:55 kernel: ? asm_sysvec_apic_timer_interrupt+0x1a/0x20 mar 24 15:56:55 kernel: ? srso_return_thunk+0x5/0x5f mar 24 15:56:55 kernel: ? srso_return_thunk+0x5/0x5f mar 24 15:56:55 kernel: ? _nv029019rm+0x10/0x10 [nvidia] mar 24 15:56:55 kernel: ? _nv029557rm+0x7a/0x130 [nvidia] mar 24 15:56:55 kernel: ? srso_return_thunk+0x5/0x5f mar 24 15:56:55 kernel: ? _nv046880rm+0xd/0x20 [nvidia] mar 24 15:56:55 kernel: ? _nv011587rm+0x119/0x280 [nvidia] mar 24 15:56:55 kernel: ? _nv056423rm+0x80/0x170 [nvidia] mar 24 15:56:55 kernel: ? _nv038479rm+0x8a/0xd0 [nvidia] mar 24 15:56:55 kernel: ? _nv038682rm+0x10a/0x360 [nvidia] mar 24 15:56:55 kernel: ? _nv032795rm+0xed/0x1f0 [nvidia] mar 24 15:56:55 kernel: ? _nv032795rm+0xbd/0x1f0 [nvidia] mar 24 15:56:55 kernel: ? _nv032763rm+0x6f0/0x1240 [nvidia] mar 24 15:56:55 kernel: ? _nv024664rm+0x13a0/0x1e80 [nvidia] mar 24 15:56:55 kernel: ? _nv013141rm+0x161/0x290 [nvidia] mar 24 15:56:55 kernel: ? _nv037426rm+0x1e5/0x4a0 [nvidia] mar 24 15:56:55 kernel: ? _nv037426rm+0x18f/0x4a0 [nvidia] mar 24 15:56:55 kernel: ? _nv041200rm+0xb67/0xf00 [nvidia] mar 24 15:56:55 kernel: ? _nv053350rm+0x28d/0x3a0 [nvidia] mar 24 15:56:55 kernel: ? _nv051354rm+0xfd/0x160 [nvidia] mar 24 15:56:55 kernel: ? _nv051352rm+0x5c/0x90 [nvidia] mar 24 15:56:55 kernel: ? _nv051352rm+0x32/0x90 [nvidia] mar 24 15:56:55 kernel: ? _nv013403rm+0x67/0xa0 [nvidia] mar 24 15:56:55 kernel: ? _nv013403rm+0x28/0xa0 [nvidia] mar 24 15:56:55 kernel: ? rm_kernel_rmapi_op+0x92/0x273 [nvidia] mar 24 15:56:55 kernel: ? nvkms_call_rm+0x4d/0x80 [nvidia_modeset] mar 24 15:56:55 kernel: ? _nv003120kms+0x4c/0x60 [nvidia_modeset] mar 24 15:56:55 kernel: ? _nv000585kms+0xb4/0x110 [nvidia_modeset] mar 24 15:56:55 kernel: ? _nv000585kms+0x8e/0x110 [nvidia_modeset] mar 24 15:56:55 kernel: ? __nv_drm_gem_nvkms_map+0x6f/0xd0 [nvidia_drm] mar 24 15:56:55 kernel: ? __nv_drm_gem_nvkms_mmap+0x16/0x40 [nvidia_drm] mar 24 15:56:55 kernel: ? nv_drm_mmap+0xdd/0x160 [nvidia_drm] mar 24 15:56:55 kernel: ? __mmap_new_vma+0xe7/0x2f0 mar 24 15:56:55 kernel: ? vma_merge_new_range+0x75/0x190 mar 24 15:56:55 kernel: ? __mmap_region+0x8f4/0xb30 mar 24 15:56:55 kernel: ? kfence_protect+0xa5/0xd0 mar 24 15:56:55 kernel: ? arch_get_unmapped_area_topdown+0x166/0x3e0 mar 24 15:56:55 kernel: ? mmap_region+0x78/0xa0 mar 24 15:56:55 kernel: ? do_mmap+0x499/0x690 mar 24 15:56:55 kernel: ? ima_file_mmap+0x44/0xe0 mar 24 15:56:55 kernel: ? vm_mmap_pgoff+0xec/0x1c0 mar 24 15:56:55 kernel: ? ksys_mmap_pgoff+0x14b/0x220 mar 24 15:56:55 kernel: ? srso_return_thunk+0x5/0x5f mar 24 15:56:55 kernel: ? drm_ioctl_kernel+0xb0/0x100 mar 24 15:56:55 kernel: ? do_syscall_64+0x82/0x160 mar 24 15:56:55 kernel: ? drm_ioctl+0x2b7/0x530 mar 24 15:56:55 kernel: ? __pfx_nv_drm_gem_alloc_nvkms_memory_ioctl+0x10/0x10 [nvidia_drm] mar 24 15:56:55 kernel: ? srso_return_thunk+0x5/0x5f mar 24 15:56:55 kernel: ? rseq_get_rseq_cs+0x1d/0x220 mar 24 15:56:55 kernel: ? srso_return_thunk+0x5/0x5f mar 24 15:56:55 kernel: ? rseq_ip_fixup+0x8d/0x1d0 mar 24 15:56:55 kernel: ? srso_return_thunk+0x5/0x5f mar 24 15:56:55 kernel: ? objects_lookup+0xa1/0xd0 mar 24 15:56:55 kernel: ? srso_return_thunk+0x5/0x5f mar 24 15:56:55 kernel: ? drm_vma_offset_add+0x33/0x70 mar 24 15:56:55 kernel: ? srso_return_thunk+0x5/0x5f mar 24 15:56:55 kernel: ? __nv_drm_gem_map_nvkms_memory_offset+0x1d/0x70 [nvidia_drm] mar 24 15:56:55 kernel: ? srso_return_thunk+0x5/0x5f mar 24 15:56:55 kernel: ? nv_drm_gem_map_offset_ioctl+0x4c/0xd0 [nvidia_drm] mar 24 15:56:55 kernel: ? srso_return_thunk+0x5/0x5f mar 24 15:56:55 kernel: ? drm_ioctl_kernel+0xb0/0x100 mar 24 15:56:55 kernel: ? srso_return_thunk+0x5/0x5f mar 24 15:56:55 kernel: ? __check_object_size.part.0+0x35/0xc0 mar 24 15:56:55 kernel: ? srso_return_thunk+0x5/0x5f mar 24 15:56:55 kernel: ? srso_return_thunk+0x5/0x5f mar 24 15:56:55 kernel: ? drm_ioctl+0x2b7/0x530 mar 24 15:56:55 kernel: ? __pfx_nv_drm_gem_map_offset_ioctl+0x10/0x10 [nvidia_drm] mar 24 15:56:55 kernel: ? srso_return_thunk+0x5/0x5f mar 24 15:56:55 kernel: ? syscall_exit_to_user_mode+0x10/0x210 mar 24 15:56:55 kernel: ? srso_return_thunk+0x5/0x5f mar 24 15:56:55 kernel: ? do_syscall_64+0x8e/0x160 mar 24 15:56:55 kernel: ? do_user_addr_fault+0x55a/0x7b0 mar 24 15:56:55 kernel: ? srso_return_thunk+0x5/0x5f mar 24 15:56:55 kernel: ? exc_page_fault+0x7e/0x180 mar 24 15:56:55 kernel: ? entry_SYSCALL_64_after_hwframe+0x76/0x7e mar 24 15:56:55 kernel: </TASK> mar 24 15:56:55 kernel: OOM killer enabled. mar 24 15:56:55 kernel: Restarting tasks ... done. mar 24 15:56:55 kernel: random: crng reseeded on system resumption mar 24 15:56:55 rtkit-daemon[1127]: The canary thread is apparently starving. Taking action. mar 24 15:56:55 kernel: PM: suspend exit However, *manual* suspend (by pressing the power button) works 99% of the times. The stacktrace is full of Nvidia driver calls, which led me to think it is a driver issue (I've reported it on their forum many times already), but if there is any workaround I could use, I'd be most happy (right now, my current workaround is disabling automatic suspend while the laptop is charging, which is pretty bad)
(In reply to Andre Costa from comment #38) > Not sure if this is somewhat related to what I am experiencing here I don't think so. Please file a different bug, or ask for advice at https://discussion.fedoraproject.org .
I am still experiencing that the system fails to thaw the user sessions after a freeze, with latest updates (Fedora 42, kernel 6.14.7-301.fc42.x86_64, systemd 257.5-6.fc42.x86_64). One VM was running via libvirt/kvm. I was able to log in via SSH, but the user slices were frozen. I had to manually "systemctl thaw" the user sessions and slices.
I've run into this on F41 and it looks like the session freeze still happens if /usr/lib/systemd/systemd-sleep is used to initiate the action, ie `sudo /usr/lib/systemd/systemd-sleep hibernate`. With /usr/lib/systemd/systemd-sleep there is no `User sessions remain unfrozen on explicit request ($SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=0).` in logs and the issue still happens. Workaround so far is to trigger the service directly, which uses the SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=0 workaround: `sudo systemctl start systemd-hibernate`. I believe (no extensive testing) power button-triggered actions are freezing the system as well on my system.