STATE-CURRENT: 14:07 check-back - 0x59 root-caused (missing pre-boot init handshake); error journal collapsed 851->4; cycles 4-7 release clean

1 files changed, 28 insertions, 5 deletions

diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md
index b49fd24..5ec4667 100644
--- a/STATE-CURRENT.md
+++ b/STATE-CURRENT.md
@@ -1,6 +1,6 @@
 # Open-IOV Current State
 
-> **Snapshot: 2026-10-01 12:12.** This is a dated public status page, not live
+> **Snapshot: 2026-10-01 14:07.** 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:
@@ -31,7 +31,19 @@ meant to execute on the physical GPU.
 | `cuCtxCreate` returns | ✅ (the whole smoke test now completes) |
 | `cuMemAlloc` + `cuMemcpy` roundtrip (`ALL OK` in the smoke test) | ✅ payload roundtrip verified 64/64 in the guest |
 | Full `nvidia-smi` output / kernel launch | 🟡 the static runtime now initializes end-to-end with **real releases** (`cudaGetDeviceCount`/`cudaSetDevice`/3×`cudaMalloc`/2×`cudaMemcpyHtoD`/`kernel launch`/`cudaGetLastError` all `rc=0`) and queues a kernel launch; execution awaits the backend |
-| CUDA kernel execution (`vectorAdd`) | 🟡 execution backend: physical ownership + firmware staging verified; the unbind/rebind freeze hazard is mitigated by the supervised D0 power-domain lock (3/3 green claim cycles), and the real FB size (8 GiB) and boot layout are verified live. The supervised live secure-verification run raised the protected region (WPR2 up) for the first time, then proved a secure-verification-only carve is not host-recoverable on this fused part, so the fail-safe held the device and an approved reboot restored it (distribution driver rebound, GPU healthy). That one-way stage is now retired: the only device-write path is a single full boot lifecycle (secure verification -> bootloader -> RISC-V start -> resource-manager initialization), whose code is implemented in the module sources and has now run live: the first real boot raised WPR2, passed Booter Load and went RISC-V active, and the module received the first real GSP-RM message (event 0x1002); init-done (0x1001) and a clean release are the next steps (see the 2026-10-01 section). A second live boot on 2026-10-01 proved the full boot sequence again (protected region up, bootloader halt, RISC-V active, first GSP-RM message) and reached the resource-manager's inline CPU-sequencer request; the host executor rejected the real request because of an over-strict internal size cap, which was found with a raw read of the message in host memory, fixed, and rebuilt. Cycles 2-3 then ran the real sequencer and received init-done with an RM init failure (`0x59`), which reproduces on a verified matching firmware image; the server's own shutdown supplied the last handoff bit, so each failed cycle completed a **clean release without a reboot**. The next step is to diagnose the `0x59` from the server's own error journal, whose capture is implemented in the module sources. |
+| CUDA kernel execution (`vectorAdd`) | 🟡 execution backend: physical ownership + firmware staging verified; the unbind/rebind freeze hazard is mitigated by the supervised D0 power-domain lock (3/3 green claim cycles), and the real FB size (8 GiB) and boot layout are verified live. The supervised live secure-verification run raised the protected region (WPR2 up) for the first time, then proved a secure-verification-only carve is not host-recoverable on this fused part, so the fail-safe held the device and an approved reboot restored it (distribution driver rebound, GPU healthy). That one-way stage is now retired: the only device-write path is a single full boot lifecycle (secure verification -> bootloader -> RISC-V start -> resource-manager initialization), whose code is implemented in the module sources and has now run live: the first real boot raised WPR2, passed Booter Load and went RISC-V active, and the module received the first real GSP-RM message (event 0x1002); init-done (0x1001) and a clean release are the next steps (see the 2026-10-01 section). A second live boot on 2026-10-01 proved the full boot sequence again (protected region up, bootloader halt, RISC-V active, first GSP-RM message) and reached the resource-manager's inline CPU-sequencer request; the host executor rejected the real request because of an over-strict internal size cap, which was found with a raw read of the message in host memory, fixed, and rebuilt. Cycles 2-3 then ran the real sequencer and received init-done with an RM init failure (`0x59`), which reproduces on a verified matching firmware image; the   server's own shutdown supplied the last handoff bit, so each failed cycle
+  completed a **clean release without a reboot**. Cycles 4-7 then captured the
+  resource-manager's own error journal and root-caused the failure: the boot
+  queue was missing the two pre-boot initialization messages the matching
+  driver queues before the kernel kick (a system-information message and a
+  packed registry table). That handshake is now implemented, and a real
+  registry profile with display disabled is sent; the error journal collapsed
+  from 29 unique/851 total records to 3 unique/4 total (the dominant assert
+  family is gone and so is the late display event), and the GPU timer is now
+  programmed before the kick. Initialization still ends in the same
+  un-journaled resource-manager error, now being chased through the recorded
+  assert call-sites; each of cycles 4-7 released the device cleanly with no
+  reboot. |
 | Graphics (3D), video | ❌ |
 | Faults, multi-version, Windows, migration, multi-tenancy, performance | ❌ |
 
@@ -76,9 +88,20 @@ chain succeeds.
   reboot**: the server's own shutdown sets the remaining secure-scratch
   handoff bit, so all four handoff bits are set and a single `rmmod` clears
   the protected region, rebinds the distribution driver and releases the
-power-domain locks. The next evidence is the **GSP-RM NOCAT journal** (the
-matching-image cycle streamed ~851 journal records), whose capture is
-implemented in the module sources and awaits a supervised diagnostic cycle.
+power-domain locks. The error-journal capture has since run on four
+supervised cycles (each one attempt, each released cleanly with no reboot):
+the journal was read, and the failure was root-caused to two pre-boot
+initialization messages the matching driver queues before the kernel kick (a
+system-information message and a packed registry table) - our boot queue was
+empty. That handshake is now implemented and a real registry profile with
+display disabled is sent; the journal collapsed from 29 unique/851 total
+records to 3 unique/4 total, the dominant assert family and the late display
+event are gone, and the GPU timer is programmed before the kick.
+Initialization still ends in the same un-journaled resource-manager error,
+now being chased through the recorded assert call-sites; the next leads are
+those call-sites, the remaining zeroed system-information fields, the
+video-memory workspace layout branch, and a build-matched log database for
+the fatal path.
 - **The full CUDA driver-API smoke test passes with correct data**: the client
   completes `cuCtxCreate -> cuMemAlloc -> cuMemcpyHtoD -> cuMemcpyDtoH ->
   cuMemFree -> cuCtxDestroy` and prints `ALL OK`, with the 64-byte payload