STATE-CURRENT: root-cause the second freeze class (claim unbind) and its hazard gate

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