x86: blocking poll() on a connected TCP fd returns ready=0 revents=0x0000 after its full 5 s timeout although the peer wrote and exited (1/24 beast KVM boots)

[ryanbreen]

Summary

On beast breenix-x86 (KVM, -cpu host, testing,external_test_bins), one
boot in 24 at fix/568-poll-wedge @ efe08b17 has poll_tcp_oracle's stage-3
poll() return ready=0, revents=0x0000 after its full 5000 ms timeout,
even though the peer child ran, wrote and exited cleanly while the parent was
parked:

[POLL_TCP_ORACLE:FAIL:late_lost_wake:ready=0 revents=0x0000 elapsed_ms=5040 delay_ms=80]

This is not the strand that #568's scheduler reorder fixes. The thread is
resumed — by its own timeout, not by the data:

3037: Saved kernel context for blocked thread 23: RIP=0x8000226672 RSP=0xffffc90000c172c8
3470: Process 21 'poll_tcp_oracle_child_21' (thread 35) exited with code 0
3592: Restored kernel context for thread 23: RIP=0x8000226672 RSP=0xffffc90000c172c8
3616: Process 13 'poll_tcp_oracle' (thread 23) exited with code 1

The peer stamps a readiness token, sleeps 80 ms, writes the payload and exits 0
— all of that happens (line 3470) while the parent is blocked from line 3037.
The parent is not woken by the write; it waits out the whole 5 s. And on the
timeout return the re-scan still reports the fd as not readable
(revents=0x0000), which is the part that is hardest to explain away as
scheduling latency.

What is and is not established

Established from the kernel serial: the parent was parked across the peer's
entire lifetime; the peer exited 0; the poll returned 0 ready fds with empty
revents after the full timeout.

Not established: whether the peer's send() was actually issued and its
readiness lost, or whether the peer's own recv of the token never completed
so it never wrote at all. late_peer() exits 0 either way
(let _ = socket::send(...)), so its exit code does not discriminate. A
first step is to make that path report, so the next occurrence separates
"readiness lost" from "peer never wrote".

Rate

1 in 24 merge-candidate boots (~4%) in the round-3 interleaved A/B. The
reorder-reverted arm cannot be compared on this: it emitted a verdict in only
4 of 16 boots because the oracle was stranded in 12 of them.

Serials (in-repo)

• docs/planning/green-program/sockets/serials/x86-r3-CAND-late-lost-wake-boot9-kernel-20260829.txt
• docs/planning/green-program/sockets/serials/x86-r3-CAND-late-lost-wake-boot9-user-20260829.txt

Per-boot table: docs/planning/green-program/sockets/AB-2026-08-29-round3.md.

Why this matters for #568

#568 is about a blocking poll() on a connected TCP fd. The hard wedge
(defect 1) and the never-rescheduled strand (defect 2) are both fixed on that
branch and proven. This is a third, rarer shape in the same syscall, and it is
the reason #568 is not being claimed closed.

[ryanbreen]

Kept open, and subsumed by #697's discrimination work

This records a possibly-real KVM residual and it is not closed by the #568
landing. Two corrections and one dependency.

Correction 1 -- the rate here is the bespoke battery's, not the shipping
gate's. This issue and EVIDENCE-2026-08-29.md §9 both say "about 1 boot in
24", measured on the beast KVM A/B battery. On docker/qemu/run-x86-boot-tests.sh
-- the default x86 gate, TCG -- the same bytes produced FAIL:late_lost_wake on
20 of 30 boots (plus 6 late_window_missed and 4 PASS: 26/30 FAIL overall).
That number appeared in no note and no issue at the time and is stated here now.

Correction 2 -- the reds as they stand cannot be triaged. The
late_lost_wake arm waitpid()s the peer and then reports without reading the
peer's exit status or its token_ms/write_ms stamps, so the verdict cannot
distinguish "the kernel lost the wake" from "the peer never got scheduled to
write". Under TCG the second explanation is entirely plausible, which is why the
20/30 cannot be read as 20 kernel defects -- and equally why the 1/24 on KVM
cannot be read as a false alarm. Both numbers are undiscriminated.

Dependency. Carrying the peer's exit status and stamps into the failure
string is item 3 of #697. Until that lands there is no way to tell whether this
1/24 is a real lost wake; after it lands, this issue should be restated with the
rate measured on the default gate rather than the bespoke one, and then either
diagnosed or closed on evidence.

Meanwhile the oracle is un-wired on x86 in the #568 landing commit, so this
residual is not currently observed on any x86 gate -- it is unobserved, not
fixed. The oracle stays wired and green on aarch64 (50/50 on the
service-sequence gate, marker present and PASS in 50/50 preserved serials).

[ryanbreen]

2:1 triage sweep, 2026-08-29 — leave-with-evidence

Read-only verification pass over this issue at main 782ab96f. The sweep's verdict, verbatim:

#693 — x86 frame-custody gate: poll oracle late_lost_wake / late_window_missed

Verified current. Last comment already corrects the rate (26/30 FAIL on the default TCG gate,
not 1/24) and identifies the real blocker: the late_lost_wake arm doesn't read the peer's exit
status/stamps, so kernel-vs-scheduling-starvation can't be discriminated. That work is item 3 of
#697. Kept open, "subsumed by #697's discrimination work" per its own text.
Verdict: LEAVE-WITH-EVIDENCE. No new evidence to add; correctly blocked on #697.