Disable blocking_read_window behind its filed defect

[Japabu]

Summary

• blocking_read_window reds beside other guests on host load, naming a lost
  wake a slow guest also satisfies
  (issues/build/blocking-read-window-reds-beside-other-guests.md). The
  orchestrator's Fast tier and nightly for PR Storage: file servers for DATA, the log and the boot volume; the kernel's NVMe and FAT go #536 at 5235eda7 hit it
  twice, 2 of 2 red, and the round-13 reviewer found Storage: file servers for DATA, the log and the boot volume; the kernel's NVMe and FAT go #536 leaves the wake and
  pipe path alone, with the two ends spending about 1580 ms of CPU each —
  consistent with the actuator's 50 ms holds running out rather than a lost
  wake.
• A flaky test is disabled at once, never re-run: this PR disables
  blocking_read_window in src/redlist.rs behind the existing issue, sets
  its status to expected-red, and adds the new evidence lines plus a note
  that its verdict rests on a 3 s duration inside a QEMU test, which the
  owner rules is metal-only — PR No QEMU test measures time, and audio is judged on metal only #562 is removing such verdicts.

Test plan

• cargo test --lib — EXIT=0 (384 passed, 0 failed, 1 ignored)
• cargo test --test toyos-build -- --list — EXIT=0
• cargo run -- --known-red blocking_read_window — YES, disabled

🤖 Generated with Claude Code

[Japabu]

Review of #577 at c0a000eb.

CI host run 36420477617: success at c0a000eb. The PR is not a draft. The host gates were re-run in the worktree: cargo test --lib EXIT=0 (384 passed, 1 ignored). cargo test --test toyos-build -- --list EXIT=0, and it prints [toyos] disabled: blocking_read_window. cargo run -- --known-red blocking_read_window EXIT=0 and prints YES, disabled. Net +15 −1: the issue +10 −1, the redlist row +4, production 0.

BLOCKER

• src/redlist.rs:28, issues/build/blocking-read-window-reds-beside-other-guests.md:33 — the branch disables the test as main's flake, but no measurement supports that attribution.
  • The record since 09-27 23:05: 32 of 32 PASS on heads other than Storage: file servers for DATA, the log and the boot volume; the kernel's NVMe and FAT go #536 in the orchestrator's runs, and 9 of 9 PASS on main's CI nightlies (36297455432 … 36388022685). Storage: file servers for DATA, the log and the boot volume; the kernel's NVMe and FAT go #536 passed 4 times at earlier heads, then failed 2 of 2 at 5235eda7.
  • Storage: file servers for DATA, the log and the boot volume; the kernel's NVMe and FAT go #536 puts every file client's reply wait on a blocking pipe read, and watch-window holds each of those up to 50 ms (kernel/src/watch.rs:227). Both reds show the signature of every hold lapsing: about 107 ms per round trip, and about 1.58 s of CPU at each end.
  • Measure before disabling: a same-session A/B of blocking_read_window on 5235eda7 and on its merge base, both started together, at least 10 runs each. The disable stands only if main reds at Storage: file servers for DATA, the log and the boot volume; the kernel's NVMe and FAT go #536's rate. Otherwise the red is Storage: file servers for DATA, the log and the boot volume; the kernel's NVMe and FAT go #536's regression and goes back to Storage: file servers for DATA, the log and the boot volume; the kernel's NVMe and FAT go #536.

NOTE

• issues/build/blocking-read-window-reds-beside-other-guests.md:3 — kind: finding was reviewed here and still owns a disabled test. issues/README.md says a finding is promoted to defect or folded at its next review, so promote it.
• issues/build/blocking-read-window-reds-beside-other-guests.md — no owner is named for the disable. CLAUDE.md asks for ownership, evidence and an exit.
• tests/toyos.rs:11478 — this is the only guest arm that stages a post between the condition read and the park. blocking_read_stress on the shared boot (tests/toyos.rs:489) runs without the window, and loom_watch checks the model on the host only. While the test is disabled, the notified-bit commit has no guest negative control, and watch.rs's window module, toyos-sched HELD/STEP and window_held have no reader that runs.
• src/redlist.rs:28 — No QEMU test measures time, and audio is judged on metal only #562 keeps blocking_read_window enabled and rewrites its verdict. Whichever of the two lands second must settle this row, or the test stays off after No QEMU test measures time, and audio is judged on metal only #562.

REMOVE

• issues/build/blocking-read-window-reds-beside-other-guests.md:11 — "--known-red blocking_read_window answers NO": this branch makes it false.
• issues/build/blocking-read-window-reds-beside-other-guests.md:13 — "Sightings, all on 2026-09-26": now false, and it is a date.
• issues/build/blocking-read-window-reds-beside-other-guests.md:33-35 — "2 of 2 red … only 28 of 500": the nightly said 30 of 500 (536r13-nightly.log:884), so the line misquotes the record.
• issues/build/blocking-read-window-reds-beside-other-guests.md:36-39 — the round-13 reviewer's inference is second-hand, and "round-13" will rot. "Leaves the wake and pipe path alone" misleads: Storage: file servers for DATA, the log and the boot volume; the kernel's NVMe and FAT go #536 moves file calls onto the pipe wait that the actuator holds.
• issues/build/blocking-read-window-reds-beside-other-guests.md:54-55 — the "3 s duration … PR No QEMU test measures time, and audio is judged on metal only #562 is removing" sentence cites an open PR, which will rot. It also misleads: at about 107 ms per round trip, 500 rounds take about 53 s, so this mode still reds at the 30 s run ceiling (tests/toyos.rs:11487) after No QEMU test measures time, and audio is judged on metal only #562.
• PR body — the reviewer's finding and "PR No QEMU test measures time, and audio is judged on metal only #562 is removing such verdicts" would become main's merge record. Remove both.

SEND BACK

[Japabu]

Closed without landing. A same-session A/B (orchestrator, 2026-09-28): blocking_read_window went red 2 of 10 on PR #536's head 06c6195 and 0 of 10 on main cd2e630, interleaved; with the earlier 2 of 2 on #536 and 32 of 32 green off #536, the red is #536's regression, not main's flake. It goes back to #536.