syslog flooded with these USB messages, but device doesn't exist

[Jeff Lane ]

For a while now (several kernels back starting with 4.15, IIRC) syslog and dmesg have been flooded with these and similar messages:

[914961.613273] usb 3-3: Failed to suspend device, error -71
[914961.613483] usb 3-3: Failed to suspend device, error -71
[914964.741387] usb 3-3: Failed to suspend device, error -71
[914964.741706] usb 3-3: Failed to suspend device, error -71
[914968.189402] usb 3-3: Failed to suspend device, error -71
[914968.189715] usb 3-3: Failed to suspend device, error -71

There's nothing on usb 3-3, just a port:

/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
    |__ Port 3: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M

So I tried disabling autosuspend:
root@galactica:~# cat /sys/bus/usb/devices/3-3/power/autosuspend
0
root@galactica:~# echo 1 > /sys/bus/usb/devices/3-3/power/autosuspend
root@galactica:~# cat /sys/bus/usb/devices/3-3/power/autosuspend
1

but I still get the "Failed to suspend messages" flooding syslog

According to the kernel documentation, I should be able to set power/control to on to disable autosuspend:
https://www.kernel.org/doc/html/v4.14/driver-api/usb/power-management.html
power/control

This file contains one of two words: on or auto. You can write those words to the file to change the device’s setting.

on means that the device should be resumed and autosuspend is not allowed. (Of course, system suspends are still allowed.)
auto is the normal state in which the kernel is allowed to autosuspend and autoresume the device.
(In kernels up to 2.6.32, you could also specify suspend, meaning that the device should remain suspended and autoresume was not allowed. This setting is no longer supported.)

power/autosuspend_delay_ms

This file contains an integer value, which is the number of milliseconds the device should remain idle before the kernel will autosuspend it (the idle-delay time). The default is 2000. 0 means to autosuspend as soon as the device becomes idle, and negative values mean never to autosuspend. You can write a number to the file to change the autosuspend idle-delay time.
Writing -1 to power/autosuspend_delay_ms and writing on to power/control do essentially the same thing – they both prevent the device from being autosuspended. Yes, this is a redundancy in the API.

So I tried both of these suggestions:
root@galactica:~# cat /sys/bus/usb/devices/usb3/power/control
on
root@galactica:~# cat /sys/bus/usb/devices/usb3/power/autosuspend_delay_ms
-1
but the Failed to Suspend messages persist.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: linux-image-5.0.0-31-generic 5.0.0-31.33~18.04.1
ProcVersionSignature: Ubuntu 5.0.0-31.33~18.04.1-generic 5.0.21
Uname: Linux 5.0.0-31-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.9-0ubuntu7.7
Architecture: amd64
CurrentDesktop: Unity:Unity7:ubuntu
Date: Mon Oct 28 11:10:15 2019
InstallationDate: Installed on 2016-02-11 (1354 days ago)
InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160210)
SourcePackage: linux-signed-hwe
UpgradeStatus: No upgrade log present (probably fresh install)

[Jeff Lane  (bladernr)]

Note, this was a problem on the 4.15 GA kernel as well. It's entirely reasonable that this is something on that USB controller going bad, however, none of the options I can find to disable that port work either.

[Doki (lkishalmi)]

I've attached an egpu over thunderbolt to my Galago Pro and started to see these messages. The connected bluetooth devices started to freeze for 1-2 sec idle time from time to time, then these messages appear in the syslog. The strange thing, that the USB devices plugged into the egpu case are working flawlessly (one webcam and a mouse). I've tested the 20.04 dev iso as well. it has the same issue.

It seems if I have a continuous use of bluetooth (like playing audio with it) this issue does not happen.

[Doki (lkishalmi)]

Just one additional info. This issue stops after the first suspend/resume cycle. So I have no longer need to constantly play something over bluetooth.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Mike Meehan (mjmeehan)]

Suspending and resuming stopped the problem briefly, but it reoccurred for me. I don't think it's a good work-around. Thanks for the tip anyway!