Reply to topic

[SOLVED] Computer immediately resumes after suspend

User avatar sparhawk
Registered Member
Posts
412
Karma
0
OS
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! :o

Thanks in advance.

Last edited by sparhawk on Wed Apr 10, 2013 12:43 pm, edited 1 time in total.
User avatar scummos
Global Moderator
Posts
1130
Karma
7
OS
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.
User avatar sparhawk
Registered Member
Posts
412
Karma
0
OS
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.
User avatar scummos
Global Moderator
Posts
1130
Karma
7
OS
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.
User avatar sparhawk
Registered Member
Posts
412
Karma
0
OS
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.
User avatar sparhawk
Registered Member
Posts
412
Karma
0
OS
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.
Code: Select all
Mar 27 17:07:30 sparhark-XPS-17 kernel: [41661.522755] wlan0: deauthenticating from d4:9a:20:5a:8d:21 by local choice (reason=3)
Mar 27 17:07:30 sparhark-XPS-17 kernel: [41661.585982] cfg80211: All devices are disconnected, going to restore regulatory settings
Mar 27 17:07:30 sparhark-XPS-17 kernel: [41661.585989] cfg80211: Restoring regulatory settings
Mar 27 17:07:30 sparhark-XPS-17 kernel: [41661.585997] cfg80211: Calling CRDA to update world regulatory domain
Mar 27 17:07:30 sparhark-XPS-17 kernel: [41661.588588] cfg80211: Ignoring regulatory request Set by core since the driver uses its own custom regulatory domain
Mar 27 17:07:30 sparhark-XPS-17 kernel: [41661.588591] cfg80211: World regulatory domain updated:
Mar 27 17:07:30 sparhark-XPS-17 kernel: [41661.588592] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Mar 27 17:07:30 sparhark-XPS-17 kernel: [41661.588594] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Mar 27 17:07:30 sparhark-XPS-17 kernel: [41661.588595] cfg80211:   (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Mar 27 17:07:30 sparhark-XPS-17 kernel: [41661.588596] cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Mar 27 17:07:30 sparhark-XPS-17 kernel: [41661.588597] cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Mar 27 17:07:30 sparhark-XPS-17 kernel: [41661.588598] cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Mar 27 17:07:32 sparhark-XPS-17 kernel: [41663.483014] PM: Syncing filesystems ... done.
Mar 27 17:07:32 sparhark-XPS-17 kernel: [41663.713778] PM: Preparing system for mem ssparharkp
Mar 27 17:07:32 sparhark-XPS-17 kernel: [41663.759840] bbswitch: enabling discrete graphics
Mar 27 17:07:33 sparhark-XPS-17 kernel: [41664.120594] pci 0000:01:00.0: power state changed by ACPI to D0
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41664.135056] pci 0000:01:00.0: power state changed by ACPI to D0
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41664.135093] pci 0000:01:00.0: power state changed by ACPI to D0
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41664.135095] pci 0000:01:00.0: power state changed by ACPI to D0
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41664.135103] Freezing user space processes ... (elapsed 0.01 seconds) done.
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41664.151231] Freezing remaining freezable tasks ... (elapsed 2.62 seconds) done.
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41666.771474] PM: Entering mem ssparharkp
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41666.771506] Suspending console(s) (use no_console_suspend to debug)
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41666.771798] sd 1:0:0:0: [sdb] Synchronizing SCSI cache
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41666.772064] sd 0:0:0:0: [sda] Synchronizing SCSI cache
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41666.772346] sd 0:0:0:0: [sda] Stopping disk
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41666.773560] sd 1:0:0:0: [sdb] Stopping disk
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.150002] PM: suspend of drv:sd dev:0:0:0:0 complete after 378.495 msecs
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.150056] PM: suspend of drv:scsi dev:target0:0:0 complete after 378.402 msecs
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.150078] PM: suspend of drv:scsi dev:host0 complete after 378.087 msecs
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.154684] PM: suspend of drv: dev:ata1 complete after 382.609 msecs
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.242581] PM: suspend of drv:snd_hda_intel dev:0000:00:1b.0 complete after 424.640 msecs
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.336979] PM: suspend of drv:sd dev:1:0:0:0 complete after 566.018 msecs
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.337030] PM: suspend of drv:scsi dev:target1:0:0 complete after 566.013 msecs
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.337069] PM: suspend of drv:scsi dev:host1 complete after 565.463 msecs
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.350366] PM: suspend of drv: dev:ata2 complete after 578.588 msecs
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.366374] PM: suspend of drv:ahci dev:0000:00:1f.2 complete after 548.673 msecs
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.366410] PM: suspend of drv: dev:pci0000:00 complete after 548.547 msecs
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.366424] PM: suspend of devices complete after 595.701 msecs
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.366426] PM: suspend devices took 0.596 seconds
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.366576] PM: late suspend of devices complete after 0.148 msecs
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.366720] r8169 0000:0a:00.0: wake-up capability enabled by ACPI
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.382427] xhci_hcd 0000:04:00.0: wake-up capability enabled by ACPI
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.414411] ehci_hcd 0000:00:1d.0: wake-up capability enabled by ACPI
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.430602] ehci_hcd 0000:00:1a.0: wake-up capability enabled by ACPI
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.462274] PM: noirq suspend of devices complete after 95.837 msecs
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.462456] ACPI: Preparing to enter system ssparharkp state S3
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.474525] PM: Saving platform NVS memory
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.476432] Disabling non-boot CPUs ...
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.577992] CPU 1 is now offline
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.681846] CPU 2 is now offline
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.682776] Broke affinity for irq 51
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.785681] CPU 3 is now offline
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.889533] CPU 4 is now offline
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.890270] Broke affinity for irq 43
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.890272] Broke affinity for irq 44
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.890274] Broke affinity for irq 46
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.890275] Broke affinity for irq 47
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.890276] Broke affinity for irq 48
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.890278] Broke affinity for irq 49
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41667.993378] CPU 5 is now offline
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41668.097219] CPU 6 is now offline
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41668.097784] Broke affinity for irq 23
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41668.097789] Broke affinity for irq 45
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41668.201079] CPU 7 is now offline
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41668.201459] Extended CMOS year: 2000
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41668.202534] ACPI: Low-level resume complete
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41668.202576] PM: Restoring platform NVS memory
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41668.203135] CPU0: Thermal monitoring handled by SMI
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41668.203190] Extended CMOS year: 2000
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41668.203229] Enabling non-boot CPUs ...
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41668.203298] Booting Node 0 Processor 1 APIC 0x1
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41668.214270] Disabled fast string operations
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41668.214286] CPU1: Thermal monitoring handled by SMI
Mar 27 17:07:39 sparhark-XPS-17 kernel: [41668.216796] CPU1 is up


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.
Code: Select all
Mar 27 17:08:18 sparhark-XPS-17 kernel: [41706.168060] PM: Device 0000:04:00.0 failed to suspend async: error -16
Mar 27 17:08:18 sparhark-XPS-17 kernel: [41706.479444] PM: suspend of drv:sd dev:0:0:0:0 complete after 379.239 msecs
Mar 27 17:08:18 sparhark-XPS-17 kernel: [41706.579392] PM: suspend of drv:snd_hda_intel dev:0000:00:1b.0 complete after 427.641 msecs
Mar 27 17:08:18 sparhark-XPS-17 kernel: [41706.666581] PM: suspend of drv:sd dev:1:0:0:0 complete after 566.707 msecs
Mar 27 17:08:18 sparhark-XPS-17 kernel: [41706.666795] PM: Some devices failed to suspend
User avatar sparhawk
Registered Member
Posts
412
Karma
0
OS
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
Code: Select all
$ qdbus org.kde.kded /kded unloadModule powerdevil
$ qdbus org.kde.kded /kded loadModule powerdevil

but this had no effect. Also,
Code: Select all
$ sudo pm-suspend

didn't work either.
User avatar bcooksley
Administrator
Posts
19760
Karma
87
OS
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]http://forum.kde.org/content/bcooksley_sig.png[/img]
User avatar sparhawk
Registered Member
Posts
412
Karma
0
OS
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!
User avatar sparhawk
Registered Member
Posts
412
Karma
0
OS
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.
Code: Select all
$ cat /sys/bus/usb/devices/*/power/wakeup
disabled
enabled
disabled
enabled
enabled
disabled
disabled
disabled
disabled
$ ls */power/wakeup
1-1/power/wakeup  2-1.1/power/wakeup  2-1.5/power/wakeup  2-1/power/wakeup  3-1/power/wakeup  usb1/power/wakeup  usb2/power/wakeup  usb3/power/wakeup  usb4/power/wakeup
$ sudo su
# echo disabled > 2-1.1/power/wakeup
# echo disabled > 2-1/power/wakeup
# echo disabled > 3-1/power/wakeup

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.

Code: Select all
$ lsusb -t
 /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/8p, 480M
        |__ Port 1: Dev 5, If 0, Class=HID, Driver=usbhid, 1.5M
        |__ Port 5: Dev 3, If 0, Class='bInterfaceClass 0xe0 not yet handled', Driver=btusb, 12M
        |__ Port 5: Dev 3, If 1, Class='bInterfaceClass 0xe0 not yet handled', Driver=btusb, 12M



It seems that the udev script i was using toggles both 2-1 as well as 2-1.1.
Code: Select all
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="15d9", ATTRS{idProduct}=="0a4d" RUN+="/bin/sh -c 'echo enabled > /sys$env{DEVPATH}/../power/wakeup'"


It seems that this is called twice for $env{DEVPATH} = two things:
Code: Select all
/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1
/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.0

There might be a more elegant way to only trigger on one, but I just hacked the udev rule to
Code: Select all
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="15d9", ATTRS{idProduct}=="0a4d" RUN+="/bin/sh -c 'echo $env{DEVPATH} | grep -q usb2/[^/]*/[^/]*/[^/]*$ && echo enabled > /sys$env{DEVPATH}/../power/wakeup'"

and this now works fine.
User avatar bcooksley
Administrator
Posts
19760
Karma
87
OS
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]http://forum.kde.org/content/bcooksley_sig.png[/img]
User avatar sparhawk
Registered Member
Posts
412
Karma
0
OS
bcooksley wrote:You might want to report a bug to your distribution here

Bug reported here. Thanks again, bcooksley.
molecule-eye
Registered Member
Posts
399
Karma
0
OS
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?
User avatar bcooksley
Administrator
Posts
19760
Karma
87
OS
My system needs the following in /etc/pm/sleep.d/ in order to be able to sleep/hibernate.
Perhaps it can help...
Code: Select all
case "${1}" in
        hibernate|suspend)
              # Unbind ehci_hcd for first device 0000:00:1a.0:
               echo -n "0000:00:1a.0" | tee /sys/bus/pci/drivers/ehci_hcd/unbind
              # Unbind ehci_hcd for second device 0000:00:1d.0:
               echo -n "0000:00:1d.0" | tee /sys/bus/pci/drivers/ehci_hcd/unbind
          # Unbind xhci_hcd for third device 0000:07:00.0:
          # echo -n "0000:07:00.0" | tee /sys/bus/pci/drivers/xhci_hcd/unbind
          rmmod ath9k
        ;;
        resume|thaw)
              # Bind ehci_hcd for first device 0000:00:1a.0:
              echo -n "0000:00:1a.0" | tee /sys/bus/pci/drivers/ehci_hcd/bind
              # Bind ehci_hcd for second device 0000:00:1d.0:
              echo -n "0000:00:1d.0" | tee /sys/bus/pci/drivers/ehci_hcd/bind
          # Bind xhci_hcd for third device 0000:07:00.0:
          #echo -n "0000:07:00.0" | tee /sys/bus/pci/drivers/xhci_hcd/bind   
          sleep 10s && modprobe ath9k &
        ;;
esac


KDE Sysadmin
[img]http://forum.kde.org/content/bcooksley_sig.png[/img]
User avatar sparhawk
Registered Member
Posts
412
Karma
0
OS
bcooksley wrote:Perhaps it can help...

I've moved onto Arch, where this bug is not present. Thanks for posting back though, bcooksley. Hopefully it will help others.

 
Reply to topic

Bookmarks



Who is online

Registered users: Baidu [Spider], Bing [Bot], Exabot [Bot], Google [Bot], gui-m, irina_r, konstar, philiptucker, piper, TheraHedwig