From 080ac261972400c9bd6a1398440b01c346d4df33 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Mon, 24 Aug 2026 02:30:29 +0000 Subject: [PATCH] docs: the stuck-wait probe and its healthy-run baseline The instrument is built (canary auto/re-wait-timeout-probe 83ad0eb3f, binary archived at /sylph-home/re/bin/waitprobe): consecutive timeouts on the same object, per thread, logged at 100 and then every 500 - self-selecting where the global kHighFrequency flag was unusable. The control is measured: a 25-minute Stage 02 run that never froze produced 27 lines, ALL one thread polling one Event at guest VA BE56BB5C with a ~30 ms timeout, whose streak reached 8000 while the game ran perfectly. So the probe is quiet, not silent - the first draft of the cvar help said silent and that is corrected here - and the freeze signal will be a NEW (thread, object) pair rather than the presence of output. Not settled: the freeze did not reproduce this run, so there is no frozen sample to compare against yet. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE --- docs/re/mission-freeze-resume-spin.md | 33 +++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/docs/re/mission-freeze-resume-spin.md b/docs/re/mission-freeze-resume-spin.md index f775ff80..7019b888 100644 --- a/docs/re/mission-freeze-resume-spin.md +++ b/docs/re/mission-freeze-resume-spin.md @@ -336,3 +336,36 @@ because the boot was not going to finish. the Release binary has **no DWARF** (`No debugging symbols found` — symtab only), so `info args` is unavailable and the `PPCContext*` would have to be dug out of a stack frame by hand. Fragile, but free. + +## ✅ 2026-08-24 (later) — the instrument exists: `--log_stuck_waits` + +Canary branch **`auto/re-wait-timeout-probe`** (`83ad0eb3f`, off the upstream +baseline) adds a counter in `xeKeWaitForSingleObject`: consecutive `X_STATUS_TIMEOUT` +results on the **same object**, per thread, logged at 100 and then every 500. +It is self-selecting — a wait that is being satisfied never builds a streak — so +it can be left on where the global high-frequency flag cannot. Binary archived at +`/sylph-home/re/bin/waitprobe/xenia_canary`; drive it with +`EXTRA_FLAGS=--log_stuck_waits=true`. + +**Healthy-run baseline, which is what a frozen run has to be compared against.** +Over a 25-minute Stage 02 run that never froze, the probe emitted **27 lines, +all of them the same pair**: + +``` +w> F800004C [wait-probe] thread F800004C has timed out N times in a row on + object BE56BB5C (type 2), timeout=18446744073709251616 +``` + +— one thread polling one **Event** (`XObject::Type` 2) at guest VA `BE56BB5C` +with a relative timeout of `-300 000` × 100 ns ≈ **30 ms**. That is a legitimate +poller, not a symptom, and its streak reached 8 000 while the game was running +perfectly. + +🔴 **Corrected before it became folklore:** the cvar's help text first claimed the +probe is *silent* on a healthy run. It is not — it is *quiet*, and one poller +dominates. The freeze signal will therefore be the **appearance of a new +(thread, object) pair**, not the presence of output. + +**Not settled:** the freeze did not reproduce in this run, so there is no frozen +sample to compare yet. That is the whole of the next step, and the instrument and +its control are now in place for it.