USB device enumeration failure after a certain amount of uptime

USB device enumeration failure after a certain amount of uptime

[laycookie]

Hello, this is my first time reporting a bug to the Linux mailing list so if I make any mistakes on how the report should be formatted I deeply apologies, and I would really appreciate feedback on how I could have made it better.

I have recently installed a pcie capture card (AVerMedia GC575) into my computer, which from my understanding is recognized as a USB hub, to which a USB “virtual capture card” gets connected, as well as an RGB controller, and while there is no problems with the RGB controller, the capture card itself disconnects after some uptime.

When the computer boots up, or wakes up from hibernation, the capture card spits out some errors but ultimately ends up connecting, and functioning properly with the following being logged in to the dmesg.

[73087.256972] usb usb4-port1: attempt power cycle
[73087.681433] usb 4-1: Device not responding to setup address.
[73087.887446] usb 4-1: Device not responding to setup address.
[73088.095031] usb 4-1: device not accepting address 67, error -71
[73088.580035] usb 4-1: new SuperSpeed USB device number 68 using xhci_hcd
[73088.649577] usb 4-1: LPM exit latency is zeroed, disabling LPM.

However after some uptime since the boot/hibernation the capture card ends up getting disconnected with the following being logged.

[73491.691281] usb 4-1: Device not responding to setup address.
[73491.898772] usb 4-1: Device not responding to setup address.
[73492.106227] usb 4-1: device not accepting address 68, error -71
[73492.857630] usb 4-1: USB disconnect, device number 68
[73493.184176] usb 4-1: new SuperSpeed USB device number 69 using xhci_hcd
[73498.305648] usb 4-1: device descriptor read/8, error -110
[73498.409287] usb 4-1: new SuperSpeed USB device number 69 using xhci_hcd
73513.767567] usb 4-1: device descriptor read/8, error -110
[73514.056885] usb 4-1: Device not responding to setup address.
[73514.265895] usb 4-1: Device not responding to setup address.
[73514.473459] usb 4-1: device not accepting address 70, error -71
[73514.475317] usb usb4-port1: attempt power cycle
[73514.903850] usb 4-1: Device not responding to setup address.
[73515.113863] usb 4-1: Device not responding to setup address.
[73515.322369] usb 4-1: device not accepting address 71, error -71
[73515.817911] usb 4-1: new SuperSpeed USB device number 72 using xhci_hcd
[73520.833734] usb 4-1: device descriptor read/8, error -110
[73520.937385] usb 4-1: new SuperSpeed USB device number 72 using xhci_hcd
[73536.294619] usb 4-1: device descriptor read/8, error -110
[73536.412431] usb usb4-port1: unable to enumerate USB device

I managed to track down the source of all the following errors with the exception being “Device not responding to setup address.” to being in the following file:
drivers/usb/core/hub.c

However sadly I’m still very much learning about linux, so I didn’t yet progress much then this. If anyone has any idea of what is going on I would really appreciate a small explanation, or pointers to where I should look. Currently I’m trying to find out what error -71, and -110 correspond.
The following was tested on kernel version 6.14.0-rc6, and the same behavior was observed on kernel versions 6.6.x.

Re: USB device enumeration failure after a certain amount of uptime

[Michał Pecio]

> Hello, this is my first time reporting a bug to the Linux mailing
> list so if I make any mistakes on how the report should be formatted
> I deeply apologies, and I would really appreciate feedback on how I
> could have made it better.
>
> I have recently installed a pcie capture card (AVerMedia GC575) into
> my computer, which from my understanding is recognized as a USB hub,
> to which a USB “virtual capture card” gets connected, as well as an
> RGB controller, and while there is no problems with the RGB
> controller, the capture card itself disconnects after some uptime.

I would guess it's a PCIe-based USB 3.1 controller (ASMedia ASM3142?)
and some USB chips permanently wired to it on the same board, you could
investigate with 'lspci' and 'lsusb -t' (when everything is working).

> When the computer boots up, or wakes up from hibernation, the capture
> card spits out some errors but ultimately ends up connecting, and
> functioning properly with the following being logged in to the dmesg.
>
> [73087.256972] usb usb4-port1: attempt power cycle
> [73087.681433] usb 4-1: Device not responding to setup address.
> [73087.887446] usb 4-1: Device not responding to setup address.
> [73088.095031] usb 4-1: device not accepting address 67, error -71
> [73088.580035] usb 4-1: new SuperSpeed USB device number 68 using xhci_hcd
> [73088.649577] usb 4-1: LPM exit latency is zeroed, disabling LPM.
>
> However after some uptime since the boot/hibernation the capture card
> ends up getting disconnected with the following being logged.
>
> [73491.691281] usb 4-1: Device not responding to setup address.
> [73491.898772] usb 4-1: Device not responding to setup address.
> [73492.106227] usb 4-1: device not accepting address 68, error -71
> [73492.857630] usb 4-1: USB disconnect, device number 68
> [73493.184176] usb 4-1: new SuperSpeed USB device number 69 using xhci_hcd

Is this a complete log? And the device was really working during those
six minutes before "setup address" failure? Usually, address setup
happens once immediately after device connection, not sure what would
lead to it being repeated later.

Regards,
Michal

Re: USB device enumeration failure after a certain amount of uptime

[laycookie]

> I would guess it's a PCIe-based USB 3.1 controller (ASMedia ASM3142?)
> and some USB chips permanently wired to it on the same board, you could
> investigate with 'lspci' and 'lsusb -t' (when everything is working).

Results of `lsusb -t` specifically for the capture card excluding the RGB controller.
```
/:  Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 10000M
    |__ Port 001: Dev 002, If 0, Class=Video, Driver=uvcvideo, 5000M
    |__ Port 001: Dev 002, If 1, Class=Video, Driver=uvcvideo, 5000M
    |__ Port 001: Dev 002, If 2, Class=Audio, Driver=snd-usb-audio, 5000M
    |__ Port 001: Dev 002, If 3, Class=Audio, Driver=snd-usb-audio, 5000M
```
Related from what `lspci` is emitting.
```
08:00.0 USB controller: ASMedia Technology Inc. ASM2142/ASM3142 USB 3.1 Host Controller
09:00.0 USB controller: ASMedia Technology Inc. ASM2142/ASM3142 USB 3.1 Host Controller
```

> > When the computer boots up, or wakes up from hibernation, the capture
> > card spits out some errors but ultimately ends up connecting, and
> > functioning properly with the following being logged in to the dmesg.
> >
> > [73087.256972] usb usb4-port1: attempt power cycle
> > [73087.681433] usb 4-1: Device not responding to setup address.
> > [73087.887446] usb 4-1: Device not responding to setup address.
> > [73088.095031] usb 4-1: device not accepting address 67, error -71
> > [73088.580035] usb 4-1: new SuperSpeed USB device number 68 using xhci_hcd
> > [73088.649577] usb 4-1: LPM exit latency is zeroed, disabling LPM.
> >
> > However after some uptime since the boot/hibernation the capture card
> > ends up getting disconnected with the following being logged.
> >
> > [73491.691281] usb 4-1: Device not responding to setup address.
> > [73491.898772] usb 4-1: Device not responding to setup address.
> > [73492.106227] usb 4-1: device not accepting address 68, error -71
> > [73492.857630] usb 4-1: USB disconnect, device number 68
> > [73493.184176] usb 4-1: new SuperSpeed USB device number 69 using xhci_hcd
>
>
> Is this a complete log? And the device was really working during those
> six minutes before "setup address" failure? Usually, address setup
> happens once immediately after device connection, not sure what would
> lead to it being repeated later.
>
> Regards,
> Michal

Yes, the only thing I did is remove all logs that were not prefixed with `usb 4-1:` during the boot/wake (there were no other events leading to disconnect at all), and the PC was on during those 6 minutes. Usually however it takes around 20 minutes to 3 hours for this behavior to occur. Not sure if it has any relevance but specifically in that session of testing my computer had a fairly long uptime since boot, and the disconnect behavior was consistently happening after approximately 6 minutes when I was waking up the computer from hibernation, however after a full power off, power on cycle it went back to failing in 20 minutes to 3 hours. 

I also discovered that apparently if I stream from the capture card to some application it never disconnects, or at least I have never encountered it disconnecting.

Dennis Lonoshchuk

Re: USB device enumeration failure after a certain amount of uptime

[Michał Pecio]

> > Is this a complete log? And the device was really working during
> > those six minutes before "setup address" failure? Usually, address
> > setup happens once immediately after device connection, not sure
> > what would lead to it being repeated later.

Nevermind, it looks like address setup is also done on device reset,
so that's what may be happening here.

Although now I'm not sure what would request a reset of an idle device
and why. Apparently not uvcvideo/snd-usb-audio drivers because they
only ever seem to reset a few specific USB IDs. Maybe USB core did it
for some reason.

You could try enabling usbcore dynamic debug:
echo 'module usbcore +p' >/proc/dynamic_debug/control

and see if there is some noise in dmesg when the device is idle or
shortly before it fails. Note that this enables debug logging on all
USB buses in the system. Change +p to -p to turn it off.

> I also discovered that apparently if I stream from the capture card
> to some application it never disconnects, or at least I have never
> encountered it disconnecting.

I guess a simple test is to leave it running overnight with some webcam
viewer software or similar. If it survives, and then fails shortly
after turning off the software, that looks like an idle state problem.

Maybe autosuspend is involved? Totally guessing. It can be disabled:
echo -1 >/sys/bus/usb/devices/4-1/power/autosuspend_delay_ms

This is quite unlikely, I think, but sometimes those USB controllers
can break and stop performing transfers correctly. You could see if
things return to normal after re-initializing the controller:

echo 0000:08:00.0 >/sys/bus/pci/drivers/xhci_hcd/unbind
echo 0000:08:00.0 >/sys/bus/pci/drivers/xhci_hcd/bind

assuming that this card is 08:00.0 and not 09:00.0 (or something else).


Michal