Yes, that’s just awful. I have greeted my laptop warm to the touch after suspension for a while at some occasions – but only when it was plugged in and I think when I plugged it in after suspending, so I try to avoid changing the power state of the system while suspended. So hopefully this was an accidental mishap? (little solice if you can’t identify with confidence what led to the bad performance, so that you can avoid it…)
While not awesome, yes, in my testing it has made some difference. But I think mileage will vary.
New kernel updates will hopefully also provide additional relief as we progress through this.
We’re also looking to tackle this at the expansion module level where possible. Appreciate the feedback and experiences thus far.
@anarcat did extensive testing on various configurations of modules and his findings indicate that the USB-C pass-through modules make no discernible difference. It would be interesting if you’d find otherwise, since they’re supposed to be just an extension cord, as far as I understand. (the penalties for plugging in stuff should also not be expected to be additive: the presence of a certain module apparently prevents certain hardware inside the laptop to go into a low-power state. Adding another module that would have the same effect doesn’t necessarily incur another penalty on top)
2 Likes
If you don’t mind longer wake times, add mem_sleep_default=deep to your kernel params to significantly save on battery life on Linux based systems.
1 Like
From my understanding, newer expansion cards were also supposed to help/fix this issue, or was that with just power draw in general?
I’m experiencing this suspend issue (inconsistently) on 13th-gen (with fedora 38), which in theory got the second gen expansion cards with it. I do have USB-A and HDMI slots.
Are these same issues confirmed on the v2 cards as well?
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.