usb_alloc_device: set address 3 failed (USB_ERR_TIMEOUT, ignored) usbd_setup_device_desc: getting device descriptor at addr 3 failed, USB_ERR_TIMEOUT usbd_req_re_enumerate: addr=3, set address failed! (USB_ERR_TIMEOUT, ignored) usbd_setup_device_desc: getting device descriptor at addr 3 failed, USB_ERR_TIMEOUT usbd_req_re_enumerate: addr=3, set address failed! (USB_ERR_TIMEOUT, ignored) usbd_setup_device_desc: getting device descriptor at addr 3 failed, USB_ERR_TIMEOUT usbd_req_re_enumerate: addr=3, set address failed! (USB_ERR_TIMEOUT, ignored) usbd_setup_device_desc: getting device descriptor at addr 3 failed, USB_ERR_TIMEOUT usbd_req_re_enumerate: addr=3, set address failed! (USB_ERR_TIMEOUT, ignored) usbd_setup_device_desc: getting device descriptor at addr 3 failed, USB_ERR_TIMEOUT xhci_interrupt: host controller halted ... and so forth... Disabling it in the BIOS doesn't help because possibly because the wireless card has some Bluetooth coexistence thing. DELL CBX3 xhci0: <Intel Sunrise Point USB 3.0 controller> mem 0xdf310000-0xdf31ffff irq 16 at device 20.0 on pci0 iwm0: <Intel(R) Dual Band Wireless AC 3165> mem 0xdf100000-0xdf101fff irq 17 at device 0.0 on pci3 iwm0: hw rev 0x210, fw ver 22.361476.0, address 44:03:2c:a3:2c:99 13.0-RELEASE-p7 Not sure what info to share. Last I checked it doesn't happen on stable. Any hope of a backport for 13.1? If someone can propose individual patches I can apply myself that'd work. I don't know what https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235092 but it doesn't seem to affect me.
I suppose it's this one. https://github.com/freebsd/freebsd-src/commit/83235903d5dc735fbce8b22a5204ab648f2d9c94
ubt0: <vendor 0x8087 product 0x0a2a, class 224/1, rev 2.00/0.01, addr 1> on usbus0 Thing is, it attached fine on stable.
(In reply to tod.jackson from comment #2) Note that stable/13 has newer work than releng/13.0. If stable's fine, then you're looking for 13.1 when that comes out (we're in the middle-ish of the release process now)
Okay, cool. I can't find an acceptable workaround in the meantime though because with hw.usb.no_boot_wait=1 I'm still waiting several minutes for my mouse to work.
(In reply to tod.jackson from comment #4) Maybe try killing ubt0 with a hint in loader.conf? maybe: hint.ubt.0.disabled="1"
Ah, someone had suggested that on the forums but I mistakenly put it in device.hints. That does prevent ubt from appearing in dmesg, but it's still waiting for usbus0... which makes me wonder if this isn't a wireless issue? To clarify, no change in behavior.
(In reply to tod.jackson from comment #6) If I understand the nature of this particular problem right, try fully power-cycling (full power loss, then cold boot). If it comes up OK, try rebooting one time (just `reboot` this time) to confirm. All of this with ubt0 still disabled.
Hey, that worked, thanks! So this fix will be in 13.1? If so, I say we can close this issue.
Well, I don't mean the fix of disabling ubt of course, but whatever is the root cause.
(In reply to tod.jackson from comment #9) Right, assuming stable worked for you without having to disable ubt0, you should be fine. I would encourage you to try 13.1-PRERELEASE images (I think that's what we're producing this week) and confirm that ubt0 indeed works there enabled. For easy testing, I reckon you can just throw it on a usb stick and boot to the install media twice, drop to a shell both times and confirm that ubt0 attached.
I'll test that now to confirm.
Wait, is it not out yet? Can't find any image.
(In reply to tod.jackson from comment #12) Barring any surprises, it should be released in ~2 days.
Okay, cool. I'll post again here with an update.
(In reply to tod.jackson from comment #12) 13.1-PRERELEASE images were announced on 24th February: <https://lists.freebsd.org/archives/freebsd-snapshots/2022-February/000060.html>
Seems fixed for 13.1. It timed out normally due to missing firmware (device id is in devd.conf now on the image so should be fine), and also didn't leave the device in a corrupt state once I returned to 13.0. We can close this if you like.
(In reply to tod.jackson from comment #16) Excellent, thanks for confirming. Given that the fix has already been backported and confirmed functional, yeah, I'll go ahead and close this. Thanks for the report!