Thanks for the feedback. My recommendations are just that, recommendations of what we recommend at this time. Not full stop solutions.
Yes, there are definitely trade offs here. However, there are those who use hibernation quite happily despite the trade offs. Whether or not a user opts to use hibernation will depend on any concerns or company policies that have security concerns with it. While it is difficult to do in TPM, there have been customers here who have managed it.
For me, it’s only done on unencrypted scenarios. My encrypted machines are not using hibernation - I simply plug them into power when I put them into suspend of an evening. Not ideal, but it’s what I do personally.
Regarding long term battery life improvement, I can tell you that we are actively, very actively working on this. We appreciate your continued patience.
Out of curiosity–and I apologize if this is covered elsewhere, searching the forums for this topic is tough–have you experienced your machine spontaneously waking up on its own immediately after hibernating and shutting down?
The pattern I observe, consistently, is that I hibernate the device. It shuts down. Then immediately powers on. When grub appears I hit the power button to shut off the machine. Then it spontaneously powers up again. I hit the power button a second time. And then it shuts down for good.
All USB devices have been disabled for wakeup. I don’t have WoL enabled. I don’t have the “power on when you plug the device in” setting enabled in the BIOS.
This happens if I trigger hibernation with systemctl or via Gnome (after adding an extension to make hibernation available in the power menu).
It’s honestly a bit mystifying.
Am I the only one who’s reported this? Any suggestions for how to troubleshoot? Nothing in the kernel dmesg indicates what’s going on, and the last time I checked, the result of dmidecode said the wakeup was from the power button being pressed (which is definitely not true).
Also, I can certainly fire up a new thread if this is off topic.
On Linux Suspend vs Hibernation are different. We refer to suspend as suspending to RAM in a lower power state. Hibernation is to disk, where the computer powers off, but saves the state. Then pressing the power button brings back the state from the disk, as if in a really, really deep sleep.
Tod find things that are waking up your suspend state, running this to take a look at the suspend logs can be helpful - 99% of the time it’s software that’s open.
journalctl | grep "suspend"
dmidecode is good, but it lacks context.
You can also test this out further by testing suspend with all applications closed, nothing attached (USB).
I am hibernating my laptop to disk. Not suspending it.
And yes, rather than the laptop simply shutting down, it appears to power down then immediately power back up and begin the normal POST and boot cycle. How do I know? Because the laptop boots into the bootloader (i.e. grub in this case), which would not happen on a normal wake from suspend.
It sounds like it’s not actually going into hibernation at all, when you say ‘I hibernate the device. It shuts down’ that is odd to me because hibernation doesn’t look like shutting down, it just looks like the screen turning off and power button light turning off a short while later.
When I first tried to set up hibernation, something similar happened to what you’re describing, in that it looked more like shutting down. I looked over everything again and it turned out I’d just put the wrong UUID in my grub settings or something.
So maybe just go through the whole process of setting up hibernate or suspend-to-hibernate again making extra certain you’ve put the right UUIDs in and everything? Sorry I’m not very techy so this isn’t detailed advice but might help.
The past few days, I’ve been experimenting with adding and removing two USB-A cards and switching between s2idle and deep sleep. I’m on a Framework 13 11th gen, 64 GB of RAM, BIOS 3.17, Fedora 37. I’ve been noting sleep and wake times and checking the battery percentage in the task bar. I added the nvme.noacpi=1 option at boot, dragged KDE’s “Power Profile” to “Power Save”, did nothing else to modify battery usage.
Roughly, assuming percentages are correct and my battery’s 55 Wh,
deep sleep with USB-A drains around 3.3% battery / hour, or 1.8 watts
deep sleep without USB-A drains around 0.95% battery / hour, or 0.5 watts
s2idle sleep with USB-A drains 1.8% battery / hour, or about 1 watt
s2idle sleep without USB-A drains 1.6% battery / hour, or 0.9 watts
With USB-A cards plugged in, I get lower power usage while sleeping with s2idle selected than with deep.
If I could somehow get around 0.5 watts/hour or less battery drain while in s2idle (it’s nice having the laptop come back up without a delay), or get maybe half that with deep sleep, leaving the USB-A ports in, I’d be pretty happy. Even 1% per hour is a noticeable loss overnight, nevermind if you leave your laptop the better part of a 24 hour period.
Recently i got email from frame.work that there is new firmware released for DP modules and there are new HDMI modules in production with fixed powerdrain. Does it mean that this issues with powerdrain in sleep should be solved by that?
The tools I was using were KDE’s default battery indicator in the system tray and post-it notes
Those wattages are estimated averages, based on the battery percentage changes over time while I left the laptop asleep, usually for an 8ish hour period. Could be a ways off, since I’m assuming the percentages are right and I’m assuming 1% of the battery == 0.55 Wh, but I’d expect them to be representative relative to each other.
I could attempt a more rigorous approach if that’s useful, cycle the battery first to maybe calibrate it, invoke a tool or a script.
Yeah, thanks. I might’ve overlooked the Windows thread… mainly was posting just to gently pile on and help this issue remain recognized as definitely still present and relevant. Over the course of months (for sure years), it’s very easy for intractable problems to slide farther and farther from the center of focus. It does sound like these issues can be addressed, albeit with difficulty.
That and I didn’t think a little repetition about USB-A cards in particular would hurt, vs. HDMI and DisplayPort, which I think have been worked around already. (And the s2idle thing is just weird, thought maybe I’d overlooked something there.)
Has anyone noticed an improvement here recently? I’m using Archlinux with kernel version 6.3.1 and the s2idle sleep mode. All four of my USB modules are USB-C. It’s otherwise an OG Framework with a i7-1165G7 CPU. I haven’t done any firmware upgrades in a while. My BIOS version is 03.07.
I haven’t done any careful measurements yet, but it seems like suspending uses a lot less battery than it was previously just a few weeks ago. (Probably before a kernel upgrade.) I left it unplugged for several hours today. When I went back to it, I realized what I had done and figured my battery would be at 50-60%. But it was still at 98%.
I’ll try another more careful experiment tonight and see what happens. But I was just curious to see if anyone else noticed any improvements and what might have changed.
Yes, things have improved. I just redid some measurements and the situation is indeed better than a year ago:
Unfortunately, USB-A and HDMI cards still force a significant drain compared to just USB-C (I think @nrp thought BIOS 3.17 should have improved the USB-A situation, but I did not see that reflected in my test), but that should not be an issue for you.
Hah, well, I’d prefer to have my HDMI and USB-A modules in (with 2 USB-C modules), but I swapped them out precisely because of this issue. But assuming things got substantially better, I’ll take the win with 4 USB-C modules.
Well, bummer, my test seems to suggest that things are still not so great. I left my laptop in s2idle for about 11.5 hours last night. It was at 100% when I left it. When I opened it this morning, it was at 8%. So the battery drained approximately 8% per hour. Which is… just awful. I had 4 USB-C modules connected. And I did update the BIOS to 03.17 before running the test.
Just a reminder - deep over s2idle and removing unused expansion cards makes a difference. I usually have two used on my own laptops at once unless I am connected to a ton of stuff. And even then I am connected to power at that point because I am already anchored to external displays.
We’re also actively working to minimize power drain on DP and HDMI as well.
Measurements posted indicate that the difference between deep and s2idle is minimal, though, and possibly within the margin of error. Are you basing your reminder on specific hardware configurations where the difference is significant?
My main motivation to retest was to verify the claim that the USB-A problems had been ameliorated: Passifying the USB-A Card - #30 by nrp . While s2idle performance across the board does seem to have improved, it seems the “penalty” for having a USB-A plugged in hasn’t changed. This makes me think the improvements are due to improvements in the hardware support in the Linux kernel; not in the firmware updates.
Indeed. I used to use deep because it didn’t drain power as quickly (as I recall it). But it takes about 10 seconds to resume after I open my lid. For my usage patterns, I’d rather faster power drain than have to wait that long every time I open the lid.
When I did my test above, I had nothing except the power coord plugged into the laptop. The other 3 ports were just USB-C modules. Are you saying I should take those modules out too to improve power drain? As in, don’t have any modules except for the one used for charging plugged in?
