From 0212c8a985a2d2ada5ee44d910a2cb9760bf289e Mon Sep 17 00:00:00 2001 From: Arthur Hanson Rasmusson Date: Thu, 1 Oct 2026 00:02:00 -0400 Subject: STATE-CURRENT: cdt2 baseline re-verified; second freeze class mechanism and power-domain mitigation recorded --- STATE-CURRENT.md | 29 ++++++++++++++++++----------- 1 file changed, 18 insertions(+), 11 deletions(-) diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md index b5db841..1cd6620 100644 --- a/STATE-CURRENT.md +++ b/STATE-CURRENT.md @@ -43,6 +43,10 @@ chain succeeds. ## Right now (frontier) +- **Driver-API baseline re-verified on the current build**: the smoke test + passes end-to-end (`ALL OK`, payload 64/64) with real releases + (`faked=0`, `miss=0`, `stale=0`), confirming the recent pump/parser and + rewind changes did not regress the baseline. - **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 @@ -119,17 +123,20 @@ chain succeeds. - Host stability: the host hang class observed on 2026-09-28 (kernel stack overflow in a channel snapshot path) is fixed and frame-audited; repeated VM load/attach/teardown cycles run without panics or pstore records. A - second, distinct freeze class was root-caused on 2026-09-30: unbinding the - distribution driver (as the physical-GPU claim path does) lets the dGPU - board power-gate, and the re-bind intermittently leaves the GPU - unresponsive (`not ready ... after resume`) with the host hard-freezing - within about a minute (no crash record either time; journal stops, pstore - empty; both occurrences followed an unbind/rebind, and the full prior log - history has no other instance). The claim path therefore refuses to run - unless both `gsp_phys_gpu=1` and `gsp_phys_hazard_ack=1` are passed; - normal module/VM work does not touch the driver binding and is unaffected. - Ownership-changing bring-up must not continue until the execution backend - is redesigned to keep the distribution driver bound (host-RM proxy); see + second, distinct freeze class was root-caused on 2026-09-30: the dGPU + board's power rail is gated by an ACPI power resource behind its root + port, released through an embedded-controller command. Unbinding the + distribution driver (as the physical-GPU claim path does) lets the device + runtime-suspend, the rail is cut, and the re-bind intermittently fails to + power it back (`not ready ... after resume`), with the host hard-freezing + about a minute later (no crash record; journal stops, pstore empty; both + occurrences followed an unbind/rebind, and prior log history has no other + instance). The claim path refuses to run unless both `gsp_phys_gpu=1` and + `gsp_phys_hazard_ack=1` are passed, and it must not run again until the + designed power-domain lock (hold the GPU and its board functions plus the + root port in D0 across the handoff, aborting on any power-loss signature) + is implemented and verified under supervision; normal module/VM work does + not touch the driver binding and is unaffected. See [`docs/03-architecture/08-physical-gpu-integration.md`](docs/03-architecture/08-physical-gpu-integration.md). ## Initialization, work and teardown path -- cgit v1.2.3