Files
LithosAnanake/capsules
Robert Allan JamesandClaude Sonnet 5 e10fb76fb2
Build / build-amd64-iso (push) Waiting to run
Build / build-aarch64-iso (push) Waiting to run
Build / build-riscv64-img (push) Waiting to run
xhci: fix Configure Endpoint completion drop under concurrent multi-device enumeration
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
2026-09-07 09:02:45 -04:00
..
2026-08-01 07:49:56 -04:00

capsules/

FORTH personality files loaded by the VM at boot. A capsule is an immutable, content-addressed payload; its XXHash64 hash is its identity. Any mutation changes the hash and the birth protocol rejects the image.

Key files

File Type Purpose
init.4th (m) MAMA_INIT Default Mama VM personality — loaded at LBN 2048
ACL.4th user Word-level ACL system; self-activating at boot
zuse.4th user Bootstrap superuser; loaded by ACL.4th
doe.4th user DoE workload words (EXEC-DOE) — opt-in
init-0.4thinit-9.4th (p) Numbered personality variants
init-l8-*.4th (p) L8 Jacquard mode variants (stable/volatile/diverse/temporal/transition/omni)
hermes/init.4th (p) Hermes baby VM personality
artemis/init.4th (p) Artemis baby VM personality

Block namespace

Block ranges are shared across all loaded capsules — collisions cause silent word-definition overwrites.

Range Owner
20482099 init.4th
21002199 doe.4th
30003999 workload capsules
4000+ user-defined (ACL.4th, zuse.4th, …)

Each block is limited to 1024 bytes. Verify with wc -c before committing.

See also