usb 1-9: device descriptor read/64, error -110

MattSr · Yesterday 03:40:47

So I noticed that my CachyOS boot was being held up each time by:

Stopping Rule-based Manager for Device Events and Files (15s / 1min 30s)

Usually taking around 1min 10secs before moving on with the rest of the boot.

Here is my journal:

Jul 26 19:59:20 cachyos systemd[1]: Stopping Rule-based Manager for Device Events and Files...
Jul 26 19:59:20 cachyos systemd[1]: systemd-bsod.service: Deactivated successfully.
Jul 26 19:59:20 cachyos systemd[1]: Stopped Display Boot-Time Emergency Messages In Full Screen.
Jul 26 19:59:20 cachyos systemd[1]: initrd-cleanup.service: Deactivated successfully.
Jul 26 19:59:20 cachyos systemd[1]: Finished Cleaning Up and Shutting Down Daemons.
Jul 26 19:59:20 cachyos systemd[1]: Finished Plymouth switch root service.
Jul 26 19:59:36 cachyos kernel: usb 1-9: device descriptor read/64, error -110
Jul 26 19:59:36 cachyos kernel: usb 1-9: new high-speed USB device number 5 using xhci_hcd
Jul 26 19:59:42 cachyos kernel: usb 1-9: device descriptor read/64, error -110
Jul 26 19:59:58 cachyos kernel: usb 1-9: device descriptor read/64, error -110
Jul 26 19:59:58 cachyos kernel: usb usb1-port9: attempt power cycle
Jul 26 19:59:58 cachyos kernel: usb 1-9: new high-speed USB device number 6 using xhci_hcd
Jul 26 20:00:03 cachyos kernel: usb 1-9: Device not responding to setup address.
Jul 26 20:00:08 cachyos kernel: usb 1-9: Device not responding to setup address.
Jul 26 20:00:08 cachyos kernel: usb 1-9: device not accepting address 6, error -71
Jul 26 20:00:09 cachyos kernel: usb 1-9: new high-speed USB device number 7 using xhci_hcd
Jul 26 20:00:13 cachyos kernel: usb 1-9: Device not responding to setup address.
Jul 26 20:00:17 cachyos systemd-udevd[349]: usb1: Worker [356] processing SEQNUM=2361 is taking a long time.
Jul 26 20:00:18 cachyos kernel: usb 1-9: Device not responding to setup address.
Jul 26 20:00:19 cachyos kernel: usb 1-9: device not accepting address 7, error -71
Jul 26 20:00:19 cachyos kernel: usb usb1-port9: unable to enumerate USB device
Jul 26 20:00:19 cachyos systemd[1]: systemd-udevd.service: Deactivated successfully.
Jul 26 20:00:19 cachyos systemd[1]: Stopped Rule-based Manager for Device Events and Files.

Through some searching around on the internet, I found that cutting PSU power for at least 10 seconds and then starting up stops the error from showing up for one boot sequence.
Journal:

Jul 26 20:23:31 cachyos systemd[1]: Stopping Rule-based Manager for Device Events and Files...
Jul 26 20:23:31 cachyos systemd[1]: systemd-bsod.service: Deactivated successfully.
Jul 26 20:23:31 cachyos systemd[1]: Stopped Display Boot-Time Emergency Messages In Full Screen.
Jul 26 20:23:31 cachyos systemd[1]: initrd-cleanup.service: Deactivated successfully.
Jul 26 20:23:31 cachyos systemd[1]: Finished Cleaning Up and Shutting Down Daemons.
Jul 26 20:23:31 cachyos systemd[1]: systemd-udevd.service: Deactivated successfully.
Jul 26 20:23:31 cachyos systemd[1]: Stopped Rule-based Manager for Device Events and Files.

I also noticed that it seems like my setup seems to post faster before handing off to the boot loader for this boot situation as well.

❯ lsusb
Bus 001 Device 000: ID 0489:e13a Foxconn / Hon Hai Wireless_Device
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0fd9:0080 Elgato Systems GmbH Stream Deck MK.2
Bus 001 Device 003: ID 1532:0a15 Razer USA, Ltd RZ06-0199, Gaming Controller [Wolverine Tournament Edition]
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 174c:2074 ASMedia Technology Inc. ASM1074 High-Speed hub
Bus 003 Device 003: ID 174c:2174 ASMedia Technology Inc. ASMT2307
Bus 003 Device 004: ID 0b05:1b9b ASUSTek Computer, Inc. USB Audio
Bus 003 Device 005: ID 046d:0b0b Logitech, Inc. A50 X
Bus 003 Device 006: ID 1532:00a4 Razer USA, Ltd Razer Mouse Dock Pro
Bus 003 Device 007: ID 1532:028d Razer USA, Ltd Razer BlackWidow V4 Pro
Bus 003 Device 008: ID 1532:0e03 Razer USA, Ltd Gaming Webcam [Kiyo]
Bus 003 Device 009: ID 0b05:1aa6 ASUSTek Computer, Inc. AURA LED Controller
Bus 003 Device 010: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 003 Device 011: ID 1b1c:0c10 Corsair Commander PRO
Bus 003 Device 012: ID 1044:7a46 Chu Yuen Enterprise Co., Ltd USB-MASS STORAGE
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 004 Device 002: ID 174c:3074 ASMedia Technology Inc. ASM1074 SuperSpeed hub
Bus 004 Device 003: ID 174c:3174 ASMedia Technology Inc. ASMT2307
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 009 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 010 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 011 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

My hardware setup is:
Mobo: ASUS X870E-E
CPU: Ryzen 9 7350X
Memory: 2x Corsair Vengeance 32GB 4800mhz

This error persists even after disconnecting literally all other hardware from the motherboard other than the SSD, power, and a monitor via HDMI (motherboard slot while testing without the GPU connected). Even my cpu cooler was only connected to power and had no data connection to the mobo.
I've also tried resetting BIOS settings to defaults. I am on BIOS version 2402 (most up to date), but this issue has persisted through other previous BIOS versions as well.

At this point, I don't see any other possibilities other than it being a motherboard defect, but hoping maybe someone else knows something I don't.

Edit: Just realized I'm posting a CachyOS issue on the Arch forums. I apologize in advance if that's not something that's allowed.

Last edited by MattSr (Yesterday 06:50:31)

seth · Yesterday 06:53:17

https://bbs.archlinux.org/misc.php?action=rules

USB is a bus, not a plug - bluetooth?
https://bbs.archlinux.org/viewtopic.php … 1#p2305291

mmy8x · Yesterday 07:22:10

Frankly yes, but it's same thing on every distribution and it affects many users here too. Apparently, even your boot firmware wastes a few seconds trying to enumerate this device.

Your case is useful because it's reproducible every time. I wonder if you could check if it's possible that kernel drivers brick these bluetooth chips?

1. turn off, disconnect the PSU, turn on, boot Linux
2. run dmesg | grep 1-9 to see what this device is, you should see its USB IDs
3. run lsusb -tv to see which driver binds to it, probably btusb or some such
4. blacklist the driver
5. repeat 1
6. run lsusb -tv again to confirm the device is still there but the driver went away
7. see if you can reboot multiple times without delays

If you find evidence that it's a kernel bug, report it upstream because there is nothing anyone here can do with that.

Last edited by mmy8x (Yesterday 07:28:44)

MattSr · Yesterday 08:24:03

alright so...

❯ sudo dmesg | grep 1-9
[    2.296591] usb 1-9: new high-speed USB device number 4 using xhci_hcd
[    2.513861] usb 1-9: New USB device found, idVendor=0489, idProduct=e13a, bcdDevice= 1.00
[    2.513867] usb 1-9: New USB device strings: Mfr=5, Product=6, SerialNumber=7
[    2.513870] usb 1-9: Product: Wireless_Device
[    2.513871] usb 1-9: Manufacturer: MediaTek Inc.
[    2.513873] usb 1-9: SerialNumber: 000000000
[   13.089948] usb 1-9: reset high-speed USB device number 4 using xhci_hcd

This last line repeats a bunch of times after this point.

❯ lsusb -tv | grep -i "xhci_hcd"
/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/12p, 480M
/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/5p, 20000M/x2
/:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/12p, 480M
/:  Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/5p, 20000M/x2
/:  Bus 005.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 480M
/:  Bus 006.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 20000M/x2
/:  Bus 007.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 480M
/:  Bus 008.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 10000M
/:  Bus 009.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 480M
/:  Bus 010.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 10000M
/:  Bus 011.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/1p, 480M

❯ modprobe --showconfig | grep blacklist
blacklist xhci_hcd
blacklist iTCO_wdt
blacklist sp5100_tco
blacklist nouveau
blacklist nova_core
blacklist nova_drm
alias symbol:rtw89_fw_blacklist_default rtw89_core

Blacklisted xhci_hcd, but am still getting:

❯ lsusb -tv | grep -i "xhci_hcd"
/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/12p, 480M
/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/5p, 20000M/x2
/:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/12p, 480M
/:  Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/5p, 20000M/x2
/:  Bus 005.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 480M
/:  Bus 006.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 20000M/x2
/:  Bus 007.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 480M
/:  Bus 008.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 10000M
/:  Bus 009.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 480M
/:  Bus 010.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 10000M
/:  Bus 011.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/1p, 480M

Maybe I didn't blacklist correctly, or I blacklisted the wrong thing? Not sure.
However, I did go into my BIOS to disable my Bluetooth controller there and that did seem to resolve the issue, although obviously I can't use bluetooth (not that it was working previously). I didn't realize earlier that it was relevant, but I read somewhere that Linux doesn't support my motherboard's Mediatek MT7927 Wi-Fi and Bluetooth card currently, although it should be coming in 7.2.

Last edited by MattSr (Yesterday 08:41:28)

mmy8x · Yesterday 08:41:32

xhci_hcd is your USB host controller driver. To find device driver, try this instead:

lsusb -tv | grep -iB1 0489:e13a

0489:e13a is the IDs from dmesg. And of course the device must be functional (no boot delay, shows up in dmesg) for this to work.

MattSr · Yesterday 09:07:19

Thank you for the pointers.

❯ lsusb -tv | grep -iB1 0489:e13a
    |__ Port 009: Dev 004, If 0, Class=Wireless, Driver=[none], 480M
        ID 0489:e13a Foxconn / Hon Hai 
    |__ Port 009: Dev 004, If 1, Class=Wireless, Driver=btusb, 480M
        ID 0489:e13a Foxconn / Hon Hai 
    |__ Port 009: Dev 004, If 2, Class=Wireless, Driver=btusb, 480M
        ID 0489:e13a Foxconn / Hon Hai

❯ modprobe --showconfig | grep "blacklist btusb"
blacklist btusb

And after restarting:

❯ lsusb -tv | grep -iB1 0489:e13a
    |__ Port 009: Dev 004, If 0, Class=Wireless, Driver=[none], 480M
        ID 0489:e13a Foxconn / Hon Hai
    |__ Port 009: Dev 004, If 1, Class=Wireless, Driver=[none], 480M
        ID 0489:e13a Foxconn / Hon Hai
    |__ Port 009: Dev 004, If 2, Class=Wireless, Driver=[none], 480M
        ID 0489:e13a Foxconn / Hon Hai

I am now able to reboot freely without delays. Thank you!

Anyway, as I mentioned, it seems the true solution will probably be just waiting for support in a kernel update supporting the Mediatek MT7927.

Last edited by MattSr (Yesterday 09:31:34)

seth · Yesterday 14:30:25

The problem precedes any kernel modules, blacklisting btusb will not prevent "Device not responding to setup address"
In case this is a dual boot system, see the 3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.

MattSr · Yesterday 18:22:42

I can confirm that "Device not responding to setup address" does not show up in the journal anymore after enabling the Bluetooth controller and then blacklisting the driver in Linux.

Jul 27 11:17:48 cachyos systemd[1]: Stopping Rule-based Manager for Device Events and Files...
Jul 27 11:17:48 cachyos systemd[1]: systemd-bsod.service: Deactivated successfully.
Jul 27 11:17:48 cachyos systemd[1]: Stopped Display Boot-Time Emergency Messages In Full Screen.
Jul 27 11:17:48 cachyos systemd[1]: initrd-cleanup.service: Deactivated successfully.
Jul 27 11:17:48 cachyos systemd[1]: Finished Cleaning Up and Shutting Down Daemons.
Jul 27 11:17:48 cachyos systemd[1]: systemd-udevd.service: Deactivated successfully.
Jul 27 11:17:48 cachyos systemd[1]: Stopped Rule-based Manager for Device Events and Files.

Also of note, I am dual booting (with fast boot turned off) and with the proper windows/motherboard drivers installed, the Wi-Fi and Bluetooth do operate properly in Windows 11.

Edit: Mistakenly said "fast boot", meant to say "fast start".

Last edited by MattSr (Yesterday 19:47:27)

seth · Yesterday 19:43:23

nb. phrasing: "fast boot" is a completely irrelevant feature/option in your UEFI/BIOS - the problematic windows behavior is called "fast start" and needs to be disabled there.
Do the errors return if you unblacklist btusb?

mmy8x · Yesterday 19:56:10

MattSr wrote:

❯ modprobe --showconfig | grep "blacklist btusb"
blacklist btusb

And after restarting:

❯ lsusb -tv | grep -iB1 0489:e13a
    |__ Port 009: Dev 004, If 0, Class=Wireless, Driver=[none], 480M
        ID 0489:e13a Foxconn / Hon Hai
    |__ Port 009: Dev 004, If 1, Class=Wireless, Driver=[none], 480M
        ID 0489:e13a Foxconn / Hon Hai
    |__ Port 009: Dev 004, If 2, Class=Wireless, Driver=[none], 480M
        ID 0489:e13a Foxconn / Hon Hai

I am now able to reboot freely without delays. Thank you!

MattSr wrote:

Also of note, I am dual booting (with fast boot turned off) and with the proper windows/motherboard drivers installed, the Wi-Fi and Bluetooth do operate properly in Windows 11.

Looks like using btusb either immediately breaks this device or leaves it in a state where it will break on the next reboot without deep power cycle. Other MediaTek chips where this problem occurs sporadically may be similar story. Not sure if Windows is involved in any way.

If anyone wants to use these devices without such problems then well, you will need to work with upstream to figure out what goes wrong and fix the driver. One rumor I have seen is that Bluetooth drivers have some power management bugs, so perhaps disabling USB autosuspend would fix this issue without giving up Bluetooth functionality.

MattSr · Today 01:44:29

mmy8x wrote:

Looks like using btusb either immediately breaks this device or leaves it in a state where it will break on the next reboot without deep power cycle. Other MediaTek chips where this problem occurs sporadically may be similar story. Not sure if Windows is involved in any way.
If anyone wants to use these devices without such problems then well, you will need to work with upstream to figure out what goes wrong and fix the driver. One rumor I have seen is that Bluetooth drivers have some power management bugs, so perhaps disabling USB autosuspend would fix this issue without giving up Bluetooth functionality.

I concur. I did some testing after considering this and here is what I got:

Deep Power Cycle
Linux w/ blacklist (No boot errors).
|-> Linux w/ blacklist (No boot errors).
|-> Linux w/ no blacklist (No boot errors).
|-> Linux w/ no blacklist (Boot errors).
|-> Windows 11 (Working BT).

Deep Power Cycle
Windows 11 (Working BT).
|-> Linux w/ blacklist (No boot errors).
|-> Linux w/ no blacklist (No boot errors).
|-> Linux w/ no blacklist (Boot errors).
|-> Windows 11 (Working BT).

Each "|->" is a standard restart.

Regardless of a deep power cycle into Linux w/o the blacklisted btusb, booting into anything after has errors and the inability to use BT in Win11.
A deep power cycle into Linux w/ the blacklisted btusb or Win11, then into any other OS configuration seems to work fine.

Last edited by MattSr (Today 01:53:47)

Arch Linux

#1 Yesterday 03:40:47

usb 1-9: device descriptor read/64, error -110

#2 Yesterday 06:53:17

Re: usb 1-9: device descriptor read/64, error -110

#3 Yesterday 07:22:10

Re: usb 1-9: device descriptor read/64, error -110

#4 Yesterday 08:24:03

Re: usb 1-9: device descriptor read/64, error -110

#5 Yesterday 08:41:32

Re: usb 1-9: device descriptor read/64, error -110

#6 Yesterday 09:07:19

Re: usb 1-9: device descriptor read/64, error -110

#7 Yesterday 14:30:25

Re: usb 1-9: device descriptor read/64, error -110

#8 Yesterday 18:22:42

Re: usb 1-9: device descriptor read/64, error -110

#9 Yesterday 19:43:23

Re: usb 1-9: device descriptor read/64, error -110

#10 Yesterday 19:56:10

Re: usb 1-9: device descriptor read/64, error -110

#11 Today 01:44:29

Re: usb 1-9: device descriptor read/64, error -110

Board footer