[SOLVED] Consistent unusually long boot times due to usb dev timeouts

delulinv · 2026-01-21 14:29:01

I just installed arch following the install guide. I noticed the time it takes to boot (specifically between grub and tty) taking an entire minute.

systemd-analyze
Startup finished in 57.136s (firmware) + 3.032s (loader) + 5.589s (kernel) + 1min 5.156s (initrd) + 6.501s (userspace) = 2min 17.416s 
graphical.target reached after 6.498s in userspace.

with systemd-analyze blame I see a 1 minute delay before device related entries appear

 1min 5.216s dev-nvme0n1p4.device
 1min 5.216s dev-disk-by\x2dpath-pci\x2d0000:04:00.0\x2dnvme\x2d1\x2dpart-by\x2dpartnum-4.device
 1min 5.216s sys-devices-pci0000:00-0000:00:01.2-0000:04:00.0-nvme-nvme0-nvme0n1-nvme0n1p4.device
 1min 5.216s dev-disk-by\x2did-nvme\x2dWD_Blue_SN5100_1TB_25372H800255_1\x2dpart4.device
 1min 5.216s dev-disk-by\x2dpartuuid-3eded4a3\x2d2b5b\x2d4d2f\x2da4c5\x2dc305183b4643.device
 1min 5.216s dev-disk-by\x2duuid-C2B2DBA1B2DB986D.device
      5.260s NetworkManager.service
      4.832s systemd-logind.service
       492ms systemd-vconsole-setup.service
       231ms initrd-switch-root.service
       158ms systemd-fsck@dev-disk-by\x2duuid-5c7c6e75\x2d2e02\x2d46d6\x2d9614\x2da1e37a03d549.service
       119ms user@1000.service
       117ms systemd-rfkill.service
        96ms systemd-udev-trigger.service

journalctl -b shows

Jan 21 18:11:24 archlinux kernel: amdgpu 0000:0f:00.0: [drm] Registered 4 planes with drm panic
Jan 21 18:11:24 archlinux kernel: [drm] Initialized amdgpu 3.64.0 for 0000:0f:00.0 on minor 0
Jan 21 18:11:24 archlinux kernel: amdgpu 0000:0f:00.0: [drm] Cannot find any crtc or sizes
Jan 21 18:11:24 archlinux kernel: [drm] pre_validate_dsc:1667 MST_DSC dsc precompute is not needed
Jan 21 18:11:29 archlinux kernel: usb 1-12: device descriptor read/64, error -110
Jan 21 18:11:45 archlinux kernel: usb 1-12: device descriptor read/64, error -110
Jan 21 18:11:45 archlinux kernel: usb 1-12: new high-speed USB device number 7 using xhci_hcd
Jan 21 18:11:51 archlinux kernel: usb 1-12: device descriptor read/64, error -110
Jan 21 18:12:06 archlinux kernel: usb 1-12: device descriptor read/64, error -110
Jan 21 18:12:07 archlinux kernel: usb usb1-port12: attempt power cycle
Jan 21 18:12:07 archlinux kernel: usb 1-12: new high-speed USB device number 8 using xhci_hcd
Jan 21 18:12:12 archlinux kernel: usb 1-12: Device not responding to setup address.
Jan 21 18:12:17 archlinux kernel: usb 1-12: Device not responding to setup address.
Jan 21 18:12:17 archlinux kernel: usb 1-12: device not accepting address 8, error -71
Jan 21 18:12:17 archlinux kernel: usb 1-12: new high-speed USB device number 9 using xhci_hcd
Jan 21 18:12:22 archlinux kernel: usb 1-12: Device not responding to setup address.
Jan 21 18:12:23 archlinux systemd-udevd[275]: usb1: Worker [292] processing SEQNUM=2789 is taking a long tim
e.
Jan 21 18:12:27 archlinux kernel: usb 1-12: Device not responding to setup address.
Jan 21 18:12:27 archlinux kernel: usb 1-12: device not accepting address 9, error -71
Jan 21 18:12:27 archlinux kernel: usb usb1-port12: unable to enumerate USB device

This leads me to assume that bus 1 port 12 is timing out repeatedly and for some reason the rest of the boot sequence is waiting on it. However, whatever is connected to it isn't even important to my os since it isn't connected during operation

cat /sys/bus/usb/devices/1-12/
cat: /sys/bus/usb/devices/1-12/: No such file or directory

ls /sys/bus/usb/devices/
1-0:1.0   1-10:1.1  1-10:1.4  1-10:1.7  1-7.2      1-9:1.0  4-0:1.0  7-0:1.0  7-1.2      7-1.4      usb2  usb5
1-10      1-10:1.2  1-10:1.5  1-7       1-7.2:1.0  2-0:1.0  5-0:1.0  7-1      7-1.2:1.0  7-1.4:1.0  usb3  usb6
1-10:1.0  1-10:1.3  1-10:1.6  1-7:1.0   1-9        3-0:1.0  6-0:1.0  7-1:1.0  7-1.2:1.1  usb1       usb4  usb7

So I'm hoping that if I can make the kernel ignore bus 1 port 12, it won't waste a minute trying to get it to work. Alternatively, if it's possible to just ignore this failure and move on with the rest of the boot process, that'd work too. Whatever happens on bus 1 port 12 doesn't matter as long as it doesn't hold up the boot process.

I've removed all external usb devices connected to my pc to see if those were the culprit, that didn't change anything. I'm assuming this is an internal usb device.

Please do correct me if my understanding of what's going on is incorrect.

Last edited by delulinv (2026-01-21 15:27:21)

seth · 2026-01-21 14:41:37

Remove all external usb devices (that includes internally attached ones like LED strips etc), see whether errors go away.

I've removed all external usb devices connected to my pc to see if those were the culprit, that didn't change anything. I'm assuming this is an internal usb device.

Could be a webcam or bluetooth?
Is there a parallel windows installation?

You want to figure what that device is and remove or fix it, not tolerate the noise on the bus.
Improperly terminated USB devices can ruin the entire stack on an electrical signal level.

delulinv · 2026-01-21 15:26:31

It was bluetooth!

I don't use bluetooth typically so I hadn't considered it, I tried starting bluetooth and got something along the lines of

systemctl start bluetooth.service
Jan 21 20:31:56 babel systemd[1]: Bluetooth service was skipped because of an unmet condition check (ConditionPathIsDirectory=/sys/class/bluetooth).

Fixing this problem fixed the boot time as well. This is the solution I found from https://stackoverflow.com/questions/765 … ditionpath

1.Turn off the PC.
2.Unplug power cable to PSU.
3.Hold power button for 30 seconds.
4.Plug power back into PSU.
5.Boot PC.

I'm assuming step 3 is to discharge electricity (not really sure). But when booting after that it boots fast and bluetooth.service starts normally.

Startup finished in 16.247s (firmware) + 3.973s (loader) + 8.205s (kernel) + 2.036s (initrd) + 8.398s (userspace) = 38.862s 
graphical.target reached after 8.398s in userspace.

Thanks for reminding me bluetooth exists ^^

seth · 2026-01-21 15:45:17

For posterity
1. What kind of BT chip is this? (lsusb)
2. In case there's a parallel windows installation see the 3rd link below.

delulinv · 2026-01-21 16:33:49

lsusb gives this as the bluetooth chip

"Foxconn / Hon Hai Wireless_Device" which comes included in my MAG B850 TOMAHAWK MAX WIFI motherboard

(Mine is a dual boot system with windows installed but fast start was off)

seth · 2026-01-21 16:35:23

I wanted you to post the device incl. the product and vendor IDs for google

Arch Linux

#1 2026-01-21 14:29:01

[SOLVED] Consistent unusually long boot times due to usb dev timeouts

#2 2026-01-21 14:41:37

Re: [SOLVED] Consistent unusually long boot times due to usb dev timeouts

#3 2026-01-21 15:26:31

Re: [SOLVED] Consistent unusually long boot times due to usb dev timeouts

#4 2026-01-21 15:45:17

Re: [SOLVED] Consistent unusually long boot times due to usb dev timeouts

#5 2026-01-21 16:33:49

Re: [SOLVED] Consistent unusually long boot times due to usb dev timeouts

#6 2026-01-21 16:35:23

Re: [SOLVED] Consistent unusually long boot times due to usb dev timeouts

Board footer