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.
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?
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.
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 inafter 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)
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 …
I found this thread because I have a new FW16 and I left my laptop in my backpack for a couple of days (it’s the weekend, doncha know). I pull it out and lo and behold it won’t power on? How strange. Plug it in and come to discover that the battery is fully drained!
I haven’t had issues like this since an HP something-or-other that I had in the late 90’s. My Thinkpads have all been decent suspend-ers.
Can Framework give us a fix or a workaround? This thread is really long! And it appears that customers are having to kludge their own solutions to this issue which is really annoying. Thanks.
I have both a Framework 13 (batch 2) and a Framework 16 (batch 1) running Archlinux, and I’ve never been able to resolve this problem. I just either power it off entirely or make sure it’s plugged in. Otherwise, if I leave it in suspend for ~1 day, I expect it to be dead by the time I try to use it again. Certain things have helped, like not having an HDMI/USB-A module plugged in, but the battery drain during suspend is still overall very bad compared to my past laptops.
I did not have this problem with my older Thinkpad. It would last in suspend for a long time.
My understanding is that some portion of the blame here is on the CPU makers for removing certain types of suspend modes, but I’m not particularly well educated on the matter.
The only work-around I’ve seen that I think can definitively work is to setup a suspend-then-hibernate hybrid. I haven’t bothered with this (yet) because I’m not especially portable. I mostly only use my laptop(s) at home where there’s always a power cord nearby. If I were back in school, for example, then I’d invest the time to do suspend-then-hibernate.
According to a friend at work, yes, this is an issue that’s actually become more of a thing across makers. My eyes glazed over when he explained the details, but as I understand it, if you put sleep in eg the BIOS, and go to sleep without telling the O/S, then Bad Things can happen.
I haven’t seen them in my older Thinkpad, but I guess it’s a thing. So it’s now up to the O/S to sleep, and there are some chipsets and devices that have this or that deep sleep capability, etc.
In short, I think it’s an industry-wide problem, sleep has actually gotten worse in the last few years, and it’s not Framework’s fault. That’s the upshot for me at least.
Exactly! Has there been any update regarding this?
Everyone would appreciate an honest response from the engineering team on this problem and the possible solutions (also, the things that do not work). It is not a first-gen laptop anymore.
I think Framework should be warning people about this known issue, it’s probably damaging machines out there and you can’t help but think it’ll be dangerous in the wrong situation.
These sorts of problems would be much easier to fix if people provided more information.
which expansion cards and devices were plugged into which slots when suspended.
which os version and kernel version is running.
where the laptop is during suspend. There have been reports of laptops waking up in laptop bags, so knowing whether any pressure is applied to the laptop lid during suspend is useful info. Note: there is already a workaround/fix for this case.
For example, some people in this thread suspect the hdmi card as a card that is still drawing power during suspend. There is a workaround for this where you add a script that is automatically run during suspend that cuts power to that usb slot.
Similarly for the ethernet card. Some people will want wake-on-lan so some power needs to remain, but others won’t need wake-on-lan and one can power off the usb to that port during suspend with a script.
This looks like another case of [RESPONDED] Linux s2idle sleep "random" power usage increase, which is apparently from my testing unrelated to expansion cards or laptop pressure / phisical conditions (because reproducible without those). It has been present in all Framework laptops since the beginning apparently (I have a gen 11 and have seem similar reports in gen 12 and gen 13) and the only “fix” we have so far is to not use s2idle sleep…
