kern/60075: xhci(4) user-visible USB addresses appear to reflect prior failed enumerations

["Izumi Tsutsui via gnats" <gnats-admin%NetBSD.org@localhost>]

>Number:         60075
>Category:       kern
>Synopsis:       xhci(4) user-visible USB addresses appear to reflect prior failed enumerations
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Mar 12 21:10:00 +0000 2026
>Originator:     Izumi Tsutsui
>Release:        NetBSD 10.1
>Organization:
>Environment:
System: NetBSD mirage 10.1 NetBSD 10.1 (GENERIC) #3: Mon Jan 5 01:48:52 JST 2026 tsutsui@mirage:/s/netbsd-10/src/sys/arch/i386/compile/GENERIC i386
Architecture: all (tested on i386 and amd64)
Machine: all (S/A)
>Description:

On NetBSD's xhci(4), repeated attachment failures on the same port
appear to influence the next user-visible USB device address (addr N)
reported in dmesg and returned through USB device information.

In my test case, a device repeatedly fails enumeration on an xHCI
root-hub port, with messages such as:

---
uhub1: autoconfiguration error: device problem, disabling port 9
---

After enough failures, when the same device finally enumerates
successfully, it does not appear at the smallest or recently reused
address. Instead, the successful attachment gets a much larger
address value that appears to reflect the history of prior failed
attempts on that port.

In my test case (pluging and removing UIAPduino without write-standby mode
three times) the kernel dmesg says first:
---
[    36.102060] uhub1: autoconfiguration error: device problem, disabling port 9
[    36.822057] uhub1: autoconfiguration error: device problem, disabling port 9
[    42.002032] uhub1: autoconfiguration error: device problem, disabling port 9
[    42.712029] uhub1: autoconfiguration error: device problem, disabling port 9
[    46.912009] uhub1: autoconfiguration error: device problem, disabling port 9
[    47.622005] uhub1: autoconfiguration error: device problem, disabling port 9

---

This implies xhci_new_device() fails 6 times.

Next, plug UIAPduino with write-standby-mode by
"pressing the reset button, connect the board to a USB port 
 of your computer and then immediately release the reset button."

---
[    56.521964] uhidev3 at uhub1 port 9 configuration 1 interface 0
[    56.521964] uhidev3: InterBiometrics (0x1209) 32V003 (0xb803), rev 2.00/1.41, addr 7, iclass 3/0
[    56.531963] uhidev3: 170 report ids
[    56.531963] uhid4 at uhidev3 reportid 170: input=0, output=0, feature=127

---

I.e. it's assigned at "addr 7" after 6 failures?

More failres show larger addr:
---

[   520.429754] uhub1: autoconfiguration error: device problem, disabling port 9
[   523.649738] uhub1: autoconfiguration error: device problem, disabling port 9
[   530.069708] uhidev3 at uhub1 port 9 configuration 1 interface 0
[   530.069708] uhidev3: InterBiometrics (0x1209) 32V003 (0xb803), rev 2.00/1.41, addr 57, iclass 3/0
[   530.079708] uhidev3: 170 report ids
[   530.079708] uhid4 at uhidev3 reportid 170: input=0, output=0, feature=127

---

[   578.439477] uhid4: detached
[   578.439477] uhidev3: detached
[   578.439477] uhidev3: at uhub1 port 9 (addr 57) disconnected
 :
[   741.528701] uhidev3: at uhub1 port 9 (addr 123) disconnected
[   742.328697] uhidev3 at uhub1 port 9 configuration 1 interface 0
[   742.328697] uhidev3: InterBiometrics (0x1209) 32V003 (0xb803), rev 2.00/1.41, addr 124, iclass 3/0
[   742.338697] uhidev3: 170 report ids
[   742.338697] uhid4 at uhidev3 reportid 170: input=0, output=0, feature=127
 :

---

If addr reaches 127, it looks wraparound:

---
[   789.888470] uhid4: detached
[   789.888470] uhidev3: detached
[   789.888470] uhidev3: at uhub1 port 9 (addr 124) disconnected
[   792.858456] uhub1: autoconfiguration error: device problem, disabling port 9
[   793.568453] uhub1: autoconfiguration error: device problem, disabling port 9
[   798.128431] uhub1: autoconfiguration error: device problem, disabling port 9
[   798.838428] uhub1: autoconfiguration error: device problem, disabling port 9
[   807.578386] uhidev3 at uhub1 port 9 configuration 1 interface 0
[   807.578386] uhidev3: InterBiometrics (0x1209) 32V003 (0xb803), rev 2.00/1.41, addr 2, iclass 3/0
[   807.598386] uhidev3: 170 report ids
[   807.598386] uhid4 at uhidev3 reportid 170: input=0, output=0, feature=127

---

As noted above, the visible USB address seems to advance according
to prior failed enumerations and eventually wraps, rather than
reflecting only currently attached devices in a simple way as
usbd_getnewaddr() in src/sys/dev/usb/usb_subr.c used by ehci/ohci etc.

I understand from follow-up discussion that xHCI using root-hub
address 0 is intentional.  This PR is not about that point.

The issue here is that controller-internal allocation/progress
appears to leak into the user-visible device address seen in
dmesg and userland.

Even if this is valid from an internal xHCI bookkeeping perspective,
it is surprising as externally visible behavior:

- Failed devices never became usable from the user's point of view
- Nevertheless, they affect later visible addr N values
- This makes logs harder to interpret
- This makes xHCI enumeration behavior harder to reason about than
  the other USB (ehci, ohci etc.) path

>From reading the xHCI attachment flow, it appears that the visible
dev->ud_addr is determined only after xHCI-specific slot/address
setup has progressed significantly, so the final visible address
may be reflecting controller-side allocation state rather than
a simpler bus-level notion of "currently assigned address".

I am filing this as a behavior/semantics issue first, even
if the current implementation is technically intentional,
because the current externally visible result is difficult
to understand and to debug from userland.

It may be preferable either:

1) to avoid exposing failed-enumeration history so directly
   in the visible USB address, or

2) to clarify that xHCI-visible USB addresses are derived from
   controller-side allocation state and may advance across failed
   enumerations.


>How-To-Repeat:
See above.

>Fix:
No idea.

---
Izumi Tsutsui