Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
USB enumeration issue
619 views
Skip to first unread message
Matthew McAllister
Jan 23, 2023, 2:00:07 AM1/23/23
to
Hi all,
Since I upgraded packages a couple weeks ago, whenever I start my PC, I
have to wait 60 seconds for the kernel to enumerate USB devices. Here's
the log:
[ 8.815277] usb 1-5: device descriptor read/64, error -110
[ 24.431295] usb 1-5: device descriptor read/64, error -110
[ 24.943220] usb 1-5: new high-speed USB device number 3 using xhci_hcd
[ 30.319491] usb 1-5: device descriptor read/64, error -110
[ 45.935494] usb 1-5: device descriptor read/64, error -110
[ 46.044772] usb usb1-port5: attempt power cycle
[ 46.523221] usb 1-5: new high-speed USB device number 4 using xhci_hcd
[ 51.323562] usb 1-5: Device not responding to setup address.
[ 56.331406] usb 1-5: Device not responding to setup address.
[ 56.539402] usb 1-5: device not accepting address 4, error -71
[ 56.943221] usb 1-5: new high-speed USB device number 5 using xhci_hcd
[ 61.743759] usb 1-5: Device not responding to setup address.
[ 66.751609] usb 1-5: Device not responding to setup address.
[ 66.959391] usb 1-5: device not accepting address 5, error -71
[ 66.960945] usb usb1-port5: unable to enumerate USB device
This occurs when *no USB cables are plugged in*. The kernel is stalling
the entire boot process to enumerate some internal USB hub, I assume.
My front USB-C is broken as far as I can tell, so I tried unplugging the
header. The issue persisted.
The front USB 3.0 work correctly and I couldn't get the header unplugged
anyways, so I didn't test if that was the issue.
Any ideas what might be going on? Kernel is 6.1.4-1.
Matthew
Since I upgraded packages a couple weeks ago, whenever I start my PC, I
have to wait 60 seconds for the kernel to enumerate USB devices. Here's
the log:
[ 8.815277] usb 1-5: device descriptor read/64, error -110
[ 24.431295] usb 1-5: device descriptor read/64, error -110
[ 24.943220] usb 1-5: new high-speed USB device number 3 using xhci_hcd
[ 30.319491] usb 1-5: device descriptor read/64, error -110
[ 45.935494] usb 1-5: device descriptor read/64, error -110
[ 46.044772] usb usb1-port5: attempt power cycle
[ 46.523221] usb 1-5: new high-speed USB device number 4 using xhci_hcd
[ 51.323562] usb 1-5: Device not responding to setup address.
[ 56.331406] usb 1-5: Device not responding to setup address.
[ 56.539402] usb 1-5: device not accepting address 4, error -71
[ 56.943221] usb 1-5: new high-speed USB device number 5 using xhci_hcd
[ 61.743759] usb 1-5: Device not responding to setup address.
[ 66.751609] usb 1-5: Device not responding to setup address.
[ 66.959391] usb 1-5: device not accepting address 5, error -71
[ 66.960945] usb usb1-port5: unable to enumerate USB device
This occurs when *no USB cables are plugged in*. The kernel is stalling
the entire boot process to enumerate some internal USB hub, I assume.
My front USB-C is broken as far as I can tell, so I tried unplugging the
header. The issue persisted.
The front USB 3.0 work correctly and I couldn't get the header unplugged
anyways, so I didn't test if that was the issue.
Any ideas what might be going on? Kernel is 6.1.4-1.
Matthew
Alexander V. Makartsev
Jan 23, 2023, 4:00:06 AM1/23/23
to
Start troubleshooting process by unplugging all USB devices, doesn't
matter, if it's empty USB extension cable, external USB hub, or USB
thumb drive.
If you did that already and don't have USB-anything plugged in and still have the same issue, then this is a hardware problem, not a software problem.
If you unplugged everything and can't reproduce the issue anymore, then you have faulty USB device, which should be tested one by one, to determine which one is the culprit.
There is one additional thing, if your "PC" is a laptop, then it is possible there is an internal device inside that uses USB bus to function, e.g. WiFi adapter, WWAN adapter, etc.
In that case you need to open laptop to remove these devices.
If your laptop is HP or Lenovo brand, you should look for publicly available Disassembly and Maintenance Manuals for your model on manufacturer's official website.
If you did that already and don't have USB-anything plugged in and still have the same issue, then this is a hardware problem, not a software problem.
If you unplugged everything and can't reproduce the issue anymore, then you have faulty USB device, which should be tested one by one, to determine which one is the culprit.
There is one additional thing, if your "PC" is a laptop, then it is possible there is an internal device inside that uses USB bus to function, e.g. WiFi adapter, WWAN adapter, etc.
In that case you need to open laptop to remove these devices.
If your laptop is HP or Lenovo brand, you should look for publicly available Disassembly and Maintenance Manuals for your model on manufacturer's official website.
--
With kindest regards, Alexander.
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀
With kindest regards, Alexander.
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀
Tixy
Jan 23, 2023, 5:10:06 AM1/23/23
to
On Mon, 2023-01-23 at 13:54 +0500, Alexander V. Makartsev wrote:
[...]
On 23.01.2023 11:40, Matthew McAllister wrote:
> Start troubleshooting process by unplugging all USB devices,
>
He said he did that ;-)
> [...]
a desktop.
Another things to try is booting using an older kernel, presumably
there is one still installed as Debian doesn't automatically uninstall
kernels.
Also, looking at old kernel logs from back when it was working would be
useful (/var/log/kernel.N.gz where N if the biggest number there is).
Hopefully that will show what device is on usb 1-5 (though I believe
port numbers may change over time and depend on what's plugged in).
--
Tixy
[...]
> > [ 66.959391] usb 1-5: device not accepting address 5, error -71
> > [ 66.960945] usb usb1-port5: unable to enumerate USB device
> >
> > This occurs when *no USB cables are plugged in*. The kernel is
> > stalling the entire boot process to enumerate some internal USB hub, I
> > assume.
> >
> > My front USB-C is broken as far as I can tell, so I tried unplugging
> > the header. The issue persisted.
> >
> > The front USB 3.0 work correctly and I couldn't get the header
> > unplugged anyways, so I didn't test if that was the issue.
[...]
> > [ 66.960945] usb usb1-port5: unable to enumerate USB device
> >
> > This occurs when *no USB cables are plugged in*. The kernel is
> > stalling the entire boot process to enumerate some internal USB hub, I
> > assume.
> >
> > My front USB-C is broken as far as I can tell, so I tried unplugging
> > the header. The issue persisted.
> >
> > The front USB 3.0 work correctly and I couldn't get the header
> > unplugged anyways, so I didn't test if that was the issue.
On 23.01.2023 11:40, Matthew McAllister wrote:
> Start troubleshooting process by unplugging all USB devices,
>
> [...]
> There is one additional thing, if your "PC" is a laptop, then it is
> possible there is an internal device inside that uses USB bus to
> function, e.g. WiFi adapter, WWAN adapter, etc.
He also said he unplugged the header for the front USB so guess that's
> possible there is an internal device inside that uses USB bus to
> function, e.g. WiFi adapter, WWAN adapter, etc.
a desktop.
Another things to try is booting using an older kernel, presumably
there is one still installed as Debian doesn't automatically uninstall
kernels.
Also, looking at old kernel logs from back when it was working would be
useful (/var/log/kernel.N.gz where N if the biggest number there is).
Hopefully that will show what device is on usb 1-5 (though I believe
port numbers may change over time and depend on what's plugged in).
--
Tixy
Matthew McAllister
Jan 23, 2023, 11:20:06 PM1/23/23
to
> Also, looking at old kernel logs from back when it was working would be useful (/var/log/kernel.N.gz where N if the biggest number there is). Hopefully that will show what device is on usb 1-5 (though I believe port numbers may change over time and depend on what's plugged in).
That was the perfect piece of advice. I found the exact log where the issue began:
2023-01-06T20:20:28.225698-08:00 cockpit kernel: [ 25.515977] usb 1-5: Failed to suspend device, error -110
Coincidentally, this is also exactly when the bluetooth on my motherboard stopped working. (The WiFi is on the same MT7921K chipset and still works weirdly).
Can you suggest any steps other than straight-up RMA'ing the mobo? (That might fix the USB-C as well, heh.)
Matthew
Jeffrey Walton
Jan 23, 2023, 11:30:05 PM1/23/23
to
feels like papering over the problem. As far as I know, that's the
only way to turn off some radios and buses.
You may find something wrong with the motherboard during a visual
inspection. You can look for leaking capacitors and cracked solder
joints. But there's not much you can do besides replacing a cap or
reflowing solder.
You will probably be more satisfied if you send the board back for
repair. Or switch motherboard brands.
Jeff
Matthew McAllister
Jan 24, 2023, 12:00:06 AM1/24/23
to
Wouldn't the bluetooth device result in a PCIE error and not a USB error
though? The WiFi device shows as PCIE and it's on the same chip.
Thanks for your replies by the way.
Matthew
though? The WiFi device shows as PCIE and it's on the same chip.
Thanks for your replies by the way.
Matthew
Tixy
Jan 24, 2023, 3:40:06 AM1/24/23
to
On Mon, 2023-01-23 at 19:54 -0800, Matthew McAllister wrote:
> Coincidentally, this is also exactly when the bluetooth on my motherboard stopped working. (The WiFi is on the same MT7921K chipset and still works weirdly).
>
> Can you suggest any steps other than straight-up RMA'ing the mobo? (That might fix the USB-C as well, heh.)
I would still place my bet on a software problem.
> Coincidentally, this is also exactly when the bluetooth on my motherboard stopped working. (The WiFi is on the same MT7921K chipset and still works weirdly).
>
> Can you suggest any steps other than straight-up RMA'ing the mobo? (That might fix the USB-C as well, heh.)
Was the boot with the first time of failure the same kernel version and
wifi firmware as the previous successful boot? If the problem stated
with a new kernel or firmware version then that would be a smoking gun,
and you could prove it by booting the earlier kernel or reverting
firmware.
--
Tixy
Tixy
Jan 24, 2023, 3:50:06 AM1/24/23
to
On Mon, 2023-01-23 at 19:54 -0800, Matthew McAllister wrote:
> > Also, looking at old kernel logs from back when it was working
> > would be useful (/var/log/kernel.N.gz where N if the biggest number
> > there is). Hopefully that will show what device is on usb 1-5
> > (though I believe port numbers may change over time and depend on
> > what's plugged in).
>
> That was the perfect piece of advice. I found the exact log where the
> issue began:
>
> 2023-01-06T20:20:28.225698-08:00 cockpit kernel: [ 25.515977] usb 1-5: Failed to suspend device, error -110
>
What would be useful is the log of the boot before that, where usb 1-5
> > would be useful (/var/log/kernel.N.gz where N if the biggest number
> > there is). Hopefully that will show what device is on usb 1-5
> > (though I believe port numbers may change over time and depend on
> > what's plugged in).
>
> That was the perfect piece of advice. I found the exact log where the
> issue began:
>
> 2023-01-06T20:20:28.225698-08:00 cockpit kernel: [ 25.515977] usb 1-5: Failed to suspend device, error -110
>
worked, to see log messages for 'usb 1-5' to find out what it is.
--
Tixy
Tixy
Jan 24, 2023, 4:20:06 AM1/24/23
to
On Mon, 2023-01-23 at 19:54 -0800, Matthew McAllister wrote:
> > Also, looking at old kernel logs from back when it was working
> > would be useful (/var/log/kernel.N.gz where N if the biggest number
> > there is). Hopefully that will show what device is on usb 1-5
> > (though I believe port numbers may change over time and depend on
> > what's plugged in).
>
> That was the perfect piece of advice. I found the exact log where the
> issue began:
>
> 2023-01-06T20:20:28.225698-08:00 cockpit kernel: [ 25.515977] usb 1-5: Failed to suspend device, error -110
That timestamp is half a day before linux 6.1 accepted into unstable
> > would be useful (/var/log/kernel.N.gz where N if the biggest number
> > there is). Hopefully that will show what device is on usb 1-5
> > (though I believe port numbers may change over time and depend on
> > what's plugged in).
>
> That was the perfect piece of advice. I found the exact log where the
> issue began:
>
> 2023-01-06T20:20:28.225698-08:00 cockpit kernel: [ 25.515977] usb 1-5: Failed to suspend device, error -110
[1] so in theory the problem started before the new kernel, but the
timing looks suspicious, so I think comparing the first log you have
for booting with 6.1 with the last log with 6.0 would be invaluable.
(The device numbers could change between kernel versions if enumeration
order changed, so that TIMEOUT error (-110) could be related to a
different device).
Also, just try booting using linux 6.0 to see if that fixes anything.
That still seems to available, so if you uninstalled it, it can be
reinstalled.
[1] https://tracker.debian.org/news/1406376/accepted-linux-614-1-source-into-unstable/
--
Tixy
Matthew McAllister
Jan 24, 2023, 11:00:06 PM1/24/23
to
> Also, just try booting using linux 6.0 to see if that fixes anything. That still seems to available, so if you uninstalled it, it can be reinstalled.
That is great advice, but before starting the thread I had already tried booting 5.10, 5.19, 6.0, and 6.1 to no avail.
I was running 6.0.0-4-amd64 both before and after the device failed. I did upgrade to 6.0.0-6-amd64 the day after. Didn't upgrade to 6.1 until 2023-01-21.
BTW, this is what the logs contained when the device was last successfully started. (It is indeed the bluetooth chip; no idea why it's not a PCI device.)
2023-01-04T23:44:08.519572-08:00 cockpit kernel: [ 3.927596] usb 1-5: new high-speed USB device number 3 using xhci_hcd
2023-01-04T23:44:08.519572-08:00 cockpit kernel: [ 4.051608] ata3: SATA link down (SStatus 0 SControl 330)
2023-01-04T23:44:08.519572-08:00 cockpit kernel: [ 4.173060] usb 1-5: New USB device found, idVendor=0e8d, idProduct=0608, bcdDevice= 1.00
2023-01-04T23:44:08.519573-08:00 cockpit kernel: [ 4.173065] usb 1-5: New USB device strings: Mfr=5, Product=6, SerialNumber=7
2023-01-04T23:44:08.519573-08:00 cockpit kernel: [ 4.173067] usb 1-5: Product: Wireless_Device
2023-01-04T23:44:08.519573-08:00 cockpit kernel: [ 4.173068] usb 1-5: Manufacturer: MediaTek Inc.
2023-01-04T23:44:08.519574-08:00 cockpit kernel: [ 4.173069] usb 1-5: SerialNumber: 000000000
Theoretically, I guess the kernel could have put the device into an unrecoverable state, even after power cycling, but that's more of a question for an expert. Not to jump to conclusions, but this is starting to sound like a random hardware failure to me. The mobo is still only 3 months old.
The one other thing I did try is flipping some XHCI handoff setting in my BIOS, but that didn't help either sadly.
Matthew
Tixy
Jan 25, 2023, 3:10:06 AM1/25/23
to
On Tue, 2023-01-24 at 19:36 -0800, Matthew McAllister wrote:
[...]
clutching at straws here, as I don't think they use the bluetooth
standard). I have wireless devices on one of my machines and the
receiver for the PC is a tiny USB device that only sticks out about 5mm
from the case, just wondered if you have such a thing plugged in and
overlooked.
--
Tixy
[...]
> BTW, this is what the logs contained when the device was last
> successfully started. (It is indeed the bluetooth chip; no idea why
> it's not a PCI device.)
My final idea: have you used a wireless keyboard or mouse? (I'm
> successfully started. (It is indeed the bluetooth chip; no idea why
> it's not a PCI device.)
clutching at straws here, as I don't think they use the bluetooth
standard). I have wireless devices on one of my machines and the
receiver for the PC is a tiny USB device that only sticks out about 5mm
from the case, just wondered if you have such a thing plugged in and
overlooked.
--
Tixy
Tixy
Jan 25, 2023, 3:20:05 AM1/25/23
to
On Wed, 2023-01-25 at 08:06 +0000, Tixy wrote:
> My final idea: have you used a wireless keyboard or mouse?
or wireless headphones.
> My final idea: have you used a wireless keyboard or mouse?
David
Jan 25, 2023, 3:40:06 AM1/25/23
to
On Wed, 25 Jan 2023 at 14:54, Matthew McAllister
<matthew.mc...@gmail.com> wrote:
> BTW, this is what the logs contained when the device was last successfully started. (It is indeed the bluetooth chip; no idea why it's not a PCI device.)
>
> 2023-01-04T23:44:08.519572-08:00 cockpit kernel: [ 3.927596] usb 1-5: new high-speed USB device number 3 using xhci_hcd
> 2023-01-04T23:44:08.519572-08:00 cockpit kernel: [ 4.051608] ata3: SATA link down (SStatus 0 SControl 330)
> 2023-01-04T23:44:08.519572-08:00 cockpit kernel: [ 4.173060] usb 1-5: New USB device found, idVendor=0e8d, idProduct=0608, bcdDevice= 1.00
> 2023-01-04T23:44:08.519573-08:00 cockpit kernel: [ 4.173065] usb 1-5: New USB device strings: Mfr=5, Product=6, SerialNumber=7
> 2023-01-04T23:44:08.519573-08:00 cockpit kernel: [ 4.173067] usb 1-5: Product: Wireless_Device
> 2023-01-04T23:44:08.519573-08:00 cockpit kernel: [ 4.173068] usb 1-5: Manufacturer: MediaTek Inc.
> 2023-01-04T23:44:08.519574-08:00 cockpit kernel: [ 4.173069] usb 1-5: SerialNumber: 000000000
Hi, how does that compare with the output of (as root)
<matthew.mc...@gmail.com> wrote:
> BTW, this is what the logs contained when the device was last successfully started. (It is indeed the bluetooth chip; no idea why it's not a PCI device.)
>
> 2023-01-04T23:44:08.519572-08:00 cockpit kernel: [ 3.927596] usb 1-5: new high-speed USB device number 3 using xhci_hcd
> 2023-01-04T23:44:08.519572-08:00 cockpit kernel: [ 4.051608] ata3: SATA link down (SStatus 0 SControl 330)
> 2023-01-04T23:44:08.519572-08:00 cockpit kernel: [ 4.173060] usb 1-5: New USB device found, idVendor=0e8d, idProduct=0608, bcdDevice= 1.00
> 2023-01-04T23:44:08.519573-08:00 cockpit kernel: [ 4.173065] usb 1-5: New USB device strings: Mfr=5, Product=6, SerialNumber=7
> 2023-01-04T23:44:08.519573-08:00 cockpit kernel: [ 4.173067] usb 1-5: Product: Wireless_Device
> 2023-01-04T23:44:08.519573-08:00 cockpit kernel: [ 4.173068] usb 1-5: Manufacturer: MediaTek Inc.
> 2023-01-04T23:44:08.519574-08:00 cockpit kernel: [ 4.173069] usb 1-5: SerialNumber: 000000000
lsusb -v -s 1:5
today?
Not that I expect this will fix anything, just curious :/
Matthew McAllister
Jan 27, 2023, 1:50:07 AM1/27/23
to
I get a completely different device:
Bus 001 Device 005: ID 046d:081b Logitech, Inc. Webcam C310
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x046d Logitech, Inc.
idProduct 0x081b Webcam C310
bcdDevice 0.12
iManufacturer 0
iProduct 0
iSerial 2 46417950
bNumConfigurations 1
The MediaTek device is nowhere to be found.
Matthew
Bus 001 Device 005: ID 046d:081b Logitech, Inc. Webcam C310
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x046d Logitech, Inc.
idProduct 0x081b Webcam C310
bcdDevice 0.12
iManufacturer 0
iProduct 0
iSerial 2 46417950
bNumConfigurations 1
The MediaTek device is nowhere to be found.
Matthew
Matthew McAllister
Jan 27, 2023, 2:00:07 AM1/27/23
to
> > My final idea: have you used a wireless keyboard or mouse?
>
> or wireless headphones.
Nope, I don't have any other USB devices. Everything is connected through a hub, so I only have one cable plugged in. I didn't miss anything.
>
> or wireless headphones.
I think it's pretty likely at this point my mobo is FUBAR. I'm going to try and RMA it. I built my own PC so it's no surprise at least one part would be a dud.
Thanks for everyone's suggestions.
Matthew
0 new messages