diff options
| -rw-r--r-- | STATE-CURRENT.md | 18 |
1 files changed, 12 insertions, 6 deletions
diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md index 018a8d5..634088c 100644 --- a/STATE-CURRENT.md +++ b/STATE-CURRENT.md @@ -116,12 +116,18 @@ 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, separate freeze class is under watch: twice the host has become - unresponsive roughly a minute after the distribution driver was unbound and - rebound on the physical GPU (once with a VM attached, once without; no crash - record either time, both needed a hard reboot). The device reset/rebind path - is the common factor; ownership-changing bring-up cycles are being run one - per boot with a watchdog and persistent logging. + 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 + the handoff. ## Initialization, work and teardown path |