[SOLVED] Computer immediately resumes after suspend
Page 1 of 1 (15 posts)
Tags:
None
Registered Member 
|
Hi, every now and then, my laptop (Dell XPS 17 L702X) won't suspend properly. That is, it suspends fine, but then immediately resumes. I've tried unplugging USB devices, but it still won't stay asleep. I've checked /var/log/pm-suspend.log, and there's nothing informative there. The log lists the suspend procedure, then a pause of a few seconds, and the resume procedure. Is there any other way to troubleshoot this problem? It's intermittent, which presumably makes it hard to troubleshoot, although it seems to happen more frequently when I'm late to leave work!
 Thanks in advance.
Last edited by sparhawk on Wed Apr 10, 2013 12:43 pm, edited 1 time in total.
|
Global Moderator
|
I had similar problems once, and it turned out every lid close/open event was evaluted twice, thus suspending and un-suspending the computer ... maybe there's a similar issue for you? I solved it by adding a shell script which enforced a 20 second timeout between events to the ACPI handler.
Greetings, Sven
I'm working on the KDevelop IDE.
|
|
Registered Member
|
That sounds promising, but I'm not sure if that's the issue here. I normally suspend with a keystroke that I've assigned to "Sleep" via the system settings. I guess it's possible that it's being evaluated twice, but I would've thought less likely than a hardware switch. Also, was your problem intermittent?
Anyway, it's probably worth a try. Could you please provide more details on how you achieved this? Thanks. |
|
Global Moderator
|
This issue always happened for me, and it still does on that particular computer. But it only happened for the hardware lid button (when you closed the notebook), if I e.g. typed "pm-suspend" it didn't happen.
Also, I'm everything but a powermanagement expert, so I can just help you guessing  You could try looking in /etc/acpi. For example I have a script called handler.sh there which seems to handle all power events. You could add some "echo suspended > /tmp/suspend.log" or similar there, and see if e.g. the wakeup action is registered by acpi. In the worst case, you could then add a workaround shellscript like I did, and e.g. add a minimum 10 seconds delay between sleep and wakeup (and otherwise just reject the event). But as said, if you're looking for advice from someone who knows about acpi, you'll have to wait for someone else  Greetings, Sven
I'm working on the KDevelop IDE.
|
|
Registered Member
|
Okay, thanks. I might wait for other replies, then. FWIW I don't have /etc/acpi/handler.sh on my system (Kubuntu). There are 27 other files there, so unless I don't get any other replies, I don't really feel like testing all of those! Thanks for the input, though.
|
|
Registered Member
|
My computer failed to suspend again. This time, `/var/log/pm-suspend.log` was again uninformative, but I thought I'd post the contents of `/var/log/kern.log`, just in case there was something there.
I immediately tried to suspend again. This time I unplugged all USB devices, and the log had the following additional entries. I'm not sure if they are relevant, especially since they didn't appear in the first suspend effort, but otherwise they would have seemed promising.
|
|
Registered Member
|
This seems to happen every time when my laptop is at one particular location. I rotate through three locations regularly, and I've only noticed this problem at one. The only thing I can think of that is specific to here is a particular mouse that I use. Either that or the specific wifi, but that seems unlikely. When I am here, it also seems that automatic suspend is also broken.
FWIW, I also tried
but this had no effect. Also,
didn't work either. |
Administrator
|
This could quite possibly be a USB / ACPI issue, triggered by the mouse you use at this location.
The movement or activation of input devices are often signals for a computer to wake from suspend, and it may be that this mouse is sending them when it should not be. Does eliminating the mouse in question from the equation allow the system to suspend properly? If it does, and you need to keep using the mouse (and cannot disconnect it prior to sleep) I would suggest trying to unload the relevant USB modules prior to suspending the system. Note however that as deciding when to wake is usually a decision taken by the hardware, this may not have any effect.
KDE Sysadmin
[img]content/bcooksley_sig.png[/img] |
|
Registered Member
|
Oops, I forgot to mention the important part… which is that I still cannot suspend even if I disconnect the mouse. Having said that, I shutdown, took the laptop home, and started it up again, and again I cannot suspend! There are no USB devices in common here and the previous location, so perhaps that was a red herring!
|
|
Registered Member
|
Aaaaah… I worked it out! It turns out that I had previously created some udev rules to allow some usb devices to wake the computer up from suspend as detailed here. A list of terminal commands and output is probably more descriptive.
Now it suspends fine. I'm not sure why it suddenly stopped working, and I'll troubleshoot a bit more to see if I can still wake the computer from USB devices, but I just thought I should shoot this reply through first. ==EDIT== Troubleshooting more, it seems that 2-1 (root hub?) is the only one that needs to be disabled. 2-1.1 seems to be sufficient to allow wakeup from my mouse.
It seems that the udev script i was using toggles both 2-1 as well as 2-1.1.
It seems that this is called twice for $env{DEVPATH} = two things:
There might be a more elegant way to only trigger on one, but I just hacked the udev rule to
and this now works fine. |
|
Administrator
|
Good to see you found the cause. Rather odd that the USB Root Controller was the cause however. It may have been caused by other (often integrated) USB devices in your system (Webcams and Bluetooth adapters are often wired internally via USB).
You might want to report a bug to your distribution here, as the controller itself definitely should not be causing a wake (although I'm not surprised, on my system I have to customise it to unload certain USB related drivers and then load them again otherwise it fails to enter sleep properly)
KDE Sysadmin
[img]content/bcooksley_sig.png[/img] |
|
Registered Member
|
Bug reported here. Thanks again, bcooksley. |
Registered Member
|
i have a similar issue as in the original post caused by my Asus bluetooth USB dongle. Even if I turn off my bluetooth keyboard and mouse and suspend the computer with the dongle attached, the computer MAY (not always, but OFTEN) resume from suspend by itself. If I remove the dongle, this doesn't happen (at least not yet in my limited testing).
Is there a way to disable the usb dongle or port completely just before suspend and then reenable it upon resume? I suppose it would be easy to write a script that I can stick in /etc/pm/sleep.d/ somewhere but I wouldn't know how to write it. Help? |
|
Administrator
|
My system needs the following in /etc/pm/sleep.d/ in order to be able to sleep/hibernate.
Perhaps it can help...
KDE Sysadmin
[img]content/bcooksley_sig.png[/img] |
|
Registered Member
|
I've moved onto Arch, where this bug is not present. Thanks for posting back though, bcooksley. Hopefully it will help others. |
Page 1 of 1 (15 posts)
Bookmarks
Who is online
Registered users: bancha, Bing [Bot], Evergrowing, Google [Bot], lockheed, mesutakcan, mickae, Sogou [Bot]
