Robert Allan JamesandClaude Sonnet 5
e10fb76fb2
Root cause of the FABRIC-3.md §IX.5 follow-on: with 9 devices attached concurrently at boot (Zuse + 8 identities), only 1 of 9 ever completed enumeration and reached blkio_usb: MSC device ready -- the other 8 produced no error and no success, just silence. xhci_poll_events()'s deferred per-slot dispatch loop submitted a Configure Endpoint command (a Command Ring op) unconditionally for every slot with that action pending in a single pass -- unlike every other Command Ring op in this driver (Enable Slot, Address Device, Disable Slot), which is correctly gated behind dev->connect_state == XHCI_CONN_IDLE before ever submitting. With 2+ devices enumerating concurrently, this let multiple Configure Endpoint commands sit outstanding on the Command Ring at once. Their completion is correlated purely via the single shared dev->connect_state field (== XHCI_CONN_AWAIT_CONFIGURE_ENDPOINT), not the completion event's own Slot ID -- so whichever slot's completion happened to land while connect_state still read AWAIT_CONFIGURE_ENDPOINT got correctly chained into SET_CONFIG, and every other slot's completion arrived after connect_state had already moved on, silently swallowed by the handler's generic "unrelated command completion" catch-all. No error path exists for this, which is why it produced total silence rather than a diagnosable failure. Root-caused live via temporary WARN-level diagnostic probes (written, captured, and fully reverted per the project's own probe convention -- this commit contains only the functional fix and its explanatory comment, no probe code) added at four points: the initial port scan, the connect handler, the Command Completion Event handler, and the deferred dispatch loop itself. The probes showed all 9 devices correctly completing Enable Slot + Address Device (ruling out the connect-state queue as the cause, the original hypothesis), then all 9 correctly submitting Configure Endpoint and all 9 commands completing successfully in hardware (code= SUCCESS, no errors logged) -- but only 1 of 9 ever got its next_action chained to SET_CONFIG. Fix: apply the same single-in-flight discipline this driver already uses for every other Command Ring op. If the Ring isn't free when a slot's Configure Endpoint action is due, put the action back on that slot instead of submitting a second command onto a busy Ring -- the next tick's dispatch pass retries it once the Ring frees up. Verified live: booting Zuse + all 8 identity drives concurrently (9 devices, one per real xHCI port via the XHCI_PORTS fix from the previous commit) now produces 9 "MSC device ready" lines and zero xHCI errors, where it previously produced exactly 1. Three-arch clean qemu acceptance (single Zuse device, the standard regression case) passed on amd64, aarch64, and riscv64 -- no change in that baseline behavior. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014Ec88YKxxhZGG1RNnune78