And if Microsoft is having issue on Windows, you can bet Linux support is even worse (possible crashes or not putting every device on low power mode, so battery drain).
Take a look at the top pinned comment for that video. You’ll see that this video caused quite a stir, and it even identified a bug within Windows:
The following behavior would change depending on whether or not the laptop was connected to power while going to the Sleep S0 state:
I think it’s sensationalist to assume that Windows OS bugs affect Linux as well. Modern Standby / s2idle does absolutely require that all the devices connected to the SOC are in the proper low power energy state. If any given one of them doesn’t reach this state, the SOC may not be able to get to it’s appropriate low power energy state. If you contrast this with S3 you’ll find that the BIOS mandates that all devices go to a low power state. In exchange for this “hammer” you will find longer resume latency.
The debug script you outlined for Intel systems is a great way to debug problems with power consumption.
Here’s a similar one that does this type of sleuth work for AMD systems:
At least for an AMD system, a properly configured kernel and BIOS will consume less power over s2idle/s0i3 cycles than it would for S3.
At least in my opinion what we need to smooth out rough edges for the experience is more data automatically collected by the OS to let people know when there are problems so that they can actually get fixed. Some ideas I have:
- We need a standard interface to report hardware sleep data. I sent some [RFC patches to the mailing list] a while back, but after the last round of feedback I never dusted them off. Someone (maybe me?) might want to pick these back up.
- We need software (systemd?) to be keeping a database of sleep information. The things that come to mind for me are: Battery levels before/after suspend, time spent in suspend, time spent in hardware sleep, and a calculated rate of discharge.
- We need user friendly software (Somewhere in GNOME?) to be regularly analyzing this data and if there is a problem making some noise in a way that can be actionable to fix.
- Rate of discharge was > X mW.
- Time spent in HW sleep state was < Y%.
- Kernel woke Z times over AAA seconds, which is too frequently and might indicate a BIOS or EC problem.
Then you can have a message like You might have a problem with a device driver - go to this wiki page for how to report a bug and capture debug data or You might have a bug with your BIOS or EC, please go to URL to file a bug with your system vendor.
- A way for users to opt into sharing this data anonymously into a central database. In the Windows world Microsoft collects oodles of telemetry and when there is a problem they go to the device vendor or system vendor and tell them there is and here is the data to back it up. We need the same thing in the Linux world.