admin/LithosAnanake
1
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(fabric): §XIV no longer reproduces -- five minted drives attach at power-on and hot-plugged a second apart, all three ISAs

Browse Source 
Checked against a scratch artemis.img, Zuse drive and five identity drives
minted together at a live prompt; the committed images are all blank since
e56974e0 and cannot show the gap either way.  No code change.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
rajames
2026-10-14 08:48:03 -04:00
co-authored by Claude Opus 5.5
parent c15589b39e
commit b7e8e4b058
19 changed files with 82662 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/fabric/FABRIC-3.md
+23
View File
@@ -2461,6 +2461,29 @@ the existing xHCI multi-device history (§VII, and the 2026-09-05/06/07 fixes re
-- possibly a recurrence or a related gap in the same per-slot attach-pending scan, given the
similar shape ("several ports become pending at once, only some get serviced").
**No longer reproduces, 2026-10-14 -- checked on all three ISAs, closed.** Both reproductions
above were rerun against a freshly minted, matched set: a scratch `artemis.img` and Zuse drive,
and five identity drives (`00`-`04`) minted at a live `zuse@Hera` prompt by `MINT`, one hot-plug
at a time (`logs/20261014-082526`). Not against the committed images: every image under
`disk/thumbdrives/`, and `disk/artemis.img`, is all zeros since `e56974e0` bleached them ahead of
§XXXV.6's re-mint, which has not been done. A blank drive is correctly passed over in silence
(its home-blocks check reads BLANK, logged at debug level only), so a first attempt today with
copies of the committed images (`logs/20261014-062249`) showed no WIREBIND lines and proved
nothing either way.
| ISA | five drives present at power-on | five drives hot-plugged ~1 s apart over QMP |
|---|---|---|
| amd64 | 5/5 attached (`logs/20261014-082755`) | 5/5 attached (`logs/20261014-083236`) |
| aarch64 | 5/5 attached (`logs/20261014-083415`) | 5/5 attached (`logs/20261014-083917`) |
| riscv64 | 5/5 attached (`logs/20261014-084134`) | 5/5 attached (`logs/20261014-084624`) |
Zuse's own drive was confirmed in every boot as well. No code changed for this. What closed the
gap is most likely the xHCI driver's per-port connect queue (`kernel/src/usb/xhci.c`,
`dev->pending_events[]`: a connect event that arrives while a command is in flight is held and
handled once the command ring is idle, not dropped); when that landed cannot be traced past the
source-tree reorganisation (`a8b70e88`), so this is inference, not proven. The one-at-a-time
attach rule of §XV and §XXXI is no longer needed.
## XV. 3(architecture) × 9(identity) × 3(replicate) randomized full-factorial DoE — self-contained
FORTH capsule, replacing the ad hoc exerciser-feeding process (2026-09-11)