On my netbook (Acer Aspire One 725) hybrid suspension is not reported properly. I use uswsusp package on Debian testing to put my machine in hybrid suspend state, I use the s2both command from shell. But I think this it's related to the kernel. The hybrid suspension seems to work well but the LED color used to report the state is wrong. Explanation: My Acer Aspire One 725 has three LED (power, battery, wireless) and use the first LED to report the power states: OFF: Machine powered off / hibernated BLUE: Machine powered on Blinking ORANGE: Machine suspended to ram On Windows during an hybrid suspend the LED has the same behaviour of suspend to ram (blinking orange) On Linux this LED stays blue. This also cause a strange behaviour: if I do a hybrid suspend and then reboot the machine the power led stay completely off also when the machine is on.
If you do a normal suspend to ram or suspend to disk, does the power LED behave normal? What kernel version are you using? Do you always have this problem or it started with some kernel version? Please attach the dmesg after you resume from hybrid suspend, thanks.
When I use s2ram or s2disk the LEDs work as expected (and as described above) Now on my netbook is running a version 3.8 of the linux kernel. I have installed it from the experimental branch of Debian. I have never think to run another kernel. So I have tried the latest kernel v3.2 found in the testing banch. It has a different (but always wrong) behaviour: During the save to disk the power LED started correctly blink with orange color, but after a resume the LED is always blinking orange instead of a fixed blue. On another notebook (an old Toshiba A300D) hybrid suspension works well and as expected. I have attached two dmesg log, obtained with the commands sequence: dmesg -c s2both dmesg > outputfile for the kernels v3.2 and v3.8
Created attachment 100601 [details] dmesg output after an hybrid suspend with kernel 3.8
Created attachment 100611 [details] dmesg output after an hybrid suspend with kernel 3.2
So s2both is an user space tool, but my disto fedora does not provide it... From the log, it appears it first did a S4 and then S3. I'll need to check s2both to understand what it does.
S4 is used in s2disk S3 is used in s2ram s2both uses s2ram and s2disk functions I have also submit a bug report to the Debian maintainers of uswsusp http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705688
From the page: https://wiki.archlinux.org/index.php/Uswsusp "s2both writes the system snapshot to the swap (just like s2disk) but then puts the machine into STR (just like s2ram). If the battery has enough power left you can quickly resume from STR, otherwise you can still resume from disk without losing your work." So looks like to me, regarding the LED, s2both should be the same as s2ram, unless you ran out of battery, which might not be your case. I have no idea why on s2both, the LED doesn't show correctly, it feels like a bug in s2both, the user space tool, not the kernel. And I don't think it is useful to compare the behavior to windows, since I'm not sure the intent of s2both is to mimic the behavior of Windows' hybrid suspend. As far as I know, the behavior of Windows' hybrid suspend is that, after system stays at S3 for some pre-defined time, Windows will put the system to S4, no matter how much battery left. And from the above words about s2both, it looks to me, s2both will not attempt a S4, it will let the power drain, but since it has created a snapshot in disk, the data is not lost. Anyway, this is a user space tool bug, not the kernel's I would say. So please follow the bug in Debian's page, thanks.