You are not logged in.
Hi everyone,
Susped-to-RAM was working flawlessly on my lenovo IdeaPad S12 Netbook until recently:
When I Suspend-to-RAM (via KDE) the system apparently suspends correctly but then it instantly turns back on. So the problem is not that I cannot suspend but rather that the system turns back on immediately after suspending. Usually the system could only be turned back on by pressing a button on the keyboard or the power button (not by moving the mouse or opening the laptop lid).
I unplugged all attached devices, including mouse, keyboard, power supply and network but that doesn't help.
I'm pretty clueless what could cause this and would be happy if someone could point me in some direction. This used to work until recently but I don't know what update broke it.
Last edited by Vortex375 (2012-03-02 16:37:18)
Offline
Small update: I logged out of KDE, stopped kdm and stopped acpid to eliminate possible causes for the wakeup. Then I suspended via 'pm-suspend'.
It did not work, however. The system woke up immediately.
Is there a way to find out the reason for the system waking up? Maybe some logfile? /var/log/pm-suspend.log does not contain anything useful...
Offline
Update:
The system stays asleep when I unload the ehci_hcd and ohci_hcd before suspending (unloading just ehci_hcd as suggested on other sites doesn't work).
So some kind of usb device seems to trigger the wakeup. As I said before I don't have any usb devices plugged in, though.
Since unloading the usb drivers is not very convenient I would really like to find out what exactly causes the wakeup. I don't really have a clue where to start, though.
Last edited by Vortex375 (2012-02-23 17:00:52)
Offline
Hi, i have the same problem on asus eee 1201N. After it wakes up everything is fine except the cpu cooler didn't run... so i had to turn it off.. And it started few weeks ago.. so i assume our problems have the same cause.
Do you have any news about this?
At least it would be great to find out which update caused this behavior...
Last edited by tlamer (2012-03-01 22:19:02)
:wq
Offline
Update:
The system stays asleep when I unload the ehci_hcd and ohci_hcd before suspending (unloading just ehci_hcd as suggested on other sites doesn't work).
So some kind of usb device seems to trigger the wakeup. As I said before I don't have any usb devices plugged in, though.Since unloading the usb drivers is not very convenient I would really like to find out what exactly causes the wakeup. I don't really have a clue where to start, though.
I use a script to unload ehci_hcd automatically when I suspend (my issue is slightly different, it doesn't immediately come back, it just doesn't finish suspending and gets stuck on a black screen)
I'd imagine a script someone similar to this would work:
http://thecodecentral.com/2011/01/18/fi … orking-bug
Last edited by bwat47 (2012-03-02 01:23:23)
Offline
Just curious: have you tried it while plugged into the AC? A number of laptops tend to reboot rather than shutting down on battery power.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
Just curious: have you tried it while plugged into the AC? A number of laptops tend to reboot rather than shutting down on battery power.
No difference between battery and AC.
I'll try bwat47s suggestion. Thanks.
:wq
Offline
bwat47's script works for me, thanks.
Offline
bwat47's script works for me, thanks.
was necessary to modify the script?
:wq
Offline
I only had to change DRIVERS="ehci xhci" to DRIVERS="ehci ohci"
Offline
I only had to change DRIVERS="ehci xhci" to DRIVERS="ehci ohci"
yeah, I had to make the same change as vortex and suspend works! thank you guys!!
:wq
Offline