Suspend or hibernate on Framework laptop

User Support
1

OK, so I have read a multitude of suspend threads here on the forums, but I am gathering that the response is usually that the suspend ability depends on the hardware. The thing is, my hardware definitely suspends under Linux, and specifically suspends fine under Fedora 36, as my partner has the exact same hardware as I do in every way, but she runs Fedora 36 directly. All her hardware works perfectly (which I am very jealous of because Qubes has been a huge hardware challenge so far on the identical machine) including suspend and resume.

For me, Suspend doesn’t seem to fully sleep, as the keyboard glows, but its tough to tell as it simply never wakes up no matter what I do, so I can’t check battery drain. v I have seen other posts mention issues like this, but so far not a good solution that I have seen. Do any of you with Framework laptops on these forums have working suspend and resume?

Its almost necessary because my battery drains 25% by just running in my bag for 30 minutes without the suspend ability.

I do want to link here a post on a fedora-related site that may be relevant: Framework Laptop, Fedora 35, and Battery Drain in Bag (sleep/hibernate) - Ask Fedora
There, one of the posters suggests that the framework defaults to s2idle, which can be changed to use “deep” sleep with a kernel option. Honestly, I’d be mostly happy either way, as long as I could suspend and wake up from suspend.

2 Likes
2

I am not very knowledgeable here, but my guess would be that Fedora 36 has a much newer Linux kernel, whereas Qubes 4.1 has an older one in dom0.

3

Thanks for taking the time to suggest that. I am running “kernel-latest” in qubes, and I believe I have also successfully set that as the default for dom0 using the GUI provided under Qubes Settings. If there is an extra step I must take to make dom0 use it beyond the GUI, then I definitely have not done that, so let me know if that’s the case. But otherwise, perhaps there is a kernel option or other setting I have to change?

1 Like
4

Just as a note to others who run into this issue, I found a small section of documentation that talks about this issue (at the very bottom of that article) and a possible solution by adding
mem_sleep_default=deep kernel option to the GRUB config. Since I am new to Linux and don’t know how to do that, I used this discussion to help figure that out.

I will post back here with whether or not that worked!

5

OK, when I added that kernel option to my GRUB config, I then rebuilt my grub config: grub2-mkconfig -o /boot/grub2/grub.cfg. Finally, I ran sudo dracut -f to rebuild the initrd, as per that post. It threw me a suspicious error:

cat: /sys/power/resume: No such file or directory

Now, this sounds like it would make an issue resuming form suspend (which it the big issue I have), but oddly this Qubes forum post contains a reply from Qubes Team member @fepitre who suggests that the error may not be meaningful?

Regardless, I rebooted the system to try the new kernel options, and then suspended. The system did seem to go into suspend (perhaps a little deeper?) but I still cannot wake it up. I would love someone to weigh in who might understand what that dracut error means. In my digging for ideas, I did run into a github thread that sounds very relevant, but I am not quite yet savvy enough to fully understand where it leads.

I am working on it, and I like to solve it once and for all. Any help would be greatly appreciated by me, and also probably I imagine by a lot of Qubes users with suspend issues. It seems to be common on newer Intel hardware at least.

1 Like
6

Suspension is always a pain under Qubes.
Edit: Extra efforts are to be made to have suspend/resume with Qubes, on specific machines.

I found one issue about suspend, whose author’s machine had the same generation of CPU as yours. He seems to be getting stable suspend/resume now, so 11th gen Core should be able to resume properly.

However, Framework team is not Lenovo, and their EC and BIOS support might not be that good. If this were the case, you wouldn’t get suspend working before they worked it out.

What are the last messages in journal before you hard reset your PC? You can run sudo journalctl -b -1 -r in dom0.

7

This is not true, it depends on the hardware. See Community-recommended computers, which have reliable suspend. Suspend is flawless on my Librem 15.

8

OK, so strange development here: I was able to get into suspend (I think), for the first time. I still have the kernel option in GRUB so I assume that is why its working, though I wish I could confirm what Sleep state it was entering (S2idle or S3); how can one do that? And also I’d love to know why it suddenly worked…It’s weird because I did nothing else to the kernel options or other settings except my regular Qubes update as I always do.

I did run that command journalctl -b -1 -r and i found that the output is massive…2000+ lines in the terminal. Some errors that stand out are “Failed unmounting mount xenstore filesystem” and "

Sep 05 14:50:57 dom0 systemd-cryptsetup[32357]: Failed to deactivate: Device or resource busy
Sep 05 14:50:57 dom0 systemd-cryptsetup[32357]: Device luks-601932b6-caaf-431b-ae8e-ccf465f103c0 is still in use.

" I read through most of it, and I see that there were a boatload of socket.send() raised exception. Thrown, and then a bunch of errors like this

Sep 05 14:50:36 dom0 qmemman.systemstate[2172]: dom ‘13’ still hold more memory than have assigned (3756617728 > 3355499842)
Sep 05 14:50:36 dom0 qmemman.systemstate[2172]: Xen free = 4570311118 too small for satisfy assignments! assigned_but_unused=4706633030, domdict={‘0’: {'memory_cur>
Sep 05 14:50:36 dom0 qmemman.systemstate[2172]: Xen free = 4570311118 too small for satisfy assignments! assigned_but_unused=4706633030, domdict={‘0’: {'memory_cur>
Sep 05 14:50:36 dom0 qmemman.systemstate[2172]: Xen free = 4570311118 too small for satisfy assignments! assigned_but_unused=4723410246, domdict={‘0’: {'memory_cur>
Sep 05 14:50:36 dom0 qmemman.systemstate[2172]: dom ‘5’ didnt react to memory request (holds 4177592320, requested balloon down to 3825355124)
Sep 05 14:50:36 dom0 qmemman.systemstate[2172]: Xen free = 4570311118 too small for satisfy assignments! assigned_but_unused=4723410246, domdict={‘0’: {'memory_cur>
Sep 05 14:50:36 dom0 qmemman.systemstate[2172]: Xen free = 4570311118 too small for satisfy assignments! assigned_but_unused=4723410246, domdict={‘0’: {'memory_cur>
Sep 05 14:50:36 dom0 root[29568]: /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/8/51760

Or also this:

Sep 05 14:50:35 dom0 libvirtd[2208]: internal error: Unable to reset PCI device 0000:00:0d.3: internal error: Unable to reset PCI device 0000:00:0d.2: internal e>
Sep 05 14:50:35 dom0 libvirtd[2208]: internal error: Unable to reset PCI device 0000:00:0d.2: internal error: Unable to reset PCI device 0000:00:0d.0: internal e>
Sep 05 14:50:35 dom0 libvirtd[2208]: internal error: Unable to reset PCI device 0000:00:0d.0: internal error: Unable to reset PCI device 0000:00:14.0: no FLR, PM>
Sep 05 14:50:35 dom0 libvirtd[2208]: internal error: Unable to reset PCI device 0000:00:14.0: no FLR, PM reset or bus reset available

Most of the errors in the journalctl were related to KDE Plasma, definitely. A bunch of “BadDraw” and “BadWindow” errors, which makes sense because Plasma was not behaving nicely a lot today (first day trying it) but I assume that’s not related to the suspend. XFCE seems to suspend and resume much more happily and quickly than Plasma at the moment with this new power.

9

I would still love to check on the idle power state improvement if possible too, as my computer runs very hot and drains the battery fast most of the time even under light load (probably because it thinks it doubles as a space heater), and usually sounds like a jet engine under heavy load (which is of course somewhat expected). But making the power states more efficient would be wonderful.

Following up on your post in the other topic: I ran xenpm start 1 as you suggested here, and I get output for each processor core showing C0, C1, C2, C3, and then P0, P1…all the way to P15. In those sets, C0, C1, C2, P0, P14 and P15 have significant time listed.

And then later in the readout there is another section that says “Socket 0” and lists the 4 cores again, but this time they say CC

10

Those systemd-cryptsetup errors seem to be related to shutdown, which are nothing to worry about.

qmemman is the memory manager of all your VMs, and these errors seem to be reporting not enough RAM.

Unable to reset PCI device is likely to be sys-usb related. I see those too.

I wish I could confirm what Sleep state it was entering (S2idle or S3)

You may see in journal, entry suspend (deep) or entry suspend (s2idle). You might not need to inspect the last boot’s journal (which parameter -1 indicates), but also those where you had tried to suspend.

11

That sounds like the problem issue #4604 was trying to address. Since rebuilding Xen is demanding for a normal user, maybe switching from ondemand scaling governor to powersave will ease the overheat problem.

I don’t know if TLP can adjust CPU’s PL1 and PL2 under Xen. According to #4604, the truth is probably negative.

This is expected. C0 means your CPU is busy, and P0 means it’s running full-speed. P14/15 means it’s running at minimal speed, and C1/2 means your CPU is idle. You can get more info about those states, just run ‘xenpm get-cpufreq-para’ and `xenpm get-cpufreq-states’.

12

OK, so now that Deep sleep is technically working, I have run into an issue that I did not immediately notice. When I resume from suspend, dom0 seems fine, but any VMs that I had running on top tend to be stalled and do not come back to life. When I go to Qubes Manager to try to shut them down or restart them, they tend to turn the little green icon to yellow and they hang there unable to shutdown. So, the suspend partially works.

Does anyone have experience with resume? Is there something I need to do to tell the VMs to resume too? Or is there something else going on?

13

Yes, the issue is reported on several other topics.

14

And suspend seems to be fully working on Qubes 4.2.0 (R4.2)
At last.

That is for Framework 13, Intel i7-1165G7

1 Like
15

However, my audio output is not working with 4.2. I haven’t spent much time on it yet.

16

Did you upgrade to qubes 4.2 from 4.1? I had audio issues when I did that. I ended up simply downloading 4.2 and installing fresh, and then restoring backed-up qubes. Now my audio works properly. I did open a github issue for it, but so far still don’t know what happened: No sound playback devices available after in-place upgrade to 4.2 · Issue #8560 · QubesOS/qubes-issues · GitHub .

1 Like
17

Yes, @moonlitOrca
I upgraded from 4.1 to 4.2, and then had my audio fail.
Thanks for the suggestion. I’ll give it a try in a few days.

18

Thanks @moonlitOrca

And audio is back.

I backed up my qubes
installed 4.2.0
restored my qubes
Then opened my Debian template
sudo aptitude install pipewire-pulse
And all of my qubes which use that template have audio again

Next question:
Why did printers disappear?

19

I’d love a bit more guidance myself on the printer configuration. I once-upon-a-time, probably a year ago, set up my network printer and had that working, but it was not simple, and something ended up breaking it later. So I haven’t tried again and just print from a different PC… :frowning: But if anyone has simple printer configuration guidance, I’d over that.

Naturally CUPS only runs when specifically selected in Qubes Manager for a qube, so that’s step number one, but then what?