STATE-CURRENT: 12:16 check-back snapshot (GR stage-4 frontier: PBDMA fetches GPGet=1, ctxsw fault 0x2c; 10 clean no-wedge cycles; GR fixes committed)

1 files changed, 21 insertions, 13 deletions

diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md
index 71da3bc..17aab60 100644
--- a/STATE-CURRENT.md
+++ b/STATE-CURRENT.md
@@ -1,7 +1,7 @@
 # Open-IOV Current State
 
 > **Snapshot: 2026-10-05 (reorganized; simulator status current 2026-10-04,
-> physical/guest campaign data as of 2026-10-05 ~12:10; debugging-options
+> physical/guest campaign data as of 2026-10-05 ~12:16; debugging-options
 > catalogue added 2026-10-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
@@ -37,9 +37,12 @@ isolation, performance, portability).
    default off), the V5 channel and the client `MAP_MEMORY_DMA` path, the
    `TURING_COMPUTE_A` compute-object alloc succeeds, the promote/commit passes
    and the ladder completes stage 3 (`hGr`, clean releases, no server wedge,
-   no reboot needed) - the first time. The new wall is stage 4: the submitted
-   GR semaphore push is not consumed by the engine (`GPGet=0`, no release,
-   `-110`).
+   no reboot needed) - the first time. **Update 2026-10-05 ~12:16:** the
+   stage-4 frontier moved - with a client page-table install (`UPDATE_PDE_2`)
+   plus a cache flush/PT refill, the GR push is now fetched (`GPGet=1`), but
+   the GR engine faults during context switch
+   (`ROBUST_CHANNEL_GR_FAULT_DURING_CTXSW`), so no release lands (`-110`); 10
+   clean cycles, no wedge, no Xid.
 - **Guest frontier: FIRST GREEN END-TO-END GUEST CUDA, NOW UNDER HARDENING
   (2026-10-04 ~16:20; hardening 2026-10-05 overnight).** The emulation-only
   ("no-claim") campaign runs an unmodified guest CUDA program to completion
@@ -109,9 +112,12 @@ isolation, performance, portability).
     also disables split VAS management (`RMSplitVasMgmtServerClientRm=0`) and
     the client sends `MAP_MEMORY_DMA` for the ladder buffers - on a shared VAS
     the server owns the lower page tables, so raw client PTEs are not
-    authoritative. New wall: stage 4's GR push is submitted but not
-    fetched/executed by the engine (`GPGet=0`, `-110`). Next: root-cause the
-    stage-4 non-consumption (GPFIFO fetch, server PDB, doorbell).
+    authoritative. **Update 2026-10-05 ~12:16:** the stage-4 frontier moved -
+    a client page-table install plus a cache flush/PT refill makes the GR
+    PBDMA fetch the submitted push (`GPGet=1`), but the GR engine faults during
+    context switch (`ROBUST_CHANNEL_GR_FAULT_DURING_CTXSW`), so no release
+    lands (`-110`). Next: root-cause the ctxsw fault (engine-context buffer
+    init, subcontext header, or a VA+PA promote); 10 clean cycles, no wedge.
 2. **Hardening the accepted no-claim path.** The first green guest CUDA
    acceptance has landed and is holding; the residual classes are (a) corruption
    via a late first decode behind pump backlog (~3-5% of runs; the experiment
@@ -310,7 +316,7 @@ chain succeeds.
 
 | ID | Milestone | When | State |
 |---|---|---|---|
-| MS-20261005-02 | GR promote wall crossed on the shared-VAS+srvctx path; new wall = stage-4 push not consumed | 2026-10-05 ~12:00 | srvctx registry (`RMSetClientRMAllocatedCtxBuffer=0`, `RMSplitVasMgmtServerClientRm=0`) + V5 + mode 17 + client `MAP_MEMORY_DMA`; stage 3 completes (`hGr`, clean release, no wedge); stage 4 `GPGet=0`/`-110` |
+| MS-20261005-02 | GR promote wall crossed on the shared-VAS+srvctx path; new wall = GR ctxsw fault after push fetch | 2026-10-05 ~12:16 | srvctx registry (`RMSetClientRMAllocatedCtxBuffer=0`, `RMSplitVasMgmtServerClientRm=0`) + V5 + mode 17 + client page-table install/cache flush; stage 3 completes (`hGr`, clean release, no wedge); stage 4 fetches (`GPGet=1`) but GR faults during ctxsw (`ROBUST_CHANNEL_GR_FAULT_DURING_CTXSW`), no release, `-110`; 10 clean cycles |
 | MS-20261005-01 | Hardening the accepted no-claim path (hazard classes closed; rates up) | 2026-10-05 overnight | per-op once bitmap + epoch/content-hash gate + grace 15 s (`b645cf6b`, `3b094c2d`, `c3cd4631`); first-attempt 86% -> ~94-95%; fakes/run 3.39 -> 0.61; hold-all-unreadable/25 s experiment committed (`4115f1dd`, module `e7ff3bf7`), campaign `239..262` validating (`239-242` green; `241a`/`243a` infra retries; `243b` live) |
 | MS-20261004-04 | **First green end-to-end guest CUDA acceptance** | 2026-10-04 ~16:20 | `noclaim38/39/40` `MAIL` + `VADD n=1048576 bad=0 checksum=392344090.500000` + `STATUS OK`, deterministic, committed `cf6ff542`; 14/15 green in the repeat campaign |
 | MS-20261004-01 | No-claim bridge reaches the guest `vectorAdd` launch | 2026-10-04 ~14:45 | guest-truth pins + DtoH mail read-back fix + FB 512 MiB; `cudaMalloc` unblocked; no `STATUS OK` yet |
@@ -354,11 +360,13 @@ chain succeeds.
   requirements were source-confirmed and implemented: on a shared VAS the
   server owns the lower page tables, so the client must send
   `MAP_MEMORY_DMA` for the ladder buffers, and GSP-RM only serves that RPC
-  when the srvctx registry also sets `RMSplitVasMgmtServerClientRm=0`. New
-  wall: stage 4's GR semaphore push is submitted but not fetched/executed by
-  the engine (`GPGet=0`, no release, `-110`). All ladder cycles released the
-  device cleanly (no reboot, no Xid, pstore empty); the fixes are uncommitted
-  in the working tree.
+  when the srvctx registry also sets `RMSplitVasMgmtServerClientRm=0`. **Update
+  ~12:16:** the stage-4 frontier moved - with a client page-table install
+  (`UPDATE_PDE_2`) plus a cache flush/PT refill, the GR PBDMA now fetches the
+  submitted push (`GPGet=1`), but the GR engine faults during context switch
+  (`ROBUST_CHANNEL_GR_FAULT_DURING_CTXSW`), so no release lands (`-110`). All
+  ladder cycles released the device cleanly (no reboot, no Xid, pstore empty);
+  the fixes are now committed (`79d5b65e`).
 - `MS-20261005-01` **Hardening the accepted no-claim path (2026-10-05
   overnight).** Three kernel-side fixes closed the replay/fake hazard classes
   after the first acceptance: (1) a held-entry retry must not re-run completed