STATE-CURRENT: 15:12 check-back snapshot (post-reboot GR campaign; commit/RAMFC wall)

1 files changed, 20 insertions, 30 deletions

diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md
index e918502..4f4a82a 100644
--- a/STATE-CURRENT.md
+++ b/STATE-CURRENT.md
@@ -1,6 +1,6 @@
 # Open-IOV Current State
 
-> **Snapshot: 2026-10-02 ~14:12.** This is a dated public status page, not live
+> **Snapshot: 2026-10-02 ~15:12.** 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:
@@ -81,35 +81,25 @@ chain succeeds.
 
 ## Right now (frontier)
 
-- **Post-reboot H1 safe half is GREEN (2026-10-02 ~13:55).** After the
-  approved reboot (boot 13:39), the module rebuilt byte-identical
-  (`e4f5d7cc...`) and one supervised module-owned cycle with the promote gate
-  disabled (`gsp_phys_rmcall_engine=1`, `gsp_phys_rmcall_gr_promote=0`) ran
-  the whole GR pre-promote half on the live GSP-RM: geometry (`raw=0xf2d00`,
-  `maxSubctx=64`), a zeroed 307-page contiguous context buffer
-  (`pa=0x5b0000000 va=0x2200000 total=0x133000`), its PDB mapping, the V5 GR0
-  channel and the `TURING_COMPUTE_A` compute object; `PROMOTE_CTX` was never
-  sent and the ladder stopped before BIND with `-EOPNOTSUPP`
-  (`rm_call_ctx: prepared=1 valid=0`). Release was latched and clean
-  (distribution driver rebound, protected region down, exactly 5
-  power-domain locks, 0 rail cycles, pstore empty, same boot). The p6h1b
-  assert `0x52a8b04` was decoded statically to the server's
-  `grctxPromoteAPI` path, and the 570.144 client confirms the canonical
-  external-VAS shape (PA-only `bInitialize=1 bNonmapped=1` init entry, then
-  VA-only `bInitialize=0 bNonmapped=0` promote entry) that the next
-  bisection variant implements. Follow-up (post-approved-reboot, same day):
-  the two-phase variant 2 and the zero-field VA-only variant 4 both wedged
-  with the identical assert and LOGINIT
-  `NV_ERR_OBJECT_NOT_FOUND` (0x57) on the VA resolve, while the PA-only
-  nonmapped step is accepted every time - the entry fields are not the wall;
-  the server has no memdesc/vaList record for the external-VAS context VA.
-  Candidate (c) is therefore implemented default-off: mode 6 allocates an
-  `NV01_MEMORY_VIRTUAL` (class 0x70) VA-range object on the ladder VAS and
-  sends a no-entry `PROMOTE_CTX` with `hVirtMemory` (mode 7 is the bare
-  `virtAddress+size` no-entry variant), so the server creates the memdesc itself.
-  The host is in the designed locked fail-safe awaiting the approved reboot;
-  next: one supervised mode-6 cycle, commit only after `REAL GR SEM OK`.
-  Evidence: `backups/evidence-20261002-gr/` (private).
+- **Post-reboot GR campaign: the wedge class is retired; the wall is the
+  context commit/RAMFC path (2026-10-02 ~15:05).** The paused reboot was
+  approved and executed (~14:20); `nvidia-smi -L` is green, the GPU is bound
+  to the distribution driver, and the host is healthy. Eleven supervised
+  default-off GR cycles (modes 6-17, one attempt each, every release latched
+  and clean, zero rail cycles, pstore empty, no reboot) separated what had
+  been one opaque promote assert into soft `0x40 NV_ERR_INVALID_STATE` checks:
+  the entry-based VA promote asserts because the external virtual address space
+  carries no server-side VA booking, so the physically-backed PA init entry is
+  accepted every time; the kernel-managed channel route is accepted but still
+  fails the same soft check after the physical context memdesc is satisfied;
+  and even with the server owning the context buffers the channel still faults
+  `CTXNOTVALID` - **the wall is the commit/RAMFC path itself, not context-buffer
+  ownership.** The failing log record's format pointer is encrypted in the
+  shipped image, so naming the exact check needs a live server-memory read or a
+  static decode. Current wall: commit the GR engine context and make the engine
+  execute the submitted compute block. Next: host `vectorAdd`, then guest GR
+  forwarding. All parameters remain default off; the software path is unchanged
+  with them off.
 - **Guest-submission relay and fault relay landed, default off (P6c
   C0/C1/C3, 2026-10-02 07:43-08:07).** With `gsp_phys_relay=1` the physical
   engine authors the guest CE copy and the release semaphore: the