STATE-CURRENT: cuCtxCreate 999 root-caused and fixed; UVM runtime progress

- GR-info indices 7/9/0x17/0x22 were zero in the emulation (shader-pipe
  sub-count among them); filling real-device values clears the previously
  fatal context check
- client now runs inside UVM for minutes instead of failing in seconds
- next wall: push-data operand translation (fix in); frontier notes updated

1 files changed, 19 insertions, 13 deletions

diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md
index 0a5e30e..9543100 100644
--- a/STATE-CURRENT.md
+++ b/STATE-CURRENT.md
@@ -1,6 +1,6 @@
 # Open-IOV Current State
 
-> **Snapshot: 2026-09-30 00:40.** This is a dated public status page, not live
+> **Snapshot: 2026-09-30 05:05.** This is a dated public status page, not live
 > state; it is refreshed on every progress check. Live working notes are
 > maintained outside this repository; the public known-knowns/unknowns document
 > is authoritative here:
@@ -28,7 +28,7 @@ meant to execute on the physical GPU.
 | Stock 570.144 guest driver probe / `RmInitAdapter` | ✅ |
 | `nvidia-smi -L` enumerates the emulated TU104 | ✅ |
 | CUDA userspace: `cuInit`, `cuDeviceGetCount`, `cuDeviceGet` | ✅ |
-| `cuCtxCreate` returns | ⏳ **frontier** |
+| `cuCtxCreate` returns | ⏳ **frontier** - the previously fatal check now passes; the final result is being captured |
 | `cuMemAlloc` + `cuMemcpy` roundtrip (`ALL OK` in the smoke test) | ❌ not reached |
 | Full `nvidia-smi` output | ❌ (faults on the CUDA path) |
 | CUDA kernel execution (`vectorAdd`) | ❌ not started (forwarding layer absent) |
@@ -44,9 +44,9 @@ chain succeeds.
 ## Right now (frontier)
 
 - The stock guest driver initializes fully; the CUDA client reaches
-  `cuCtxCreate` within seconds and now fails with a forced `rc=999` a few
-  seconds after the compute-channel phase (a timeout path, not an RM error
-  record).
+  `cuCtxCreate` within seconds and - with the latest fix - passes the check
+  that previously forced a `rc=999` timeout, continuing into UVM for minutes.
+  The final result is being captured on fresh boots.
 - The per-channel completion counters in guest memory are enumerated,
   registered and published; the client's per-channel waits clear, and the
   per-channel GPFIFO work on copy channels is consumed.
@@ -71,14 +71,20 @@ chain succeeds.
   them through the exact counter slot makes **all 20/20 channel releases
   land** (verified on live boots). The failure is unchanged by that fix, so
   the counter path was not the gate.
-- **The remaining wall is a silent post-compute-phase rollback**: about a
-  second after the performance-boost control the guest tears down the 20
-  channels and returns the context error - while every resource-manager
-  control was answered successfully and the guest kernel logs no error. The
-  profile points at the rollback's RPC frees with the GSP health check
-  running inside the RPC poll.
-- Active work: kernel-return probes on the UVM channel lifecycle plus
-  failure-instant trace capture, to name the event the rollback waits on.
+- **The context-creation error is root-caused and fixed**: the emulated GR
+  information table left four indices zero (the shader-pipe count and
+  related clock fields), so the client's clock-table validation rejected the
+  context. Filling them with the real-device values makes the client sail
+  past the previously fatal check and **run inside UVM for minutes** -
+  channels advancing, memsets and releases executing - instead of failing in
+  seconds.
+- **Next wall is the push-data path**: with context creation cleared, the
+  copy-engine pushes need their operand translations; routing those through
+  pinned translations (previously a missing-entry failure) now lets the
+  inline writes execute (`memset=860/1653`, `ringops=1687` live).
+- Active work: capture the final context-creation result on a fresh boot,
+  then move to the allocation/copy roundtrip; runs that end with the
+  guest-agent unresponsive are the known trace-flood starvation, not a panic.
 - Guest health note: agent/SSH timeouts during a run are usually guest-agent
   starvation and recover when the client stops; one hard wedge occurred only
   when pushed memsets were re-enabled, so bulk pushed operations stay disabled