diff options
| -rw-r--r-- | STATE-CURRENT.md | 50 |
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 |