[TRACKING] High Battery Drain During Suspend

[mikeymop]

Hello, I was playing around with turbostat and the s0ix debugging tools provided on 01.org and noticed some failures when testing s2idle.

[  880.618452] PM: Suspending system (s2idle)
[  880.618455] printk: Suspending console(s) (use no_console_suspend to debug)
[  880.619538] wlp170s0: deauthenticating from 94:83:c4:1f:4d:62 by local choice (Reason: 3=DEAUTH_LEAVING)
[  881.200712] PM: suspend of devices complete after 581.211 msecs
[  881.200717] PM: start suspend of devices complete after 582.169 msecs
[  881.200720] PM: suspend devices took 0.582 seconds
[  881.215569] PM: late suspend of devices complete after 14.843 msecs
[  881.241747] ACPI: EC: interrupt blocked
[  881.308356] PM: noirq suspend of devices complete after 92.029 msecs
[  881.308393] ACPI: \_SB_.PR00: LPI: Device not power manageable
[  881.308398] ACPI: \_SB_.PR01: LPI: Device not power manageable
[  881.308400] ACPI: \_SB_.PR02: LPI: Device not power manageable
[  881.308402] ACPI: \_SB_.PR03: LPI: Device not power manageable
[  881.308403] ACPI: \_SB_.PR04: LPI: Device not power manageable
[  881.308405] ACPI: \_SB_.PR05: LPI: Device not power manageable
[  881.308406] ACPI: \_SB_.PR06: LPI: Device not power manageable
[  881.308407] ACPI: \_SB_.PR07: LPI: Device not power manageable
[  881.308413] ACPI: \_SB_.PC00.RP10.PXSX: LPI: Device not power manageable
[  881.308415] ACPI: \_SB_.PC00.HECI: LPI: Device not power manageable
[  881.308417] ACPI: \_SB_.PC00.PEG0.PEGP: LPI: Constraint not met; min power state:D3hot current power state:D0
[  881.308422] ACPI: \_SB_.PC00.GNA0: LPI: Device not power manageable
[  881.310108] PM: suspend-to-idle
[  893.693629] Timekeeping suspended for 11.610 seconds
[  893.693860] ACPI: PM: Wakeup unrelated to ACPI SCI
[  893.693863] PM: resume from suspend-to-idle
[  893.696003] ACPI: EC: interrupt unblocked
[  894.122699] PM: noirq resume of devices complete after 426.935 msecs
[  894.126365] PM: early resume of devices complete after 3.551 msecs
[  894.642587] PM: resume of devices complete after 516.134 msecs
[  894.651955] PM: resume devices took 0.525 seconds
[  894.651973] PM: Finishing wakeup.
[  894.651975] OOM killer enabled.
[  894.651976] Restarting tasks ... 

I am curious if these \_SB_.PR0x power management failures mean anything to anyone?
I am guessing these are platform features that are not suspending when the machine is put to sleep causing the suspend power drain.

[3by2]

This is kind of a joke. 1260p, hybrid sleep disabled, 2x USB C, 2x USB A

Why am I wasting hours of my life trying to diagnose this on such an expensive product? How is this acceptable on an enthusiast oriented machine?

[Second_Coming]

@3by2

This is kind of a joke. 1260p, hybrid sleep disabled, 2x USB C, 2x USB A

Why am I wasting hours of my life trying to diagnose this on such an expensive product? How is this acceptable on an enthusiast oriented machine?

Yup…I’ve been there with the frustration. All very good questions.

All I can say is: Some people here on the forum confused “enthusiast oriented machine” with “wanting to tinker”. In my book, the two are not one and the same.

[anarcat]

I’m doing a new run of benchmarks of the suspend time power usage here, using batterylog and my homegrown solution. Hopefully I should be able to corroborate or infirm other results people might have had here. So far I have found those results to be interesting:

@Nils

System on, locked and screen off, with HDMI & USB expansion cards: around 3W

s2idle sleep with USB-A and HDMI expansion cards: around 1.9 W

s2idle sleep with only USB-C expansion cards: around 0.8 W

deep sleep with USB-A and HDMI expansion cards: around 0.9 W

deep sleep with only USB-C expansion cards: around 0.4 W

@Nils

So I’d say the nvme.noacpi=1 has almost completely resolved the power drain: even with 1W, the machine can stay suspended for more than 2 days and without the HDMI and USB-A cards it’s an entirely decent score.

Also, reading this thread is kind of painful for two reasons. One, it’s kind of sad how much trouble everyone is having with their battery life. I get it, trust me, I’m in the same boat. But second, it’s kind of a shame it goes a little off the rails…

I don’t think it’s productive to beat the Framework Team over the head with this kind of stuff. They’re working on those issues, maybe not fast enough for your taste, but keep in mind this is a young startup, I don’t think it’s fair to expect them to produce a laptop that has the batter life of a Carbon X1…

Anyways, next up is results, I’m hoping to get something more solid some time this week. My assumptions are that, as usual, the expansion cards are the main culprit, that deep sleep saves a lot of power, and that nvme.noacpi=1 won’t have an effect on my laptop. Apparently, that setting might be specific to s2idle!

See also:

Linux battery life tuning

For folks who are seeing improvements in battery life during standby after setting the “nvme.noacpi=1” kernel parameter, could you share what SSD you are using and if possible, what version of firmware is running on it? We’ve worked with Western Digital and found that SN750 with 111110WD and older firmware needs that workaround, but updating to 111130WD and newer does not. Edit: Also, for folks who are not seeing improvements with “nvme.noacpi=1”, could you also share your SSD and the firmware…

Update: tests are not complete just yet, but first results are trickling in. So far I am confirming the results that the USB-A modules take almost half a watt on standby (500mW for the first, 370-380mW for the n+1), which is much worse than what they do on idle.

It seems like something kicks those cards into high gear on suspend, it’s quite bizarre. I’m going to run more tests to confirm this, with more USB-A cards. I’ll also run the tests with all the other cards I can lay my hands on, but it really seems like the main culprit right now in my fluctuations in suspend battery performance…

I’m actually considering creating a whole new thread specifically about expansion card battery use during suspend, since this one is becoming quite long…

[anarcat]

@Daouadi_Philippe

turbostat --show Pkg%pc2,Pkg%pc3,Pkg%pc6,Pkg%pc7,Pkg%pc8,Pkg%pc9,Pk%pc10,SYS%LPI rtcwake -m freeze -s 60

I’m a little confused as to how this works.

First off, here, -m freeze doesn’t enter a deep sleep state, at least not as power-saving as s2idle or deep anyways, so it’s normal you’re seeing bad results from this.

But more importantly, I don’t actually understand how or even if turbostat can give you power usage results at all. Normally, the CPU is basically stopped on deep suspend, you only deliver power to the memory to keep that alive, and then resume processing tasks in the CPU once the computer resumes from sleep.

How can turbostat tell anything that happened then? It’s basically suspended… or is it using some other tricks there?

@Daouadi_Philippe

There might be a bug in the bios or the card’s firmware itself. Where can we report this so that Framework’s staff can have a look at it?

Also, has anyone here actually tried to report this explicitly to the @Framework team?

What I’m seeing right now is major power drain issues with expansion cards, specifically on suspend. It seems like they enter a different power profile than when the computer is idle. So it could be something relatively simple to fix, since the difference really is between suspend and idle…

Anyways, once I get my actual results, I’ll open a new thread about this and cross-reference it here. I’m also considering just opening a formal support request to see if we can get this moving in the team as well.

[Daouadi_Philippe]

@anarcat

Also, has anyone here actually tried to report this explicitly to the @Framework team?

I did:

High Battery Drain During Suspend

Quick update from framework: We are working with our manufacturer and Intel on potential firmware changes that could improve the issue you’ve reported, but don’t have a specific timeline we can communicate at this time given the collaboration and work required. Let’s wait and see

[KiptonK]

Thanks to everyone doing detailed tests here. I just want to echo some findings with my 12th Gen and Debian Bookworm/Testing:

• The USB-A adapters are doing weird things in deep. Removing them doesn’t affect s2idle but they boost current draw in deep to about triple that of s2idle.
• For my build with a SN770 1TB, the nvme=noacpi parameter isn’t signifcant. s2idle and deep usage are pretty much unaffected by setting/unsetting.

[anarcat]

Finally finished my benchmarks here and posted the results in a new topic:

Expansion card standby battery usage tests results

After first testing each expansion card’s power usage at runtime — part of my in-depth review — I have finally gone around doing a similar set of tests on standby. Here is a summary of those results. Device Wattage Amperage Days Note baseline 0.25W 16mA 9 sleep=deep nvme.noacpi=1 s2idle 0.29W 18.9mA ~7 sleep=s2idle nvme.noacpi=1 normal nvme 0.31W 20mA ~7 sleep=s2idle without nvme.noacpi=1 1 USB-C 0.23W 15mA ~10 2 USB-C 0.23W 14.9mA same as above 1 USB-A 0.75W 48.7mA 3 +500…

[Jason_Dagless]

Guys, pure ON or OFF is the way forward.

[Xenophon]

I’ve just run into this issue.

Laptop at about 55% battery, put it into suspend, no power overnight to the apartment, next morning - laptop had shut down of out power.

One USB A stick inserted, one USB mouse.

I’ve noticed when running on battery that having the mouse or the USB stick inserted (I’ve not checked with both) adds something like 4w of battery drain. Having scanned briefly through this thread, I see comments about USB A devices commanding considerable power drain, and indeed, if one or both devices was still drawing power during suspend, that would most certainly account for the shut down overnight.

[Kimo_Bonnelycke]

I have been having sleep issues with my frame work since I purchased it (batch 5 or 6) and finally decided to do some testing. I started with a fresh W11 load, installed latest drivers (also on 3.17 bios for my 11th gen i5) and enabled S3 sleep (s0 disabled). I put my W11 system to sleep with 60% battery (set via bios as max) at approx 8pm. The following day at 2pm, I woke the system, logged in and the battery was down to 9%. Obviously s3 sleep, for me, isn’t actually working. Unfortunately, if I have to full shutdown every time just to keep my battery from draining when not in use, then it is time for me to switch to some other system that actually works in this manner. Honestly I don’t really know if this is a Windows 11 issue, a framework laptop issue, or a combination of both. I have used S3 for years on my W7, W10 laptops and never had this much of a battery drain. I guess I could switch to W10 on my framework and test it as well.

[Nils]

My impression was that the new Windows approach is to suspend-then-hibernate, which should do S0 until your battery has dropped 5% and then hibernate to disk, after which your laptop is actually off.

On Linux it looks like the power usage under S2idle (ACPI S0 if I’m not mistaken) can, with a bit of tweaking, get you to a 2-day lifetime or so; but it depends a bit on your setup (NVME and expansion cards) what base level you can actually attain. “deep” (ACPI S3, I think) doesn’t actually seem to get you that much better.

Windows going the suspend-then-hibernate route is definitely going to affect how much optimization chip set developers are going to put into getting decent performance from S3, so it is quite conceivable that modern hardware performs significantly worse under S3 than older hardware does.

Framework’s 55Wh battery is definitely on the small side and it’s pretty clear by now that it’s not the best-tuned in its class for power efficiency, but the figures people have been able to get are not too far off from middle-of-the-pack performance either.

[Kimo_Bonnelycke]

Here is the output from powercfg sleepstudy. Doesn’t seem to explain why the drain, just that it exited from standby with 5205 mWh remaining (9%).

System Power State: Standby

	START TIME	DURATION	STATE	ENTRY REASON	EXIT REASON	% CAPACITY REMAINING AT START
21	2023-01-15 15:22:26	21:25:48	Standby	Application API	Unknown	61%

- Detailed Session Information

- Battery Information

Remaining Charge Capacity At Entry [mWh]		33634
Full Charge Capacity At Entry [mWh]		55009
Remaining Charge Capacity At Exit [mWh]		5205
Full Charge Capacity At Exit [mWh]		54901

- System Event Log

TargetState		4
EffectiveState		4
ProgrammedWakeTimeAc		62048-31687-00T55041
WakeRequesterTypeAc		0
ProgrammedWakeTimeDc		62048-31687-00T55041
WakeRequesterTypeDc		0

[Nils]

Yes, that’s a decrease of 28.4Wh over 21.5 hours, so that’s in the 1.3 W range. That’s in the upper regions of Test results for standby battery use of Expansion Cards (on linux). If you have non-USB-C expansion cards plugged into your system you can probably significantly improve performance by unplugging them, but 0.8 W is about the best people have reported so you shouldn’t expect to do much better than that.

[Matt_Hartley]

Appreciate everyone here sharing their findings. Doing testing on our end (new testing) and will have results here in the not too distant future. Thanks everyone.

[Kimo_Bonnelycke]

Thanks Nils, that is a bummer to hear, esp. needing to remove my usb-a cards to try and get more life out of sleep.

Matt, I am certainly looking forward to hearing if there is anything that can be done. (Other than doing a full shutdown to save ones battery when not plugged in.)

[Nils]

@Kimo_Bonnelycke

Thanks Nils, that is a bummer to hear, esp. needing to remove my usb-a cards to try and get more life out of sleep.

Have you given window’s default suspend-then-hibernate a try? On my surface tablet that works just fine (I’ve never changed it from the default): if I leave it unplugged for more than half a day, it will display the “windows” symbol when I open it up but within a few seconds it’s up and running.
I don’t use windows on the framework laptop, so your mileage may vary there.

[Kimo_Bonnelycke]

@Nils

Have you given window’s default suspend-then-hibernate a try? On my surface tablet that works just fine (I’ve never changed it from the default): if I leave it unplugged for more than half a day, it will display the “windows” symbol when I open it up but within a few seconds it’s up and running.
I don’t use windows on the framework laptop, so your mileage may vary there.

I did a reinstall, and started using the suspend to hibernate, and that does seem to help a lot.

[Sean_Mullen]

I recently purchased a Framework laptop for Linux, running Ubuntu 22.10, and have been experiencing the battery drain when closing the lid and the laptop is not plugged in overnight. I do like the laptop but this is a dealbreaker for me as I can’t afford to pick up the laptop to head out the door for some work and find that the battery is drained.

I saw on another forum that there is a BIOS update (3.10) for the 11th Gen Intel that fixes this issue, but that there is no BIOS update for the 12th Gen. Is that the case? Is there any other fix for the 12th Gen running Linux?

(Update: I don’t have a USB-A expansion card, but I do have an HDMI expansion card which others report being the/a culprit. I’ll try without it, though having to remember to unplug in/plug in back in every time is not optimal. I also have an Ethernet expansion card and 2x USB-C cards)

[Adrien_Rey-Jarthon]

For the record I forked a new thread about the specific problem I reported here: s2idle sleep usually drawing a normal ~1w but SOMETIMES drawing up to 7w and getting the laptop very hot. Here it is: Linux s2idle sleep "random" power usage increase

This way we can gather data and solutions about this problem more specifically and avoid mixing it with the issue of baseline sleep power draw in this thread.
@Nils @Cecile I believe you were among those who experienced this too so feel free to join the discussion with any additional data you have. And if there are other people impacted too of course.