HI @Tim_Sawicki,
Here’s a bit of background on the cards and changes made to those expansion cards that saw a refresh.
2 Likes
Thanks @Matt_Hartley , appreciate you sharing =)
Are there any updates on this issue? As someone who travels a lot, this is becoming more and more of a nuisance and seems like a very important issue to fix (I think most people expect something like this to work OOB without work-arounds that don’t really provide the same functionality).
Hoping it has high criticality. Even finding/making a safe combo of expansion cards would be a good start.
I can only speak to Linux, Ubuntu 22.04 and Fedora 38 specifically. So I’ll assume you’re using this as well.
I will only speak to Intel products as that is what is out right now.
13th gen does well in daily usage. Ubuntu and Fedora, using our battery optimization guide, you will see pretty solid battery life. For ticket and forum work, I get through my shifts no problem. Video, obviously, will drain the battery faster.
I have not had the cycles to do fresh battery drain testing in 13th Gen Intel, but the improvements with the expansion cards have helped.
Myself, personally, I have never, ever put a laptop into suspend overnight not connected to power (unless I was doing testing) as it never made sense for my own use case.
Once we get settled down a bit, I will be doing fresh battery drain testing with suspend, but overall with my current workload it’s very low on the list at the moment. Not due to importance, rather available cycles.
Ah, I am running Fedora 38.
I hear you here, but I can think of a lot of examples where you wouldn’t be suspending it connected to power, or overnight even.
I have had several cases where I’m, say, in an airport with airplane mode on and no external devices connected (including Bluetooth), close the laptop and put it in my bag to hop on the plane, only to pull out the laptop an hour later with it basically on fire, fans blasting, and 40-50% drained.
Same with people who bring it to work to throw it into their bag to travel to/from. If you aren’t aware of this issue, you can totally cook your laptop on accident.
It also does not do it consistently. I have tried manually clicking suspend before closing the lid, just closing the lid, connected to power or just battery, airplane mode or normal. Sometimes it actually suspends correctly and remains cool to the touch, sometimes it doesn’t and does what I describe above. I might as well just shut it off cuz it’s such a dice-roll and I’m worried about damaging my laptop.
It could be this is related to some random power settings and something is actually waking it up somehow during suspend? But it seems to me potentially related to what people are describing here and in an enclosed space it also will kick the fans on as heat builds, draining even more power (though is that possible in suspend?).
It might be good to try and see what the actual problem is because right now I don’t know if this general issue is some sort of issue during actual suspend where it’s somehow drawing too much power, or related to the laptop somehow waking during suspend, whether that be a power setting or otherwise, or not suspending correctly at all to begin with, somehow?
3 Likes
IMO the different distros ultimately just lead to different ways of configuring kernel settings.
While there is plenty benefit to have up-to-date documentation on how to configure the settings correctly for the major distributions, I would much rather see a check-script that tests the kernel settings (depending on hardware generation [obviously]) if they match best practices.
For anyone struggling with the power settings, I hope this provides more inside into the question which changes might help.
@Tim_Sawicki that’s the issue I forked into this topic and investigated in more details: [RESPONDED] Linux s2idle sleep "random" power usage increase
From what I noticed in my testing, the OS is not considered “resumed” as in the s2idle logs we can see the OS doesn’t print anything and only print the resume lime when resuming the laptop, no matter if it’s running hot (~7w) or cold (<=1w).
I also do consider this a dangerous and critical bug and not just a “nice to have” power saving feature, but gave up on hopping a fix, especially now that newer motherboards have been released and interest for mine (11th gen) has already fall. If the exact same problem is encountered on 13th gen maybe that’ll bring up the interest a bit for them.
2 Likes
This is the part I don’t understand…why not just shut it down. It takes almost as long to boot as it does to come out of suspend these days, so why continue using something that regularly breaks. Sure walking from one floor to the next, leaving the office for a meeting nearby i.e. carrying the laptop in hand…but closing it up and stuffing it in a bag…just shut it down. Not only safer, but also definitively more secure.
On FDE (full disk encryption), I’m not sure this plays well when you have to connect key devices and/or enter decryption keys etc on every cold boot.
In that sense hibernation makes much more sense.
I personally won’t be purchasing Framework until s2idle is figured out, so keeping an eye out here with great interest.
I use FDE and have no problems with entering my decrytpion key on every cold boot. Will never use a yubikey or similar device, so no problem there.
I really don’t think hibernation or suspend has ever really made sense, convenient, easy to use, and ultimately a maintenance pain and a security hole.
I’m experiencing this problem with 13th gen, so this is definitely still relevant!
1 Like
Not to be dismissive here, but your opinion around whether suspend is a good idea or whether cold boots are fast enough these days for your use case is not relevant to the discussion. Suspend is used by every laptop by default. People expect it to work.
Right now, at best it works as intended, if you’re lucky it only hilariously drains your battery if it’s in a well-ventilated location, and at worst you cook your laptop.
It frankly is just a bad look in general when Framework is already fighting other battery draining issues. This should be a priority issue that should not just be left to “oh, the user will figure it out”.
4 Likes
Are you actually sure about that…I think you should read up a bit. A lot of distros have to be configured during or after install to even use suspend.
So if it risks a catastophic meltdown…why would you then use it.
Except s2idle is not a Framework issue but an issue created by Intel. This is an issue that occurs across manufacturers, across a wide variety of linux distros, so saying it is a bad look for Framework is kind of harsh when the issue is really between the kernel and how Intel changed its sleep states. If we look historically hibernate, and suspend have always a hit or miss item that required user intervention to “fix” for a time. So really I don’t see how Framework making it a “Piriority” is going to fix something that has historically been an issue, and was made a bigger issue in the last three years by a manufacturer making changes to how the cpu handles it.
3 Likes
Admittedly I am not familiar with every distro, so you may be right here. That being said, any of the popular distros I’ve used, and certainly the ones officially supported by Framework, this is the default behavior afaik.
Mostly to see if I could debug what causes it. At this point, no luck…which might relate to your later point.
If this is true, which I also considered this possibility, then you are correct that it’s not just on Framework and it’s unfair to blame it on them. I have personally not run into this with my 11th gen XPS, but there are a lot of variables at play obviously, and a sample size of 2 is useless lol.
If this is the case, Framework should mention this then? This thread has existed far too long if this is just ultimately a kernel/Intel issue (not to say there isn’t something on Frameworks end still, but from your experience it sounds more unlikely). I assumed since it persisted that it was a quiet acknowledgement that there is indeed likely a problem from their side? Maybe they themselves are also unaware of the more general issue?
1 Like
I think part of the issue here is suspend and issues with suspend are intel created issues. High battery drain on suspend is an intel issue (i.e. improper suspend) which is further exacerbated by modules. The modue part is a Framework issue, and one they are working on, and it has been a priority but firmware takes a lot more time to turnaround than a simple OS level tweak. Also if one simply uses all usb-c modules you are then only dealing with suspend issues as regards reliability and not a high battery drain issue being aggravated by modules.
1 Like
We’re always working on getting the best results possible. And, with BIOS updates, we aim to address these concerns where we can. I’m not on the engineering team, so I won’t speak for them. But it’s something we continue to focus on.
I have met the very occasional warm suspended laptop, but mostly because I plugged it in after suspending it. I have since gotten into the habit of waking up the laptop whenever I change its power status, which is a bit inconvenient. I have not encountered a toasty laptop in my bag since. Prior to the framework I had the very occasional toasty XPS 13 as well (and I do not have enough data to assess if this had to do with power status changes). I don’t know if improvements in the (fedora) kernel or system setup have improved this over the last couple of years.
What would be interesting to know is what the s2idle power draw under Windows is. Do the expansion cards affect the power draw similarly? If there is proof that the Framework hardware can perform better under a different operating system then that may give the linux kernel and driver people something concrete to work towards.
(I’m sceptical it will, though, because Microsoft is very clearly aiming for a very solid suspend-then-hibernate solution, where the power draw during s2idle isn’t very important)
It’s been 178 days. Are you continuing to focus on this?
3 Likes
I’ve noticed something like this ever since I uninstalled tlp and powertop to fix another issue, where the laptop would hard reboot instead of waking up. When I leave it suspended overnight, for 8 hours, the AMD Framework 13 uses 30-40% of its battery. Thankfully it charges rather quickly, and hibernate works well.
I’m on an AMD Framework 13, running Fedora 40. I followed the Optimizing fedora battery life guide and I even turn off wifi before I suspend my laptop after use (using suspend directly from the Power menu). I see a similar 30-40% battery drain while suspended.
Those issues are by far the most painful issue I have on both AMD machines FW13 & FW16.
I also followed the guide for both Fedora 40 and Ubuntu 24.04 but still cannot rely on the laptop’s battery. I’ve used the sl2idle script and can’t trigger the problem or see anything failing…
This is driving me nuts ! Really !
I would have hope the recent Bios would have patched the firmware bits that could have an impact on this but still no improvements … 
2 Likes