DF-2283 run1 (stock kernel #0 Jul 2 2026, guest root) -- reader blocked in "sgnull"
=========================================================================================================================
script: run2283.sh  (reader under nohup ./sg2283 block; external ps probes)

---PS1--- (t = +3s after entering the sleep)
   PID STAT   WCHAN    COMMAND
   872 S4     sgnull   ./sg2283 block

---PS2--- (t = +23s)
   PID STAT   WCHAN    COMMAND
   872 I4     sgnull   ./sg2283 block

---LOG--- (block.log)
DF2283: request pack_id=2002 queued; waiting 2s for sgdone()
DF2284: CONTROL read(pack_id=2002) returned immediately, result=0
DF2283: TEST read(pack_id=4242) entering tsleep(&hstat, PCATCH, "sgnull", 0) NOW (pid 872)
RUN_DONE
(reader deliberately left parked; fd held open)

VERDICT markers:
  * control read with matching pack_id returned at once (result=0)
  * unmatched-pack_id read parked in tsleep wchan "sgnull" for the full
    observation window (timo=0; rg over sys/ shows no wakeup(&hstat)
    anywhere in the tree -- the channel is a stack address unique to the
    sleeping invocation)

run2 (signal experiment) -- SIGTERM to the parked reader
--------------------------------------------------------
script: run2283b.sh
kill -TERM 872; sleep 3
---AFTER-TERM---
   PID STAT   WCHAN    COMMAND
   872 R4     -        ./sg2283 block

The PCATCH sleep is interrupted by the signal, but the reader does NOT
return to user mode: it transitioned to a kernel-bound runnable state
(R4) and spun; within ~2 minutes the guest became unresponsive (sshd
dead, serial silent, qemu alive) -- a kernel livelock triggered by the
signal-vs-sgnull interaction (sgread's `goto search' loop after the
interrupted tsleep, on a periph whose lock/refcount state is in flux).
This aggravates the finding: the "indefinite block" escalates to a
whole-system livelock when the sleeping reader is signaled.
(guest was reset with-src afterwards; see env.txt)