STATE-CURRENT: pinpoint the stall - cudaEventSynchronize after a default-stream record never completes (minimal repro); host event post path still fails with EINVAL; sema side verified healthy at the stall; cross-boot matrix r177-r179

1 files changed, 15 insertions, 0 deletions

diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md
index a79d5f2..5322e98 100644
--- a/STATE-CURRENT.md
+++ b/STATE-CURRENT.md
@@ -273,6 +273,21 @@ isolation, performance, portability).
        that does not land where the launch's data fill later reads the operand (the
        vidmem write path vs the fill's read path divergence; analysis and the ranked
        ledger fix are in the private handoff, cont. 23).
+      **Update 2026-10-17 ~01:00 (stall pinpointed on r179; diagnostics only, no tree change yet):**
+       a minimal repro (`cudaEventCreate` + `cudaEventRecord` on the default stream +
+       `cudaEventSynchronize`) sits forever after the record - the first CUDA call pinned down
+       as a hard hang. A 3-stream workload using event record/wait/elapsed time stalls even as
+       the very first client of a fresh boot (intrinsic, not position- or poison-dependent;
+       unclean client kills were tested and do not break the next client). On a used boot the
+       user's `victory_mail`/`victory_matmul` hit the same wait: the client spins in driver
+       userspace while a background worker polls the interrupt-service RM control once per
+       second. The host's event-registration table and post path exist (register on NV01_EVENT
+       alloc, retire on free, per-channel/all post helpers) and the stall windows still show
+       frequent post failures with EINVAL; the host sema side is verified healthy at the stall
+       (client pushes decode, pool releases apply to the correct page, then the machine idles).
+       Cross-boot matrix: mail/matmul/smiley green early; strided/atomics/memset2d/saxpy fail
+       fast on the remaining data class at any position; event-sync stalls always. Next: fix
+       the completion post so the recorded event wakes (details in the private handoff, cont. 24).
       **Update 2026-10-16 ~18:40 (reliability wave m160-m162 + harness fixes; verified battery, no reboots):**
        five cycles (r163-r167) landed and verified the bounds of the earlier "STATUS FAIL /
        freeze" repro. Fixed and live-verified across boots: `victory_mail` and