It’s supposed to be like this on any platform that supports S0ix connected standby. Windows has a “power budget” – typically 5% – that it uses to determine when to hibernate.
By default, the device will sleep until it drains 5% battery, at which point it will hibernate.
I believe there are issues disabling CsEnabled can cause on platforms that support S0ix. I guess that’s your tradeoff to make: sleep issues because tgl is not officially specced for S3 sleep, or not being able to set a hibernate timeout and instead having to rely on drain.
Ooh how did you do that? Those options look far more useful!
Given the seemingly 5 million different reasons windows has for not going to sleep or for randomly waking from sleep, I always have a preference for a hard set time after which it’s forced to hibernate…sleep is such a hopelessly unreliable method of turning a computer off!
Just be mindful, as mentioned the hardware is designed with hybrid sleep in mind (S0). S3 is not officially supported on the hardware. Instead of disabling S0 on Windows, I would just enable hibernation. In this way closing the lid will sleep (S0) the device. But you are able to hibernate via the power GUI, or by changing the lid / power button action.
Like this you are still able to suspend the laptop for about 2 hours (if you have no audio software up and running), or you can reliably hibernate. Super stable and rock solid. With the NVME drive in there, you resume from hibernation incredibly fast.
But I don’t want closing the lid to do anything per se. I simply do not trust any computer to go into or stay in standby, full stop. I want it to automatically hibernate after a given amount of time idle in any state! It doesn’t seem much to ask….Dell manage to give that option on 11th Gen Intel…
Ok, then just remove that from the power profile. The lid does not have to trigger anything.
My response was more in general then to your particular case. My point was, trying to use S3 with a device specifically designed for S0 is more trouble then just living with S0, and being able to control hibernation.
Interesting. Seems for reasons unknown, Microsoft automatically hides the Hibernate After x minutes option in Windows 11 if the computer supports modern standby. What a stupid thing to do!
Apparently it can be returned to the power profile options
So i tried today to switch to windows 11 (wiped the drive, started over) and during setup the everything works fine, but once I’m in the OS it wants me to update the drivers. Each set of drivers I’ve tried (3.06, 3.07) has failed to make the wifi work. Windows knows there’s a problem, but it can’t seem to figure out whats wrong. The wifi worked perfectly with no driver bundle, during setup, but after installing the proper drivers it fails to function. I’ve now started over with different systems and bundles 3 or 4 times, and nothing is making the wifi functional. Any tips?
I even just now reflashed 3.07 itself, and that didn’t help either.
Edit: I installed the drivers from intel themselves and now after a restart its working just fine. I don’t really understand why it would have failed before, but alas.
Did you try the Windows 11 Alpha drivers? Another suggestions would be to download Intel Driver and Support Assistant for the most current WiFi drivers.
I think where you’re going wrong is that all the version numbers you reference are BIOS updates, not device drivers.
What you need is the Windows 11 Alpha driver bundle, which is all the relevant Windows drivers, not the BIOS which is different entirely. Incidentally, bios 3.07 is the latest, so at least you have that now!
FYI: Yesterday, 19 vulnerabilities in Insyde H2O UEFI BIOS products were published (found under “February 01, 2022” here: Insyde's Security Pledge | Insyde Software). Since some of them are rather severe, I figured it’s best you are aware of them and await their fix in BIOS 3.08
@Kieran_Levin Thank you for following up! It is a little hard from just reading the CVEs what practical vulnerabilities arise from this: are these exploitable by someone with local access or also remotely? During boot? During normal operation?
It would be good to know what kind of mitigation is warranted until the vulnerabilities are fixed. It’s quite a different story if exploits need local (physical) access than if just a network interaction (malicious banner ad on a web page?) can be used as a vector.
In summary, a local attacker with administrative privileges (in some cases a remote attacker with administrative privileges) can use malicious software to perform any of the following:
…
so at this point it looks like the vulnerabilities mainly allow for potentially very severe escalation of another security breach. It would be nice to know what some cases allow a remote attacker to exploit them. Is that for situations where remote firmware administration has been configured?
and OEM’s patched their BIOS’s in January. This is an area Framework needs to improve upon. It’s not good for other OEM’s to have coordinated disclosure but framework to leave their users vulnerable
An update on this, LVFS did not flag this in our bios in their UEFI R2 decompilation checks. I also ran the binarly tools against bios 3.02, 3.06 and 3.07 and it did not detect any threats due to these Insyde CVEs in versions we have shipped.
We are still checking with our vendor to double confirm we are not impacted.
I seem to be hitting an odd issue with 3.07 that I did not hit with previous BIOS versions. I usually leave my laptop plugged in and on more than one occasion I have come back to my laptop being completely drained. I then have to unplug the USB-C cable and plug it back in and then it will still charging. I’ve tried different cables and chargers with the same results. It seems like there are some situations where the charge thresholds are not enabling charging again. Additionally I do have charge thresholds set for 80% charge. Has anyone else seen this?
