I wonder how many people are actually not aware of the sub-par out-of-the-box behavior under Linux because they use their devices differently, so they don’t run into these things - at least not right away.
For me deep sleep is not working anymore with 3.20 on Archlinux.
Batch 9
Intel i7-1165G7
AX210 WiFi
WD_BLACK™ SN850 NVMe™ - M.2 2230 - 1TB
DDR4-3200 - 16GB (2 x 8GB)
4 x USB-C
It’s a bit of a joke, that the community needs to debug this instead of their own QA, but deep sleep is no longer working for me either after the 3.20 update on Ubuntu:
Batch 9
11th Gen Intel® Core™ i7-1165G7
AX210 WiFi
WDS100T1X0E-00AFY0 (614600WD) NVMe
2x 16GB CT16G4SFRA32A
2x USB-C + 2x USB-A
@anon81945988 I recommend you read a bit through the following to understand the differences in the possible suspend modes. This should make things clearer.
https://wiki.archlinux.org/title/Power_management/Suspend_and_hibernate
There is s2idle (S0) and there is deep (S3). You can find out what your system is doing via the command:
cat /sys/power/mem_sleep
I expect it to be s2idle in your case and you can try to change it to deep and see if you’re affected as well.
The point here is that S3 is the better mode to use to reduce battery drain as S3 puts most components to sleep compared to S0 - which at least on framework laptops is not nearly as good as stated in other places. Also the reason why you Ubuntu ate 28% of the battery while in suspend.
The best writeup on the battery consumption on framework laptops I have found so far is the following blog. This is for the 12th gen though, but gives you an idea of what kind of skillset you require to dig into the mess that is suspend modes in Linux in general and in combination with Intel CPU in particular.
https://anarc.at/hardware/laptop/framework-12th-gen/
I stand corrected. There seems to be also an issue with AMD based frameworks.
https://c.mirifique.ch/2024/10/30/power-management-and-archlinux-for-the-framework-13-amd-laptop/
The difference is less pronounced than you might expect to see: [TRACKING] High Battery Drain During Suspend - #10 by Nils
and the followup: [TRACKING] High Battery Drain During Suspend - #48 by Nils
s2idle sleep with only USB-C expansion cards: around 0.8 W
deep sleep with only USB-C expansion cards: around 0.4 W
Maybe I’m interpreting the data differently…but that’s a 100% increase going from deep to s2idle.
at the follow-up, the number is much better. The difference, at least in that configuration, is almost completely resolved by nvme.noacpi=1
Ah…Got it. Thank you.
I’m testing that out now, in Linux. (On Windows, I got 0.32-0.33w like you did. So I guess that’s as good as it’s going to get in Linux)
Does anyone other than me have an 11th gen system that is on bios 3.20 and works fine with deep sleep and suspend? If you’re not on 3.20 and rely on deep sleep, please don’t dive in to test as you run the risk of losing that functionality. I am trying to understand why my machines work but others don’t. Both of them have the RTC replacement module installed.
I have only tested it on linux, but I will boot up windows (I think I have win 10, not 11 on those machines/the expansion cards for them) and add a post with the outcome.
Possibly, but we definitely have people running into the issue on linux as well.
I’m on an 11th gen FW13 and the 3.19 BIOS, just tried s2idle with four USB-C cards and the nvme.noacpi=1
option, and I calculate around 0.7 W/h consumed during suspend over the last three hours or so. I’ll try a more scientifical calculation overnight, but that’s about double what you reported. Have any tips?
11th gen, 3.20, Ubuntu 24.04.1 LTS, s2idle, 4 x USB-C…suspended for 8 hours and 15 minutes, depleted 8.1Wh. So burning at just under 1W.
I did not set the nvme.noacpi=1 option…Don’t see that from the Framework guides. There’s this where @Matt_Hartley mentioned the nvme.noacpi=1 hasn’t been required for quite sometime now: Ubuntu 24.04 on the Framework Laptop 13 - #36 by Matt_Hartley
Update with additional details:
Memory: 2 x 32GB (HX432S20IBK2/64)
SSD: Adata SX8200 1TB
Due to differences in configuration (memory brand and amount, brand of SSD) I suspect there will be differences in base line power use. I image it will depend on the type of SSD if the nvme.noacpi=1
option makes a difference. I haven’t tested for a while. I might try and see what results I presently get with 3.20 BIOS and fedora 40.
I don’t have those. I only have the original RTC battery. Maybe it is worth checking on the voltage and put a fresh one in or request that module from framework.
Good point, I’m updating the post above your with the additional details.
I’m now going to do a sleep test in Windows 11, again. See if there’s any changes now (vs when it was on BIOS 3.19).
By just taking the battery charge readings before and after s2idle sleep, I recently measured:
0.4 W with just USB-C and 0.93W with an HDMI and a USBA expansion card. This is for an 11th gen i7 with 16Gb memory. The laptop is running fedora 40 and I have TLP activated (and PowerProfile disabled). So it looks like nothing much has changed in terms of the software support and the expansion cards still take a very significant toll. It is a power use where on a 55Wh battery the laptop can survive for about 2 days in suspended state at a minimum. If you’re used to having the laptop plugged in frequently, that is quite workable.
What are you thinking about the nvme.noacpi=1 argument now? I saw a while back that it was taken out of Framework’s Fedora installation guide, along with the recommendation to use TLP, and somewhere Kieran (I think) said it hasn’t been necessary for a long time.
However, when nvme.noacpi=1 was first recommended in 2022, nrp said that it shouldn’t be necessary if we had the latest SN750 firmware, yet I was still measuring a significant difference despite having that latest firmware.
What are you thinking about the nvme.noacpi=1 argument now?
Nothing. I put it there originally when it had an enormous effect and haven’t had a reason to remove it. As far as I know, the SN730 hasn’t received firmware updates from what I received it with.