When you put your computer to suspend, it will turn some of its devices to power saving mode to preserve energy consumption. But computers have many sleep states from deeper to shallow just like humans. The most shallow one is the freeze (or S0-idle) which only puts CPU to idle and if possible turn other devices to less power consuming mode. The most deeper one is the “Sleep-to-Memory” (or S3) in which CPU is turned off, and nearly only memory and some critical devices uses energy. It is also possible to suspend-to-disk (S4, S5), with STD current state of computer saved to disk. STD is called hibernate. In hibernate cold reboot will be performed so, it will take longer to restore the state.
Depending on your computers configuration, you may see some subset of sleep states (S0, S1, S2, S3, S4, S5). In this article I will discuss the reasons and possible workarounds of missing sleep states.
[table id=”1″ /]
Reference: https://msdn.microsoft.com/en-us/library/windows/desktop/aa373229%28v=vs.85%29.aspx,
Although above table taken from Microsoft, terminology is the same. But I’m not sure about the S0 low-power idle mode description which states: “Systems that support Modern Standby do not use S1-S3”. Because in linux, kernel complains if it could not find S1, S2, and S3 in firmware.
More detailed information about sleep states can be found in https://www.kernel.org/doc/Documentation/power/states.txt
Some Sleep States not Listed
First things first. Power management of linux systems left to pm-* programs with the modern kernels. With these commands you can put your system to suspend, hibernate or a complete power off state. Additionally pm-if-supported command can be used to test if a power state is supported with the system. It will not generate an output but return value of the command indicates the capability. (echo $? will show the return value of the last executed command).
So let’s execute
pm-is-supported --suspend echo $? 1 |
|---|
So, it says suspend is not supported. Let’s dig in to issue. What about the dmesg?
dmesg [ 0.553777] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [_S1_] (20150930/hwxface-580) [ 0.553786] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [_S2_] (20150930/hwxface-580) [ 0.553793] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [_S3_] (20150930/hwxface-580) [ 0.553814] ACPI: (supports S0 S4 S5) |
|---|
It says, system supports SO, S4, S5. But in previous lines there is some ACPI Exceptions. ACPI stands for Advanced Configuration and Power Interface. We’ll explain the meanings of these exceptions soon.
fwts – Firmware Test Suite
This is very handy tool to test firmwares. You can install it with your distribution’s package manager or build it from its source. I added this program to this post because it was used in this bug report while I was searching exceptions listed in dmesg output. In short, the output of fwts shows that system does not support S1, S2, and S3 which is an important investigation to the issue.
|
Ivan Hu (ivan.hu) wrote on 2014-02-19: |
|---|
|
Ivan Hu (ivan.hu) wrote on 2014-02-19: As for the failures, These should not be a big concern, if the IPMI works fine. |
Results
With these steps you can evaluate whether your system supports missing Sleep States. But there are other reasons if you can not see some Sleep States such as missing kernel configuration. To investigate the real cause that fails suspend/hibernate/resume you can read the link which is a comprehensive source to find out the source of the issue. Additionally, you can follow the steps below to identify the problem:
swsusp/S3 tricks ~~~~~~~~~~~~~~~~ Pavel Machek <pavel@ucw.cz> If you want to trick swsusp/S3 into working, you might want to try: * go with minimal config, turn off drivers like USB, AGP you don't really need * turn off APIC and preempt * use ext2. At least it has working fsck. [If something seems to go wrong, force fsck when you have a chance] * turn off modules * use vga text console, shut down X. [If you really want X, you might want to try vesafb later] * try running as few processes as possible, preferably go to single user mode. * due to video issues, swsusp should be easier to get working than S3. Try that first. When you make it work, try to find out what exactly was it that broke suspend, and preferably fix that. |
|---|
Reference: https://www.kernel.org/doc/Documentation/power/tricks.txt
note to self 
For the S1, S2, S3, S4 failures,
The failures come from firmware not provide _S1,_S2,_S3 and _S4 objects, so that the kernel complains about cannot find _S1,_S2, _S3,_S4 namespace objects that contains the register values for the sleep state when kernel would like to setup all the sleep state information. This means kernel don’t know how to enter S1,S2,_S3,_S4 sleep state, it makes no function of these sleep states.
But it should not be a problem if these sleep state isn’t supported intentionally.
I’ve sent a patch to lower the failure level on fwts of the _S1 and _S2 objects cannot be find, since these sleep states are not used in most of the machines. Please refer to and follow by the bug#1279714.