I run 4.2.4 (R4.2); since about a week my machine has an intermittent problem with wake up after suspend. After pressing power button screen remains black and the only option is a hard reset. Problem is intermittent - sometimes the system won’t wake up from 5 minutes suspend, but wakes up with no problem after being suspended overnight, other times - the opposite. It is rather frustrating, especially the randomness. Hardware (HP Zbook G7) is OK, even tested with windows (sleep, suspend etc.) - works fine. Haven’t made any changes after Qubes install. I’d very much appeciate any ideas.
Could be S0ix, which is an active issue on github and has many forum posts as well.
Thank You for the reply. If I understand this correctly, S0ix sleep support is an issue with TigerLake processors, but mine is 10th gen. Comet Lake. I specifically chose G7 and not G8 gen Zbook to avoid this. Also, after Qubes install everything worked fine, out of the box, for over a year - until now. I’m having a hard time understanding what has changed.
Same problem here on a Lenovo T480s. Been using Qubes on this machine for years, never had any issue. The problem seems to have started after upgrading some VMs to Fedora 41.
Example journalctl log output from dom0:
Aug 21 14:25:58 dom0 kernel: Command line: placeholder root=/dev/mapper/qubes_dom0-root ro rd.luks.uuid=luks-a0bd7a03-3dec-41bc-a990-95d559517682 rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap plymouth.ignore-se>
Aug 21 14:25:58 dom0 kernel: Linux version 6.12.39-1.qubes.fc37.x86_64 (mockbuild@94ca441b254845ddb3c4a039cbe3c554) (gcc (GCC) 12.3.1 20230508 (Red Hat 12.3.1-1), GNU ld version 2.38-27.fc37) #1 SMP PREEMPT_DYNAMIC T>
-- Boot 9a3751d65ef3450f944c11357f8a8527 --
Aug 21 14:02:10 dom0 kernel: PM: suspend entry (deep)
Aug 21 14:02:10 dom0 systemd-sleep[12736]: Entering sleep state 'suspend'...
Aug 21 14:02:10 dom0 systemd[1]: Starting systemd-suspend.service - System Suspend...
Aug 21 14:02:09 dom0 systemd[1]: Reached target sleep.target - Sleep.
Aug 21 14:02:09 dom0 systemd[1]: Finished qubes-suspend.service - Qubes suspend hooks.
Aug 21 14:02:09 dom0 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=qubes-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Aug 21 14:02:09 dom0 kernel: audit: type=1130 audit(1755784929.976:741): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=qubes-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? r>
Aug 21 14:02:09 dom0 52qubes-pause-vms[12689]: 0
Aug 21 14:02:05 dom0 qmemman.systemstate[1751]: dom '11' still hold more memory than have assigned (4144685056 > 4070031981)
Aug 21 14:02:05 dom0 qmemman.systemstate[1751]: dom '5' still hold more memory than have assigned (3813392384 > 3742355150)
Aug 21 14:02:04 dom0 libvirtd[1810]: Operation not supported: Domain '6' does not support suspend
Aug 21 14:02:01 dom0 systemd[1]: Starting qubes-suspend.service - Qubes suspend hooks...
Aug 21 14:02:01 dom0 systemd[1]: /usr/lib/systemd/system/qubes-suspend.service:9: Standard output type syslog is obsolete, automatically updating to journal. Please update your unit file, and consider removing the se>
Aug 21 14:02:01 dom0 systemd[1]: /usr/lib/systemd/system/qubes-suspend.service:9: Standard output type syslog is obsolete, automatically updating to journal. Please update your unit file, and consider removing the se>
Aug 21 14:02:01 dom0 systemd-logind[1752]: Suspending...
Looks like one VM does not support suspend, that could be a problem…
This happened again. I observed that the laptop “sleep light” was on, indicating the machine had successfully entered suspend. The lock-up is therefore probably happening when the machine tries to resume from suspend.
From the journalctl log above, as well as by inspecting the log from the most recent issue, it’s clear that no entries are saved to journalctl during the resume-from-suspend. This could be for either or both of two reasons:
- The system locks up before reaching a state where logs are written, and/or
- The hard reset needed to recover the system from the locked-up state wipes any logs that have been written during wake.