[TRACKING] Suspend on linux drains a lot of battery compared to other laptop

The MicroSD card for whatever reason draws a lot of power. You might try your test again with it removed. The USB-A is lower, but still a small draw.

Regarding suspend-then-hibernate, I will have to revisit the steps that I took. My recollection is that it involves first setting the system up so that hibernate is an option. Once that has been done, then one needs to enable the setting in a config file and set the time before hibernate in another. I am on Manjaro now, so the config files may be slightly different than Debian.

This thread has very complete measurements on power use during “normal power on”, s2idle, and deep:

The expansion cards have a non-negligible power use during s2idle/deep.

For your measuring accuracy: I wouldn’t go with “estimated time till drained”, since that involves a highly variable estimate of power use-while-on. I think you’ll get more reliable results by querying the estimated charge of the battery (in mAh or in W). It’s not perfect either, but the runtime estimate is based on it, so you’'ll get more stable results.


May be I’m quite naive but if I would design a suspend mode I would switch of all extensions if nothing is plugged in. I admit I need the MicroSD card extremely rarely (would love to have a normal SD card extension) but simply leaving the slot empty to save battery seems to be quite strange.

@Andreas_Tille - found the files.

In /etc/systemd/logind.conf I have the following relevant lines:


In /etc/systemd/sleep.conf I have these relevant lines:


The AllowSuspendThenHibernate line is commented out but that is the default so it is fine.

I hope that this helps.


Here in lies the rub. To the laptop, there is something plugged in, the expansion card. Plus I don’t think USB autosuspend is enabled by default on Linux but you can enable it.

Hello @Andreas_Tille best tip I have for you is to make this file etc/udev/rules.d/10-runtime-pm.rules as mentioned in a solution to this question over at serverfault
This one solution basically corrects mostly all the “bad” errors powertop will show.

Additionally, I have configured power profile daemon to stay on power save while on battery, it gives me an hour or so of extra battery time.

Hi @Matt_Hartley looking forward to your guides on this.

1 Like

Hi @Lamy and @Andreas_Tille,

Lamy, that’s a tough one to give a specific figure. But I can share the following.

First off, @Cipher’s tip is absolutely correct and while a bit more hands on, works great.

For a more “do it for me” approach, install TLP with its defaults is “pretty good.”

My rationale for recommending TLP first is that it doesn’t really do anything drastic that might create unintended behavior.

Short version: If your focus is taking care of those tunables, Cipher’s recommendation is absolutely the way to go. If you are “okay” with one or two of them being bad, default TLP is also fine.

Anything pulling power is going to be a consideration. Modules connected for DisplayPort, HDMI, etc. PowerTOP can give you it’s best guess estimates for sure. But even after running calibration, PowerTOP isn’t going to be exact. It will fluctuate.

True. 32G is sufficient for me, so my recovery time is faster.

1 Like

@Matt_Hartley I can understand that its impossible to give exact values due to many variables, but a rough estimate, like for e.g.

0.5% to 1% battery discharge rate per hour in sleep (not hibernation and not a hybrid sleep, a true sleep state).

Can you give a rough estimate? A rough idea. Does Intel provides this information?

@Lamy It’s tough. I’m brand new, so I have not had time to do any proper benchmarking…yet.

The best thing to do until I have time to really dial this:

  • Make sure you’re using the latest available firmware.
  • Some expansion modules will use more power than others.
  • Early testing has me on Fedora 37, latest kernel, YT video on a loop. No touchpad interaction with PowerTOP open is looking to be 3-5 hours, likely will hit 4 hours with YT playing the entire time.
  • My daily use sees about 4-6 hours depending how much I use.

To get really dialed in information on discharge rates, please use this command in the terminal for discharge rates:

upower -i /org/freedesktop/UPower/devices/battery_BAT0

Hopefully this helps.

1 Like

@Matt_Hartley I have an idea.

Yesterday night I had put my Ubuntu 22.04 in sleep and went to bed. Today morning, I could boot only after charging the battery for at least a minute and saw that the battery was at 2%. Clearly the battery has completely discharged overnight in a span of about 8 hours.


We have 2 LEDs on our laptop. One is used while the laptop is charging from its 2 USB C ports. May be one could have a setting in the bios, that when enabled can use another LED to glow continuously if the rate of discharge of battery is beyond certain percentage say 5%. And may be both LEDs can glow when the laptop is not being charged at all!

So, if I suspend my laptop and see that the LED is glowing I would know that something is wrong and I would do the shutdown.


Two things occur to me.

  • First, this is a very cool idea and I will pass this along. No idea what this would look like specifically, but the idea has merit.

  • I need to get to work on a hibernation how-to because suspend isn’t going to be ideal for all use case scenarios. Myself, I rarely suspend more than a lunch break. But I definitely get the need.

1 Like

@Matt_Hartley My old ASUS Laptop had one LED blink once every minute when in sleep. It used to only not beep while the laptop was on, or hibernated or shut down.

1 Like

@lbkNhubert Thanks to the hints in this thread my laptop does now way better. Thanks a lot to all who provided helpful suggestions. The only thing I did not got working is the suspend-then-hibernate method. I did as suggested

In /etc/systemd/logind.conf I have the following relevant lines:


In /etc/systemd/sleep.conf I’ve set only 3hours which makes sense for me:


Unfortunately the laptop does not switch to hibernate (neither the framework not the other laptop where I wanted to configure this.
Anything I might have forgotten?
Kind regards, Andreas.

@Andreas_Tille see the post I just made and check your version of systemd

1 Like

@Matt_Hartley Bios 3.05

Nov 21 17:43:54 lamy systemd-sleep[3345771]: Entering sleep state 'suspend'...
Nov 21 20:49:34 lamy systemd-sleep[3345771]: System returned from sleep state.

3 hrs sleep, battery discharged 33%

Thanks for the update. Early testing thus far on my end:

Note, because attaching anything is naturally a potential power draw if it fails to suspend with the laptop, this was done as a suspended laptop Framework laptop only. No applications loaded, next round will be with Chrome open and then suspended.

  • Ubuntu 22.10 on 12th gen, overnight lid close suspend with a 90% charge, late afternoon following day, 80% - this isn’t bad. kernel, s2idle is deep. Wi-Fi had question mark reconnect, shows question mark, but INTERNET IS WORKING.

  • Ubuntu 22.04 on 12th gen, overnight lid close suspend with a 90% charge, late afternoon following day, 80% - this isn’t bad. kernel, s2idle is deep. Wi-Fi displays normal and also connects fine.

Next will be Fedora 37 testing.

In the meantime, please feel free to open a ticket and they’ll ask you to follow a specific set of guidelines to gather specific logs. This will allow me to better see what is happening at tier 3 support.


At what power state is the drain being measured? S0ix, S1, S2 or S3? “deep” is supposed to be S3, is that state actually being reached?

@Matt_Hartley - what expansion cards do you have in the system during the test?

@lbkNhubert I wasn’t not happy with the early tests, going to re-do them with matching cards as much as I have available (multiple laptops). Saw something with Fedora 37 that had me go “hmmm”, so I want to re-run this in a more consistent way.

Going to update this tomorrow after re-testing accordingly:

Pop OS 22.04, Ubuntu 22.04 and Fedora 37.

TLP on Ubuntu and Fedora, system76-power on Pop OS.

I will update as I have further details.