Disable broken xhci device before suspend and avoid freeze.

system-sleep-xhci.sh

#!/bin/sh
# 
# This script should prevent the following suspend errors
#  which freezes the Dell Inspiron laptop. 
#
# Put it in /usr/lib/systemd/system-sleep/xhci.sh
#
# The PCI 00:14.0 device is the usb xhci controller.
#
#    kernel: [67445.560610] pci_pm_suspend(): hcd_pci_suspend+0x0/0x30 returns -16
#    kernel: [67445.560619] dpm_run_callback(): pci_pm_suspend+0x0/0x150 returns -16
#    kernel: [67445.560624] PM: Device 0000:00:14.0 failed to suspend async: error -16
#    kernel: [67445.886961] PM: Some devices failed to suspend, or early wake event detected

if [ "${1}" == "pre" ]; then
  # Do the thing you want before suspend here, e.g.:
  echo "Disable broken xhci module before suspending at $(date)..." > /tmp/systemd_suspend_test
  grep XHC.*enable /proc/acpi/wakeup && echo XHC > /proc/acpi/wakeup
elif [ "${1}" == "post" ]; then
  # Do the thing you want after resume here, e.g.:
  echo "Enable broken xhci module at wakeup from $(date)" >> /tmp/systemd_suspend_test
  grep XHC.*disable /proc/acpi/wakeup && echo XHC > /proc/acpi/wakeup
fi

Thanks for creating this gist. When I shut my laptop lid, my system would suspend. However, sometimes it would not resume and I would be forced to press and hold the power button to shut it off. With this script, I no longer have the issue.

thanks. I used it here:
https://askubuntu.com/questions/1047229/sometimes-gnome-suspend-immediately-resumes-ubuntu-18-04-on-pure-intel-laptop/1047754#1047754

Thank you! This solved my systemd suspend problems with my System76 Oryx Pro running Arch Linux. I too had log entries with

Aug 23 14:03:43 bilquis kernel: pci_pm_suspend(): hcd_pci_suspend+0x0/0x30 [usbcore] returns -16
Aug 23 14:03:43 bilquis kernel: dpm_run_callback(): pci_pm_suspend+0x0/0x120 returns -16
Aug 23 14:03:43 bilquis kernel: PM: Device 0000:00:14.0 failed to suspend async: error -16
Aug 23 14:03:43 bilquis kernel: PM: Some devices failed to suspend, or early wake event detected

(Trying to add as many keywords as possible to help future searchers. 🙈)

Same problem on dell XPS 13, ubuntu 18.10, thanks a lot !

Solved (random) immediate wake-up after suspend on dell XPS 13, ubuntu 18.10, thank you 👍
Edit It seems i have problems for the Device 0000:00:14.0 (Intel Corporation Sunrise Point-LP USB 3.0 xHCI) and with my bluetooth device your script solved the first one (disabling bluetooth makes it sleep normally).

The edit of your script posted here https://askubuntu.com/questions/1089067/wakes-from-suspend-immediately-when-bluetooth-device-disconnected/1092933 solved both problems for me.

It fixed my Thinkpad P52 on Fedora 30 too. Thanks a lot!

Who knows why some machines have trouble with this and some don't?

Thanks, it fixed suspending on P51s with Manjaro KDE (5.6.16)

i think it fixed my problem on a Thinkpad X1 Carbon 6 Gen . tried upgrading ubuntu 19.10 to 20.04 and also installing bios updates to fix it, to no avail.

my symptoms were that suspend seemed to sometimes work fine, sometimes seem to work but fail to resume, and sometimes it looked like it would suspend, but i would end up with a blinking red dot in the thinkpad logo.

Seems to have fixed similar symptoms on my Thinkpad X390. Thanks for sharing.

thanks for this. had similar problem on Fedora 35 (Gnome) Dell Latitude 5480 laptop

Recently started encountering issues with suspend on my Dell Precision 7710
I tried the above script but to no avail

I found this ancient link https://bugs.launchpad.net/ubuntu/+source/pm-utils/+bug/562484/comments/3 which deals with the issue by unloading the module itself.

I modified the above script as follows and now suspend works fine

  # Do the thing you want before suspend here, e.g.:
  echo "Unload xhci_pci module before suspending at $(date)..." > /tmp/systemd_suspend_test
  modprobe -r xhci_pci
elif [ "${1}" == "post" ]; then
  # Do the thing you want after resume here, e.g.:
  echo "Load xhci_pci module at wakeup from $(date)" >> /tmp/systemd_suspend_test
  modprobe xhci_pci
fi

One thing: it should be bash in shebang not sh.

One thing: it should be bash in shebang not sh.

why would it need to be bash? it's a perfectly valid posix sh script

interesting... with sh I've got:

./xhci: 15: [: pre: unexpected operator
./xhci: 19: [: pre: unexpected operator

It's debian, so sh is dash.

$ ls -la /bin/sh
lrwxrwxrwx 1 root root 4 Jun 21 13:28 /bin/sh -> dash

When I change to bash it works perfectly fine.

ah, i was wrong; the test utility specification doesn't require == to be supported, only = or -eq

for maximum compatibility, the script could be edited to use = instead