STATE-CURRENT: 17:12 check-back snapshot (GR promote wall = externally-owned VAS; shared-VAS opens 0xc5c0 object-alloc wedge; host in locked fail-safe pending reboot approval)

1 files changed, 25 insertions, 25 deletions

diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md
index 153c131..cad25ce 100644
--- a/STATE-CURRENT.md
+++ b/STATE-CURRENT.md
@@ -1,6 +1,6 @@
 # Open-IOV Current State
 
-> **Snapshot: 2026-10-02 ~16:12.** This is a dated public status page, not live
+> **Snapshot: 2026-10-02 ~17: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,30 +81,30 @@ chain succeeds.
 
 ## Right now (frontier)
 
-- **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. The campaign has since captured the real guest driver's exact
-  9-entry promote shape (mode 19) and replayed it; that MAIN-VA entry on the
-  externally-owned space wedged the server again (no reply) and the fail-safe
-  held the device until an approved reboot restored it (~15:46); the wall is
-  unchanged. Next safe routes: forward the guest's own captured GR operations
-  (P6c) or the kernel-managed non-MAIN entry set.
+- **GR context campaign: the promote-side wall is root-caused; the current
+  wall is the shared-management GR object alloc (2026-10-02 ~17:10).** The
+  long-running context-promote wall was the ladder's virtual address space
+  being allocated as *externally owned* (the client owns page tables, VA
+  bookings and engine-context commitment), so the server skipped the
+  engine-context commit and asserted when a promote VA had never been booked.
+  Switching the ladder's address space to *shared management* with a
+  UVM-sized (128 TB) range is a default-off change now in the working tree; it
+  gets past the promote wall entirely - the shared space is accepted and a
+  kernel-managed channel allocates (both firsts on this path) - but the next
+  resource-manager call, the `TURING_COMPUTE_A` compute-object alloc, then
+  stops replying and wedges the server (no reply; the fail-safe holds the
+  protected region). The same alloc wedges on both the kernel-managed and the
+  normal channel variants, so the gate is the server-internal
+  context/global-buffer mapping under shared management, not the channel kind
+  or the promote shape. Two supervised wedges in this window were each cleared
+  by an approved reboot (the host is currently held in the locked fail-safe and
+  a further reboot is pending approval). A new untested candidate
+  (kernel-managed channel plus a no-entry virtual-memory promote) is built
+  default-off. Current wall: commit the GR engine context and make the engine
+  execute the submitted compute block. Next routes: the static root-cause of
+  the compute-object construct, forwarding the guest's own captured GR
+  operations, or the new candidate. 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