โฌข DragonFlyBSD Kernel Audit
DF-5533 / run.log
โ† back to finding โ†“ download raw
# baseline run (unpatched kernel) โ€” fire.log is EMPTY: no return, no WARNING
# T+3s after firing:
    -1 B3     dfhz     dfhz
  1028 D1     suspkp   sysctl
# 8s later โ€” still stuck:
   PID STAT   UCOMM
  1028 D1     sysctl
(fire.log end)
kern.dfstarv.report: started_ms=1791335035572 victim_ran=1 victim_ran_ms=1791335036112 churn_count=52 waiter_done=1 waiter_woke_ms=1791335036612 now_ms=1791335060232 starve_ms=500

# Reading:
# - PID 1028 (sysctl kern.dfcold.fire=1) sits in D-state (uninterruptible),
#   wait channel "suspkp" โ€” suspend_kproc()'s tsleep (kern_kthread.c:197),
#   which can only be released by the usb_process thread acknowledging
#   TDF_MP_STOPREQ. It never does: the suspend check in usb_process() is
#   #if 0'd out (usb_process.c:86-89) and kthread_suspend_check() does not
#   exist in DragonFly anyway (usb_process.c:60).
# - The dfhz usb_process thread is B3 (blocked): it was cv_signal'ed by the
#   drain but cannot re-acquire the bus lock the wedged drain thread still
#   holds while sleeping inside suspend_kproc (tsleep releases nothing).
# - usb_process.c:437's "WARNING: A USB process has been left suspended"
#   never prints โ€” it is after the never-returning call.
# - The rest of the system is alive (the report sysctl runs): the wedge is
#   the drain thread + the usb_process + everyone who later wants that bus
#   lock, exactly what a controller attach-failure during cold boot would
#   leave behind.