powering off an usb3 device causes kernel to resume immediately after suspend

[b3nmore]

After powering off an usb3 disk (e.g. udisksctl power-off -b /dev/sdc) the system immediately resumes after suspend. This does not happen, if I umount the device and disconnect it. Usb devices < 3.0 seem not to be affected.

How to reproduce:
1) plug an usb3 device to an usb3 port and mount it
2) umount it
3) power it off: udisksctl power-off -b /dev/sdX
4) suspend: (e.g. echo mem > /sys/power/state)

result: system suspends and immediately resumes

Package: udisks2 (2.1.3-1)

[Martin Pitt (pitti)]

can you please do "dmesg > /tmp/dmesg.txt" after such a resume and attach /tmp/dmesg.txt here? Thanks!

[b3nmore (b3nmore)]

> can you please do "dmesg > /tmp/dmesg.txt" after such a resume and attach /tmp/dmesg.txt here? Thanks!

Rebooted and executed the steps mentioned above. dmesg is attached.

[b3nmore (b3nmore)]

I did some further testing with following results: I can reestablish the correct suspend behavior by plugging in the drive, mounting, unmounting and unplugging the drive without powering down. This has to be done on exactly the same port, which triggered the misbehavior (other ports will not work).

[b3nmore (b3nmore)]

I've tested kernel 3.16-rc7 from mainline, with the same results.

Another thing I've tested, is disabling acpi wakeups for usb related devices: If I disable wakeup for ALL usb related devices (in my case EHC1, EHC2, XHC) suspend works correctly. Any other combination (e.g. disable only XHC and leave EHCx enabled) prevents suspending.

Attached is the dmesg output of a successful suspend/resume using this workaround.

/proc/acpi/wakeup for successful suspend looks in my case:
$ cat /proc/acpi/wakeup
Device S-state Status Sysfs node
UAR1 S4 *disabled pnp:00:0b
RP01 S4 *disabled pci:0000:00:1c.0
PXSX S4 *disabled
RP03 S4 *disabled pci:0000:00:1c.2
PXSX S4 *enabled pci:0000:03:00.0
GLAN S4 *disabled
EHC1 S4 *disabled pci:0000:00:1d.0
EHC2 S4 *disabled pci:0000:00:1a.0
XHC S4 *disabled pci:0000:00:14.0
HDEF S4 *disabled pci:0000:00:1b.0
PEG0 S4 *disabled pci:0000:00:01.0
PEGP S4 *disabled
PEG1 S4 *disabled
PEG2 S4 *disabled

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.16 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.16-utopic/

[b3nmore (b3nmore)]

> Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.16 kernel[0].

Done. No changes.

[b3nmore (b3nmore)]

Tested again with v3.17.1-utopic: still the same issue.

[Kaarel (krlk89)]

I've filed a bug report about the same issue (#1486581) and found two other bug reports about this (#1454253 and #1389990).

[b3nmore (b3nmore)]

Tested again with latest mainline kernel (4.4.0-040400rc2-generic): Still the same issue.