Robert Allan JamesandClaude Sonnet 5
c54ea24aaf
Completes the CBW -> Data-In -> CSW chain for READ(10) started last commit. xhci_bot_read_data_in() and xhci_bot_receive_csw(), each a single Normal TRB on the bulk IN Transfer Ring via a new xhci_bulk_in_enqueue_and_ring() helper (mirrors the OUT-side helper from CBW send). All three stages now chain automatically via the existing deferred next_action pattern: CBW completion defers into Data-In, Data-In completion defers into CSW receive, CSW completion is where signature/tag/status validation happens. Data-In reads into a new fixed 512-byte bot_data_buf -- single-block scope for this increment, matches QEMU's usb-storage reported block size; xhci_bot_send_read10() now refuses rather than overflow/truncate if a request exceeds it. CSW validation (BOT spec section 5.2) checks dCSWSignature and dCSWTag (a new bot_last_tag field, latched from the CBW) before trusting bCSWStatus at all, so a garbled/misaligned CSW read can't be misread as a clean pass. usb_bot_csw_t follows the same struct-with-explicit-length-not-sizeof discipline as usb_bot_cbw_t. Verified live via a temporary probe (written, run once, log captured, reverted per this project's own probe convention), all three architectures, byte-identical: the full CBW -> Data-In -> CSW exchange completes cleanly, well-formed CSW with correct signature and echoed tag, no wedge, clean disconnect immediately after. The SCSI command itself reports CSW status FAILED against the current test fixture -- expected at this stage (no TEST UNIT READY / UNIT ATTENTION handling implemented yet, consistent with a fresh-attach unit-attention condition, not a transport-layer defect) and not root-caused further here; the BOT mechanism itself is confirmed correct end to end. Probe-free re-verification afterward on all three architectures. FABRIC-2.md Section X Milestone 2g's CSW checklist item marked done; "get one real READ(10) working end to end" stays explicitly open, distinguishing "the mechanism works" from "the SCSI command succeeds." Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01R4VMX6VSKCten8nGgaMkq4
disk/
QEMU disk images used for Artemis (block-storage VM) persistence testing.
Mounted via Makefile.starkernel's ARTDISK variable (default
disk/artemis.img) as a virtio-blk-pci device on all three
architectures' kernel QEMU boots — not scripts/rundisk.sh, which targets
a separate, currently-unused disks/ (plural) directory for the hosted
VM's --disk-img= flag instead.
artemis.img— standard Artemis persistence test disk. Reformatted 2026-08-02: this image had been stuck in a corrupted state (validLithosAnankemagic header, but data not matching whatART-READ-TESTexpects) since before this repo's own git history begins (git logshows it already broken at the initial commit, carried over from the pre-split monorepo). Chasing down the resulting persistentFAIL: persist-readtraced to the data, not the code — the write→reboot→read round trip works correctly on a fresh image (seeartemis-debug-roundtrip.imgbelow). Reformatted by blanking the file and letting a normal boot format+write-test it; verifiedPASS: persist-readon amd64, aarch64, and riscv64 against the same image afterward (cross-arch resume, matching the arch-neutral on-disk format.claude/ARTEMIS.mdspecifies).artemis-debug-roundtrip.img— round-trip regression fixture created during that investigation. Known-good: format → self-test → write-test → reboot → resume →PASS: persist-read, confirmed 3 times in a row. Keep this in a passing state; if a future change breaks it, that's a real regression, not a stale-fixture artifact likeartemis.imgwas.artemis-persist-test.img— persistence round-trip test image (pre-existing; history/state not re-verified during the above investigation).artemis-poison.img— a separate test image (exact scenario not documented elsewhere in the repo as of this writing; name suggests an adversarial/corruption test, not confirmed).artemis-unrecognized-test.img— exercisesART-HALT-UNRECOG(.claude/ARTEMIS.mdacceptance criterion #6). Regenerated 2026-08-02: the previous copy of this file had itself been silently reformatted by a since-fixed bug in the generic block subsystem (src/block_subsystem.c) — it carried a valid low-level'STFR'/v2 header despite being meant to represent foreign disk content, direct forensic evidence of the bug described in.claude/ARTEMIS.md's Build Status item 6. Regenerated as 30MB of a repeatingPOISON-UNRECOGNIZED-DISK-TEST-FIXTURE--NOT-BLANK-NOT-STFR-NOT-ARTEMIS--ASCII pattern — deliberately neither blank, nor the block subsystem's own'STFR'magic, nor Artemis's"ARTEMIS\0"marker. Verified on amd64 and riscv64 post-fix: boot correctly halts (ARTEMIS HALT: unrecognized disk content) and the file's sha256 is now byte-for-byte identical before and after boot. Keep this fixture in this poisoned state — if a future change makes its sha256 change across a boot, that is exactly the regression this fixture exists to catch.
Note on incidental header churn: artemis.img picks up a few changed
header bytes on every ordinary boot even though no user data changes —
blk_subsys_attach_device() always records a fresh mounted_time on a
successfully recognized disk, which gets flushed at shutdown. This is
expected bookkeeping, not a bug; revert it before committing rather than
carrying timestamp noise in git history.
usb-thumbdrive-test.img— 64MB raw image backing a QEMUusb-storagedevice attached to the xHCI controller's bus (xhci0.0) for Milestone 2e/ 2h hotplug testing, added 2026-08-22. Not yet formatted with any LithosAnanke/Artemis header — at this point in the driver's development it only needs to exist as a backing store for a live Port Status Change event; formatting comes onceblkio_usb.candblk_subsys_attach_device()wiring exist (Milestone 2h).
Convention, standing as of 2026-08-22: every virtual disk/thumb-drive image
used for testing — Artemis persistence disks above, and USB Mass Storage
backing images alike — lives in this directory and is a tracked, committed
file, never scratchpad. This was already artemis.img's convention;
usb-thumbdrive-test.img and any future USB test images follow the same
rule. Confirmed no .gitignore in this repo excludes disk/*.img.
These are regenerable QEMU raw disk images, not source — see
.claude/ARTEMIS.md for the storage model they exercise.