diff options
| -rw-r--r-- | STATE-CURRENT.md | 27 |
1 files changed, 17 insertions, 10 deletions
diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md index cad25ce..a3605a0 100644 --- a/STATE-CURRENT.md +++ b/STATE-CURRENT.md @@ -82,7 +82,7 @@ chain succeeds. ## Right now (frontier) - **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 + wall is the shared-management GR object alloc (2026-10-02 ~17:35).** 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 @@ -96,15 +96,22 @@ chain succeeds. 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. + or the promote shape. Since then three more supervised cycles (modes 20, 21 + and 22, module `1c69c03b…`) closed out the client-promote shape space on the + default external VAS: every kernel-managed-channel variant - single MAIN, + VA-only, bare VA+size, `hVirtMemory`, and `GPU_INITIALIZE_CTX` followed by + `hVirtMemory` - returns the same soft `NV_ERR_INVALID_STATE` (0x40) with a + clean release each time; adding the initialize step does not move it. The + five-element engine-class table decode and the Ghidra headless helper + scripts are recorded in the handoff (Addendum 25); the V5 path's commit + assert `0x52a8b04` is a secondary failure after an earlier non-zero commit + status. Current wall: commit the GR engine context and make the engine + execute the submitted compute block. Next routes: name the soft-0x40 check + in the commit helper, root-cause the V5 assert's first failure, or rehost + the promote flow in risc-v-gsp-rm-debugger. All parameters remain default + off; the software path is unchanged with them off. The guest-runnable + victory client (`tools/cuda-ab/victory_mail.cu`, host-oracle green) is ready + for the first green guest execution. - **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 |