STATE-CURRENT: 20:12 check-back - first real GPFIFO work submitted to the physical engine; channel now allocates; engine did not execute the block

1 files changed, 33 insertions, 28 deletions

diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md
index 210c31e..f68fcc0 100644
--- a/STATE-CURRENT.md
+++ b/STATE-CURRENT.md
@@ -1,6 +1,6 @@
 # Open-IOV Current State
 
-> **Snapshot: 2026-10-01 19:12.** This is a dated public status page, not live
+> **Snapshot: 2026-10-01 20: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:
@@ -57,16 +57,17 @@ meant to execute on the physical GPU.
   with a zero result and serve the full static-config reply (GPU name, 8 GiB
   FB, internal handles, BAR PDE bases, engine caps), and graceful shutdown
   works through the unload RPC. Each of cycles 4-13 released the device
-  cleanly with no reboot. Since 2026-10-01 17:24 the next rung has both code
+  cleanly with no reboot.   Since 2026-10-01 17:24 the next rung has both code
   and live results: a host resource-manager client creates memory and
-  channel-group objects on the booted server (nine allocations succeed), then
-  allocates a virtual-address-space object under the server's device handle; it
-  is now blocked one step earlier, at programming that address space's
-  page-directory base (the server rejects the page-directory control), so channel
-  allocation is not yet reached. One unsafe channel variant hung the server
-  task, so the fail-safe held the device and an approved reboot restored it -
-  the variant is removed from the tree. No physical work has been submitted
-  yet. |
+  channel-group objects on the booted server, allocates and programs the
+  page-directory base of a virtual-address-space object, and **allocates a real
+  channel** on the live server. It has since filed the **first real submission
+  to the physical engine**: a copy work item was placed in the channel's GPFIFO
+  and the doorbell was rung, but the copy engine did not execute it within the
+  timeout, so no completion was observed - getting the physical channel to run
+  submitted work is the current wall. One unsafe channel variant hung the server
+  task earlier, so the fail-safe held the device and an approved reboot restored
+  it; the variant is removed from the tree. |
 | Graphics (3D), video | ❌ |
 | Faults, multi-version, Windows, migration, multi-tenancy, performance | ❌ |
 
@@ -78,24 +79,26 @@ chain succeeds.
 
 ## Right now (frontier)
 
-- **Submission-rung bring-up (2026-10-01 17:24-19:12): the first real
-  resource-manager objects on the live GSP-RM.** A host resource-manager
-  client now talks to the booted server: ten memory allocations (system-memory
-  page-table registrations) and a channel-group object are created under the
-  server's own internal handles, and a virtual-address-space object is now
-  allocated under the device handle too. The root-client allocation path is
-  parked after the server returned an invalid-client result, and the resource
-  manager rejects the control that programs the new address space's
-  page-directory base, so channel allocation is blocked one step earlier than
-  before; the next experiments are to supply the correct page-directory base
-  (or a valid memory descriptor) so a channel can be allocated. One channel
-  variant hung the server's resource-manager task; the fail-safe held the
+- **Submission-rung bring-up (2026-10-01 17:24-20:12): the first real work
+  submitted to the physical engine.** A host resource-manager client now talks
+  to the booted server and the channel-allocation wall has fallen: ten
+  system-memory page-table registrations and a channel-group object are created
+  under the server's own internal handles, a virtual-address-space object is
+  allocated under the device handle, its page-directory base is programmed (the
+  earlier rejection is fixed), and a real copy-engine channel is allocated. In
+  the latest cycle the client bound the channel, scheduled it, obtained a
+  work-submit token, placed a 30-word copy work item in the channel's GPFIFO and
+  **rang the doorbell** - the first real submission to the physical engine.
+  The copy engine did **not** execute the work within the timeout (no semaphore
+  release, the channel made no progress), so completion is not yet observed;
+  making the physical channel run submitted work is the new wall. The
+  root-client allocation path remains parked after an invalid-client result. One
+  channel variant hung the server's resource-manager task; the fail-safe held the
   device instead of handing it back in a wedged state, and an approved reboot
-  restored the distribution driver (~18:37). The unsafe variant has been
-  removed from the tree, and a decoded resource-manager log dump now makes
-  server-side failures readable. No work has been submitted to the physical
-  engine yet. Evidence: `backups/evidence-20261001-cycle14/` through
-  `...-cycle18/`.
+  restored the distribution driver (~18:37). The unsafe variant has been removed
+  from the tree, and a decoded resource-manager log dump makes server-side
+  failures readable. Evidence: `backups/evidence-20261001-cycle19/` through
+  `...-cycle21/`.
 - **Physical-backend milestone (2026-10-01 16:45): the host-owned GSP-RM
   completes initialization on the real TU104 and serves the static-config
   RPC.** Three supervised cycles, no reboot, clean release each time:
@@ -420,7 +423,9 @@ Work execution (host service vs client synchronization):
              launch; the queued compute pushes decode but are not executed
  [partial] GPU VA -> guest PA translation: page-table walk fixed and succeeding;
            server-owned page-table population still in progress
- [not yet] real work forwarded to the physical GPU (host-RM proxy or direct submission)
+ [partial] real work submitted to the physical GPU: a copy work item was placed
+           in a real channel's GPFIFO and the doorbell rung; the engine did not
+           yet execute it (no completion)
  [not yet] correct results (vectorAdd)
 ```