5

My computer usually suspends and wakes normally. But when I connect a USB3.0 hard disk, even after it has been unmounted and disconnected, the machine immediately wakes every time I try to suspend.

All USB devices are disabled in /proc/acpi/wakeup (below), and I can't see any errors in /var/log/syslog pertaining either to the USB disk or the standby or wakeup process.

The same disk connected to a USB 2.0 port does not cause the same problem, neither do USB 2.0 disks connected to the USB 3.0 ports. Even when there are no USB devices connected at all the computer wakes immediately from standby if a USB 3.0 disk has ever been connected since startup.

The systems is a Dell Precision M6700 and the problem occurred with 14.04 and persists with 14.10.

What could be causing this, and how can I debug it further?

> cat /proc/acpi/wakeup
Device  S-state   Status   Sysfs node
P0P1      S4    *disabled
USB1      S3    *disabled
USB2      S3    *disabled
USB3      S3    *disabled
USB5      S3    *disabled
USB6      S3    *disabled
USB7      S3    *disabled
RP01      S4    *disabled  pci:0000:00:1c.0
PXSX      S4    *disabled
RP02      S4    *disabled  pci:0000:00:1c.1
PXSX      S4    *disabled  pci:0000:03:00.0
RP05      S4    *disabled
PXSX      S4    *disabled
RP06      S4    *disabled
PXSX      S4    *disabled
RP07      S4    *disabled
PXSX      S4    *disabled
RP08      S4    *disabled  pci:0000:00:1c.7
PXSX      S4    *disabled  pci:0000:0c:00.0
PEG0      S4    *disabled  pci:0000:00:01.0
PEGP      S4    *disabled
PEG1      S4    *disabled
PEG2      S4    *disabled
PEG3      S4    *disabled
USB4      S3    *disabled
RP03      S4    *disabled  pci:0000:00:1c.2
RP04      S4    *disabled  pci:0000:00:1c.3
PXSX      S4    *disabled
GLAN      S4    *enabled   pci:0000:00:19.0
EHC1      S0    *enabled   pci:0000:00:1d.0
EHC2      S0    *enabled   pci:0000:00:1a.0
XHC       S0    *enabled   pci:0000:00:14.0
HDEF      S4    *disabled  pci:0000:00:1b.0
LID0      S3    *enabled 
PBTN      S3    *enabled

Edit - Explicitly disabling devices does not solve the problem

I've now tried disabling wakeup for all devices (except the power button).

First I disabled the devices in /proc/acpi/wakeup and then to be sure I searched /sys/devices/ for all wakeup files:

find /sys/devices/ -name "wakeup" -print -exec grep enabled {} \;

Then I explicity set them all to disabled, eg.:

sudo bash -c "echo disabled > /sys/devices/pci0000:00/0000:00:19.0/power/wakeup"

Leaving only the power button enabled:

cat /sys/devices/LNXSYSTM:00/LNXPWRBN:00/power/wakeup
# enabled

After that the computer still wakes up immediately from suspend (whenever a USB 3.0 disk has ever been connected).

Also, after waking up, the following devices have been reset to enabled:

/sys/devices/pci0000:00/0000:00:19.0/power/wakeup
/sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0/power/wakeup

The PCI device seems to be my LAN because it's also reset in /proc/acpi/wakeup:

Device  S-state   Status   Sysfs node
...
GLAN      S4    *enabled   pci:0000:00:19.0
...

Can there be other factors not listed in the devices that are responsible for the wake up?

Edit - Added detailed lsusb info

Added info requested by Fabby:

> Bus 004 Device 002: ID 357d:7788  
> Device Descriptor:
>   bLength                18
>   bDescriptorType         1
>   bcdUSB               3.00
>   bDeviceClass            0 (Defined at Interface level)
>   bDeviceSubClass         0 
>   bDeviceProtocol         0 
>   bMaxPacketSize0         9
>   idVendor           0x357d 
>   idProduct          0x7788 
>   bcdDevice            0.00
>   iManufacturer          10 
>   iProduct               11 
>   iSerial                 3 
>   bNumConfigurations      1
>   Configuration Descriptor:
>     bLength                 9
>     bDescriptorType         2
>     wTotalLength          121
>     bNumInterfaces          1
>     bConfigurationValue     1
>     iConfiguration          0 
>     bmAttributes         0xc0
>       Self Powered
>     MaxPower                2mA
>     Interface Descriptor:
>       bLength                 9
>       bDescriptorType         4
>       bInterfaceNumber        0
>       bAlternateSetting       0
>       bNumEndpoints           2
>       bInterfaceClass         8 Mass Storage
>       bInterfaceSubClass      6 SCSI
>       bInterfaceProtocol     80 Bulk-Only
>       iInterface              0 
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x81  EP 1 IN
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0400  1x 1024 bytes
>         bInterval               0
>         bMaxBurst              15
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x02  EP 2 OUT
>     Couldn't open device, some information will be missing
>     bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0400  1x 1024 bytes
>         bInterval               0
>         bMaxBurst              15
>     Interface Descriptor:
>       bLength                 9
>       bDescriptorType         4
>       bInterfaceNumber        0
>       bAlternateSetting       1
>       bNumEndpoints           4
>       bInterfaceClass         8 Mass Storage
>       bInterfaceSubClass      6 SCSI
>       bInterfaceProtocol     98 
>       iInterface              0 
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x01  EP 1 OUT
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0400  1x 1024 bytes
>         bInterval               0
>         bMaxBurst               0
>         Command pipe (0x01)
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x82  EP 2 IN
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0400  1x 1024 bytes
>         bInterval               0
>         bMaxBurst               0
>         MaxStreams             32
>         Status pipe (0x02)
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x83  EP 3 IN
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0400  1x 1024 bytes
>         bInterval               0
>         bMaxBurst              15
>         MaxStreams             32
>         Data-in pipe (0x03)
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x04  EP 4 OUT
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0400  1x 1024 bytes
>         bInterval               0
>         bMaxBurst              15
>         MaxStreams             32
>         Data-out pipe (0x04)
> 
  • Related, but not necessarily dupes: askubuntu.com/q/148481/30266, askubuntu.com/q/152403/30266 – krlmlr Nov 3 '14 at 20:53
  • Are there entries like EHC? and XHCI in your /proc/acpi/wakeup? – krlmlr Nov 3 '14 at 20:54
  • @krlmlr, Yes there are both, though I don't know what they mean. I've posted the full output now. – Ian Mackinnon Nov 4 '14 at 10:52
  • On my system, suspend worked again after saying ( echo EHC1; echo EHC2; echo XHCI ) > /proc/acpi/wakeup in a root shell. – krlmlr Nov 4 '14 at 12:23
  • @krlmlr, Thanks, though unfortunately disabling devices did not help. I've added the results to the question. – Ian Mackinnon Nov 12 '14 at 11:49
3

Firstly, it was not obvious to me that the XHC listing in the wakeup output was a USB 3.0 device.

XHC       S0    *enabled   pci:0000:00:14.0

However, even disabling the wakeup status of this device does not solve the problem.

sudo bash -c "echo disabled > \
    /sys/devices/pci0000:00/0000:00:14.0/power/wakeup"  # Problem persists.

The only working solution I have found is to unbind and bind the device driver using the following commands:

sudo bash -c ' \
  echo -n "0000:00:14.0" > /sys/bus/pci/drivers/xhci_hcd/unbind && \
  echo -n "0000:00:14.0" > /sys/bus/pci/drivers/xhci_hcd/bind;'

I must do this every time between connecting a USB 3.0 storage device and suspending the computer but it works consistently.

It should be noted that the xhci_hcd component of the path is only valid for USB 3.0 devices. This part of the path will need to be varied depending on the type of bus that needs to be reset, and might be one of uhci_hcd, sdhci-pci or ehci-pci for other types of storage device.

  • Holly molly... the echo to unbind and bind works. Thank you! This problem has driven me mad. My laptop is a Lenovo G400 the USB3.0 sysfs node is the same as yours. The Ubuntu version is 16.04. – aasril Nov 24 '18 at 10:49
  • 1
    @aasril The issue is still occurring for me with a fresh install of 18.10, so I'm still using this method wrapped up in a script. – Ian Mackinnon Nov 24 '18 at 11:03
  • do you put any check in the script? I was thinking on making a function or a script which do the command above and systemctl suspend on the line after. Would that do or I need to watch out for something else? – aasril Nov 24 '18 at 11:26
  • 1
    @aasril I don't connect the problematic drive very often so I prefer to run the script manually when needed to minimise potential side effects. I wish I understood the root cause of the problem so I could file a bug report or investigate a fix myself, but I don't even know which package is responsible. – Ian Mackinnon Nov 24 '18 at 11:33
2
+50

Sorry for adding an answer but I don't have enough reputation to add comments...

(Which is why I'm looking at your problem!) ;-) :P

Have you tried resetting the USB bus the disk was just disconnected from before suspending?

If you don't know how, could you:

  1. Shut down the machine
  2. Unplug all USB devices
  3. Remove all power cables, UPSes, batteries, ...
  4. Power on the machine (yes: without power cables!)
  5. Put back all power removed in step 3
  6. Boot the machine
  7. Do a: lsusb --verbose > /tmp/good-bus.txt 2>&1
  8. Plug in the disk
  9. Do a: lsusb --verbose > /tmp/bad-bus.txt 2>&1
  10. Unmount the disk
  11. Eject the disk
  12. Remove the disk
  13. Do a: lsusb --verbose > /tmp/worse-bus.txt 2>&1
  14. Do a: diff --text /tmp/good-bus.txt /tmp/bad-bus.txt > /tmp/test-g-b.txt
  15. Do a: diff --text /tmp/good-bus.txt /tmp/worse-bus.txt > /tmp/test-g-w.txt

And then report back here with the output of /tmp/test-g-b.txt and /tmp/test-g-w.txt

  • Thanks, the output is identical before connection and after disconnection of the drive. I've added the diff of output while connected to my question. – Ian Mackinnon Nov 17 '14 at 17:40
  • Could you do a: lspci | grep USB and post the output back here too? – Fabby Nov 18 '14 at 5:02
  • (previous needed to do a reset of the disk bus only and not the entire bus) – Fabby Nov 18 '14 at 5:08
  • 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04); 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) ; 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) ; – Ian Mackinnon Nov 19 '14 at 7:48
  • I'm stumped! The only thing I find suspicious is that I cannot find anything on the vendor for the USB enclosure... Do you have another enclosure you can try this hard disk in??? – Fabby Nov 19 '14 at 10:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.