Four T14 bench issues filed, and three standing ones corrected by the same readback

[Japabu]

What this changes

issues/ only; no code. What the branch as a whole does to the tracker, after the round-1 review's findings were answered in the files they were found in:

• Adds issues/build/a-hung-boots-log-partition-is-wiped-by-the-next-runs-flash.md (kind: tooling): src/metal.rs's loop flashes (:1000-1002, called at :1471) before it reads (read_log at :1489, raw_log at :1496), so a hung boot's partition survives only if something outside the loop read it between two invocations; and the loop cannot read a wedged stick at all (read_log and raw_log refuse, :1131-1162, :1184-1190). Run 55's partition was read from outside the loop before run 56 flashed over it, and held no file logd wrote. Exit condition: a pre-flash save that records, not refuses, when the stick does not answer.
• Adds issues/kernel/a-120000-ms-boot-deadline-fired-132859-ms-late-on-the-t14.md (kind: defect): run 55's boot, armed boot-deadline=120000, expired at 252859 ms; the 60000 ms hard-lockup bound armed off the same parameter (kernel/src/deadline.rs:182, toyos-tco/src/lib.rs:154-156) was silent on the same boot. The sealed census is quoted whole; cpu0's state explains nothing about the bound (cpu4 took 215 timer interrupts in the 3.47 s cpu0 took 9). The instrument that measures the lateness exists — deadline_lateness_ms (src/metal.rs:1591), priced at ceiling 10000 in tests/metal-profile.toml:409-414, judged in tests/common/metal.rs:895-919 — and 132859 is 13x that ceiling on a boot the profile does not name. The record was read by run 56's loader pass, which printed it and ended the chain without booting a kernel (bootloader/src/main.rs:857-860).
• Adds issues/kernel/the-deadline-header-promises-any-interrupt-and-only-the-timer-entry-polls.md (kind: defect): kernel/src/deadline.rs:11-13 claims "some CPU still takes an interrupt" keeps the bound alive; poll's only call sites are the timer entry's (kernel/src/arch/idt/timer.rs:71,79,96) and :185-186 says so. Filed, not fixed.
• Adds issues/isolation/a-reset-stops-xhci-and-leaves-every-claimed-pci-function-armed.md (kind: defect): five paths reach the two register writes — sys_reboot and sys_shutdown through quiesce, deadline::expire (deadline.rs:224) and hardlockup::locked_up (hardlockup/mod.rs:326) straight to acpi::reset_now, panic_reboot::reboot_now to acpi::reboot — and none tears down a live process's PCI function; pcidev::release's one caller is Claim's Drop (kernel/src/device.rs:75). True today for netd's virtio-net function (system.toml:70-72); the I219 is the instance this tree reaches when PR The cable: netd takes its address from the network, and the T14 answers a ping on it #442 lands. What the 0xCF9 write does to the function is stated as unmeasured, with what would measure it.
• Promotes issues/kernel/a-claimed-function-must-have-msi-x-and-the-i219-may-not.md from finding to defect, status: assigned to PR The cable: netd takes its address from the network, and the T14 answers a ping on it #442 (lan-metal, whose pcidev arms MSI where MSI-X is absent), and folds into it the I219's measured interrupt mode (mode=msi, recorded on that branch at git show 0a5717f5:issues/hardware/the-t14-answers-only-through-a-usb-stick.md lines 61-63), the IVAR write and readback quoted whole from toyos-i219/src/lib.rs:496-503, the fact that the write is unreachable in this tree (kernel/src/pcidev/mod.rs:544 refuses the function before open runs), and that the boots which armed MSI (runs 42 and 51, tips 4204e090 and 6276fc87) were of unmerged branches. IVAR only; nothing cited says EIAC is MSI-X-only.
• Closes issues/kernel/a-job-list-hangs-with-interrupts-on-and-the-deadline-ends-it.md: its exit condition was a loader.log from a T14 boot that ran to its deadline with the ring tail naming what the machine was doing, and run 56's readback is that. Its one citation, in issues/kernel/an-xhci-storm-starves-the-cpu-that-takes-it.md, moves to the deadline file.
• Deletes issues/kernel/eiac-and-ivar-are-msi-x-registers-on-an-msi-only-i219.md (folded, above) and issues/panic-path/no-watchdog-outlives-exitbootservices-and-a-hang-seals-nothing.md, both filed on earlier pushes of this branch and never on main. The panic-path file claimed a fatal event reaching apic::halt_all_cpus disarms both kernel bounds and reaches no black-box seal, so that nothing past ExitBootServices is timed by a bound this tree has verified to fire and no hung boot's record has ever been captured. Refuted twice: in the tree, the black box's own contract (kernel/src/blackbox.rs:5-7) is that the panic path seals what the panel rendered, record_panic, called at kernel/src/drivers/panic_console/mod.rs:582; and on the machine, run 55's boot — a deadline::expire wedge, which never reaches halt_all_cpus — sealed a WEDGED record that the next loader pass printed, the record the deadline file quotes.

Why

The round-1 review (verdict SEND BACK) found, and the orchestrator upheld: the build file asserted no hung partition had ever been read when run 55's had been, and proposed a pre-flash read_log that refuses on exactly the wedged stick it would be for; the deadline file's slug named a cause its own census refutes, omitted the silent hard-lockup bound, proposed an instrument that exists, and cited neither of the two files already on the subject; the EIAC/IVAR file duplicated an open finding without citing it, asserted EIAC's mode without a source, and never said the scenario is unreachable in this tree; the isolation file's "every reset goes through acpi::reboot/acpi::shutdown" is false in the tree and its load-bearing claim about the function surviving the reset was unmeasured; and the PR body's numbers pointed at files no reader of the tree can open.

Evidence

Every number in the issue files is quoted from the bench transcripts into the file itself — run 55's loop refusal at 21:02:01Z and the copied partition's loader.log line 20 (Black box: 0x8000000 armed at 2026-09-14-205457 …); run 56's transcript line 1 and its loader pass (the boot deadline expired: a bound of 120000 ms, reached at 252859 ms, with this machine in \complete`.), the irq:` census whole, and the tail's last records; runs 42 and 51's hand-over records. The transcripts live under the orchestrator's job directory, which no reader of the tree can open, so no path there is a citation.

• 252859 − 120000 = 132859; 132859 / 10000 = 13.3 (the ceiling at tests/metal-profile.toml:412).
• git diff --stat 4d604c86 HEAD -- kernel/src/deadline.rs kernel/src/hardlockup/mod.rs kernel/src/drivers/acpi.rs → empty: the branch run 55 booted matches this tree on the files the deadline issue cites. git branch -a --contains 4d604c86 → i219-delivery only.
• git grep -n 'regs::IVAR' 4204e090 6276fc87 -- toyos-i219/src/lib.rs → both tips carry the write and readback at :502-503; git branch -a --contains on either tip → bar-placement, i219-delivery, i219-phy, never main.
• git grep -l lancase origin/lan-metal → src/lan.rs, tests/toyos.rs, tests/metal-profile.toml and five more; git grep -n lancase HEAD → only the issue files.
• rg -n 'deadline::poll' kernel/src → kernel/src/arch/idt/timer.rs:79 and :96 only. rg -n 'pcidev::release' kernel/src → one line, the caller at kernel/src/device.rs:75; the definition, pub fn release(slot: usize), is at kernel/src/pcidev/mod.rs:782.
• Every file:line in the six changed issue files was read in this worktree at 2a8cb4e7 with sed -n.

Gates

command	exit	result
cargo test --lib (this worktree, 2a8cb4e7)	0	307 passed, 0 failed, 1 ignored
git grep --cached -n for the five deleted or renamed slugs (a-job-list-hangs-with-interrupts-on-and-the-deadline-ends-it, eiac-and-ivar-are-msi-x-registers-on-an-msi-only-i219, a-boot-deadline-of-120000-ms-fired-132859-ms-late-behind-an-xhci-storm-on-cpu0, a-reboot-quiesces-xhci-and-leaves-a-claimed-i219-armed, no-watchdog-outlives-exitbootservices-and-a-hang-seals-nothing)	1	no hit
rg -n --hidden -g '!.git' for the same five	1	no hit
rg -n -- '-area' over the six changed issue files	1	no hit
a frontmatter conformance loop over issues/*/*.md (the README's value sets, its status/kind pairing table, the date form)	0	252 files
every issues/<area>/<slug>.md the six changed files cite, tested with [ -f ]	0	7 paths, all resolve
cargo test --workspace --exclude toyos-build	not run	no crate is touched; every host-crate suite is unaffected by issues/
an issues gate in src/	none exists	rg -n -i 'frontmatter' --glob '!issues/**' . is empty; the tree-side readers of issues/ paths are src/redlist.rs's source: rows and src/tiers.rs, and none names a file this branch moves

Anything a reader of main must not miss

• Closed by this merge: issues/kernel/a-job-list-hangs-with-interrupts-on-and-the-deadline-ends-it.md. Its durable line — a deadline that fires is a machine on which some CPU took a timer interrupt — is already kernel/src/deadline.rs:86-87's, so no header line is owed.
• issues/kernel/a-claimed-function-must-have-msi-x-and-the-i219-may-not.md is now kind: defect, status: assigned to PR The cable: netd takes its address from the network, and the T14 answers a ping on it #442.
• issues/hardware/a-t14-boot-wedges-after-a-jobs-exit-and-nothing-said-why.md is not closed: its exit condition is a WEDGED record of a different shape, and the deadline file says why.
• Pre-existing and untouched here, found by the review and ruled outside this branch: kernel/src/arch/syscall/machine.rs:97, kernel/src/drivers/xhci/stop.rs:449 and issues/kernel/quiesce-runs-while-userland-still-does-io.md each say every reset goes through acpi::reboot/acpi::shutdown, and deadline.rs:224 and hardlockup/mod.rs:326 reach reset_now directly. The isolation file states the true graph beside them.
• Filed and not fixed, by design of this branch: the deadline header's coverage claim.

🤖 Generated with Claude Code

https://claude.ai/code/session_014iqcj4jDKpaiDX8B7CMvmK