Bug 57391
Summary: | Hybrid suspension doesn't work properly on my Acer aspire one AO725 | ||
---|---|---|---|
Product: | Power Management | Reporter: | Francesco Muzio (muziofg) |
Component: | Hibernation/Suspend | Assignee: | Aaron Lu (aaron.lu) |
Status: | CLOSED INVALID | ||
Severity: | normal | CC: | aaron.lu |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 3.8 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
dmesg output after an hybrid suspend with kernel 3.8
dmesg output after an hybrid suspend with kernel 3.2 |
Description
Francesco Muzio
2013-05-01 14:51:27 UTC
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. |