# DF-2270 hang test, iteration 1 (harness artifact -- kept for honesty)
#
# First hang-test attempt: the harness kthread called chgetelemstatus()
# directly WITHOUT taking the periph lock first, so the first
# cam_periph_unlock() (scsi_ch.c:1088) hit lockmgr with no lock held
# and panicked.  This panic is a HARNESS CALLING-CONVENTION BUG, not
# evidence of DF-2270 (the same panic would fire with an in-range
# chet).  Fixed by making the kthread cam_periph_lock() before the
# call, exactly as chioctl() does (scsi_ch.c:697).  Iteration 2
# (hang_serial.log / hang_pagedaemon.log) is the valid evidence.
#
# Captured from the serial console (boot.log at the time):
DFH2270HANG: thread calling REAL chgetelemstatus() with type=8 count=65535 (desclen=0xffff -> ~4GiB M_INTWAIT kmalloc)
panic: lockmgr: LK_RELEASE: no lock held
cpuid = 5
Trace beginning at frame 0xfffff80117eab9d0
lockmgr_release() at lockmgr_release+0x11a 0xffffffff80647b3a 
lockmgr_release() at lockmgr_release+0x11a 0xffffffff80647b3a 
chgetelemstatus() at chgetelemstatus+0x6b 0xffffffff80a8133b 
dfh_thr_2270hang() at dfh_thr_2270hang+0x61 0xffffffff80a81841 
Debugger("panic")