A reset records the Bulk-Only phase a device was left in, and the black box keeps that account readable

[Japabu]

A reset says which Bulk-Only phase it found a device in; it does not finish the
command, because six T14 boots say the device does not need it and the ring it
would write is one a live driver may still be enqueuing on.

What the machine said, and what this branch claims because of it

Six T14 boots cut a Bulk-Only command on the bench's own SanDisk Ultra and it
came back from every one, stick_secs 0, PASS, EXIT=0:

run	tree	what the device was holding	what ended the machine	stick
39	base	a CBW, nothing queued for its data, after one 4 KiB write	deadline, 120062 ms	0 s
43	base	the same, after 4 MiB of writes	deadline, 120065 ms	0 s
43	base	a data TRB on the ring, doorbell never rung	deadline, 120066 ms	0 s
43	base	the data taken, nothing reading its CSW	deadline, 120065 ms	0 s
45	base	a write in flight — the sweep never stopped	the hard-lockup detector, 60003 ms	0 s
47	this branch	a write in flight, 236 TRBs pending	deadline, 120066 ms	0 s

Run 45 is the base arm and its bound is the finding the first review caught:
that sweep held IF clear for the rest of the boot, so
toyos_tco::hard_lockup_bound_ms ended the machine half a bound early and the
page read a cpu locked up with interrupts off: cpu7 has taken no interrupt for 60003 ms — not the bound the judge demands. Run 47 is the same arm with the
stimulus fixed, and the lockup bound did not fire.

So the reset path publishes and records and does not act:

1. toyos_xhci::bot::Phase — where one Bulk-Only round trip stands (BOT 1.0
   §5.1), published by the driver between every enqueue and its doorbell and at
   each gap between two phases, read by the reset out of an atomic because that
   path may take no lock.
2. xhci::stop::settle_commands — gives the driver USB_TIMEOUT_NS to close
   the command, then writes which phase the device was left in and what the
   controller says about its data endpoint. Reported, never judged.
3. toyos_blackbox::ACCOUNT_BYTES and Account — the account reaches the page
   at all, and says how far the reset got if the machine ends mid-way.

It does not finish the command. An earlier revision of this branch did, and
it is deleted: nothing on that path can hold the controller lock, so a TRB
written onto a ring rebuilt from published numbers can be a second write of a
block the device already has — and no machine has shown the finish necessary.
BOT §5.3.4 makes reset recovery the device's obligation and this bench's device
honours it.
issues/kernel/a-cut-bulk-only-command-does-not-brick-the-benchs-stick.md
carries the rows and what is not claimed.

What "236 TRB(s)" rests on

The number in run 47's account — and in the tracker and in this branch's commit
messages — was produced by dequeue.wrapping_sub(base) / 16 and a
% RING_SIZE, in the kernel, with no test and no refusal: a dequeue pointer
that is not on the ring wrapped into some value between 0 and 255 that the
account printed as the hardware's own word.

That computation is now toyos_xhci::Ring::pending, in the pure crate beside
EndpointState::decode, which reads the other half of the same endpoint
context:

pub fn pending(self, dequeue: u64) -> Result<u16, NotOnTheRing>

• It refuses by name. NotOnTheRing::Dequeue for a pointer before the
  ring's first TRB or past its last — which is what a context the controller
  never wrote, or one read mid-publication, reads as — Unaligned for one on
  the ring and not at a TRB, Tail for a driver enqueue point past the ring's
  end. The account prints the refusal where it used to print a number, so no
  reader can take one for the other.
• The arithmetic is unchanged for a pointer that is on the ring, which is
  what makes run 47's 236 still the same 236: same masking of the low four bits
  (xHCI 1.2 §6.2.3 — Dequeue Cycle State plus three RsvdZ), same wrapped
  distance from the controller's index to the driver's tail. What is new is that
  a pointer off the ring is now said rather than wrapped.
• It is tested, including the wrap in both directions, both ends of the
  ring, the four low bits, an unaligned base, and a ring of no TRBs — the
  division by zero this path may not take.

What is still owed on it: run 47 was measured under the old, unrefusing
computation, so that its pointer was genuinely on the ring is inferred from the
count being in range and the endpoint being Running on a ring the driver had
just enqueued on — not witnessed. A boot of the usbload arm on this tree would
witness it; the bench's stick is dead awaiting a physical replug, so that boot is
not taken here.

The black box lost the account, and the reserve was not why

Measured off the four pages (awk over each loader.log, split at the first
usb-quiesce line):

page	report bytes, of REPORT_BYTES = 14296	page bytes free	account
run 43 usb-wedge-data-owed	13773	2571	absent
run 43 usb-wedge-in-data	13763	2581	absent
run 43 usb-wedge-before-status	14253	2091	798 B
run 45 usbload	14258	2086	930 B

No report exceeded its reserve and neither losing page was full. stop_all
writes its barrier line and then waits — 2000 ms settling, a port-reset bound,
100 ms of device recovery per controller — and the one statement that rewrites
the length and checksum covering everything written was only reached after all
of it. A machine that ends inside one of those waits leaves every byte already
written covered by nothing.

toyos_blackbox::Account is the fix, and it seals per line, not per
fragment: one writeln! reaches a writer as the pieces either side of each
argument, so a writer that sealed on every one of them would cover a torn line
with a valid checksum — the same defect one layer down. Bytes past the last
newline stay on the page, outside the sealed length, invisible to recover.
It lives in the crate rather than the kernel because the previous writer was
constructible only in the kernel and no host test could drive it.

Both are recorded in
issues/diagnostics/a-wedged-boots-record-outgrows-both-channels-that-carry-it.md,
which this does not close: its loader.log half stands.

The two checks

Negative controls (host, run):

mutation	what it restores	cargo test -p toyos-blackbox
ACCOUNT_BYTES = 0	the reserve gone	101 — a report ran to 16296, leaving under 1024 B for the account
Account commits on every fragment	the torn line sealed as a complete account	101 — the cut line reads back (…xHCI 00:14.0 halted=), and one line built from three fragments seals 9 times where 3 lines owe 3
Account never commits	the account covered by nothing	101 — the page carries the report and none of the account ("[0000] why\n")

Restored after each: 0, 26 passed.

The second and third are the control on the commit-per-line half that the last
round did not have: the test named then drove Report::commit directly and
passed with the kernel's writer deleted. The current test asserts the cut line
is not readable and that one line built from three fragments seals exactly
once.

Independent oracle: USB Mass Storage Class Bulk-Only Transport 1.0 §5.1,
§5.3.4, §6.7.2–3 and xHCI 1.2 §4.7 / §4.11.1 / §5.4.8 / §4.19.5 / §6.2.3, cited
at the sites — and the T14's own boot.usbload.stick_secs, a physical device on
a laptop whose ports never drop VBUS, answering through a channel this kernel
does not write.

The stimulus, and the state it leaves its CPU in

usb-reset-under-load sweeps the last eighth of the stick from the shutdown
syscall so the reset lands on a controller that is moving bytes. It keeps its
CPU interruptible — preemption off, IF on, the one-shot armed — so the boot
deadline and not the hard-lockup detector ends the machine, and it now puts
all three back on every path out: an Interruptible guard whose Drop
restores them, because the caller goes on to drain write-back, sync every
filesystem, flush every disk and wait for the log to be durable. Whether the
syscall arrived with IF masked is read before the sti rather than assumed.

What this does not have

• One CI measurement. usb_reset_records_the_phase_it_cut is a new
  registration and every shortcut is refused by the tree: src/durations.rs
  refuses a committed UNMEASURED marker, src/tiers.rs refuses that marker on
  a Nightly row and refuses a Nightly row with no CI evidence, and the local
  measurement of 63 s can never be Tier::Fast against a 10 000 ms ceiling. It
  is bootstrapped Tier::Fast with the marker, which is the two-cycle path
  tests/CLAUDE.md states. durations reds until a second commit replaces
  the marker with the measured value and re-tiers the name Nightly. This is
  not landable before that.
• A T14 boot on this tree. The bench's stick is dead awaiting a physical
  replug, so no run was requested. What a boot would witness is named above.
• Step 3 of the original brief — catching the real hang — is not started. The
  three kills share the hang, not the reset, and the stick cannot carry evidence
  about its own death; that question moves to the network track.

Fence

Kernel, pure crates (toyos-blackbox, toyos-xhci) and the harness. No ABI:
git diff --name-only origin/main touches no file under toyos-abi/, toyos/
or userland/libc/.

Gates, each with its own command's exit status

command	exit
cargo run -- --clippy	0 (5 invocations clean)
cargo run -- --build-only	0
cargo test --lib	0 (298 passed)
cargo test --workspace --exclude toyos-build	0
cargo test -p toyos-blackbox -p toyos-xhci	0 (26 and 53 passed)
cargo test --test toyos-build usb_reset_records_the_phase_it_cut -- --nightly	0, PASS (64 s)
cargo test --test toyos-build usb_reset_hands_devices_back -- --nightly	0, PASS (39 s)
mutation: Account commits per fragment	101
mutation: Account never commits	101
mutation: ACCOUNT_BYTES = 0	101
restored, cargo test -p toyos-blackbox	0 (26 passed)

The renamed guest arm was run twice. The first attempt exited 2 and is not
quoted as a result: test result: INVALID. 0 passed, 1 invalidated by a host suspend of 994s — the laptop slept mid-run, which tests/CLAUDE.md says is a
re-run and not a verdict. The row above is the re-run, which carries no
invalidation line. No T14 boot was taken: the bench's stick is dead awaiting a
physical replug.

🤖 Generated with Claude Code

https://claude.ai/code/session_014iqcj4jDKpaiDX8B7CMvmK