x86: loopback_recv_wake reader-EOF (reader_exit_15, 9.5s stall) — unfiled, main-baseline N=20 does not reproduce

[ryanbreen]

Signature

docker/qemu/run-boot-parallel.sh 5 on beast (breenix-x86 Incus container, -smp 1,
testing,external_test_bins profile). Observed once during T3-G PR2 round-1 x86 gate work on
branch fix/607-576-zero-pc-family @ c9c75c3b (strict-2 batch, test 2 of 5):

TEST_TALLY: exited=102 nonzero=2 failed=[loopback_wake_test_child:15,loopback_wake_test:1]

Userspace side:

LOOPBACK_WAKE_TEST: eof wait_ms=9472 bytes=0
[TEST:userspace:loopback_recv_wake:FAIL:reader_exit_15]

The reader stalls ~9.5s on a loopback socket read, then gets EOF with zero bytes rather than the
expected payload. The boot completes and reports a tally (not a livelock/hang like #630's shape) —
this is a distinct failure class from the garbage-fd sys_read livelock tracked in #630.

Rate observed

1/20 on branch fix/607-576-zero-pc-family (T3-G PR2 round 1: 4 batches of run-boot-parallel.sh 5 = 20 boots; floor batch + 3 strict batches). Evidence preserved at
beast:/root/pr2-evidence/strict2_loopback_recv_wake_fail/.

Main-baseline check (T3-G PR2 round 2)

Ran the identical harness (4× run-boot-parallel.sh 5 = 20 boots) at main @ 9602d6d4 (merge
of #632) as a dedicated main-baseline comparison. 0/20 occurrences of this shape. (The run did
reproduce #630's unrelated livelock shape at 2/20 — see comment on #630 — but never this
reader-EOF/reader_exit_15 shape.)

This does NOT establish the shape is main-clean or branch-introduced. N=20 against a single
observed occurrence at 1/20 has essentially no power to distinguish "pre-existing at ~5% rate,
just didn't land in this sample" from "branch-specific." Stated plainly, not concluded: main did
not reproduce it in this sample; whether it is pre-existing flakiness or exposed/introduced by the
branch under test is unresolved and needs either a much larger main-baseline sample or a targeted
repro under the loopback wake test in isolation.

Where it does NOT match

Not on the pre-adjudicated x86/aarch64 field-signature list (#555, #536, #586, #612, #613, #599,
#622-624, #627, #628) per round-1's cross-check; #586 in particular is a different reader_exit
wake-loss shape (starved wake-loss misreport) that completes differently — this one specifically
reports EOF-with-zero-bytes after a ~9.5s stall, not a wake-loss tally mismatch. Worth checking
for relation to #586 more carefully if it recurs, since both live in wake/EOF territory on the
loopback path, but they are not being treated as the same issue here without more evidence.

Evidence

• Branch occurrence (round 1): beast:/root/pr2-evidence/strict2_loopback_recv_wake_fail/
• Main-baseline round (round 2, no reproduction): beast:/root/pr2-evidence/main-baseline/
• Mirrored tallies:
  /private/tmp/claude-501/-Users-wrb-fun-code-breenix/14b2f8b6-d391-4fe4-b1ff-96563e0f434a/scratchpad/t3g/pr2/pr2-x86-baseline.md

Provenance

T3-G PR2, fix/607-576-zero-pc-family x86 gate slot (round 1) + main-baseline side-quest
(round 2).