The SCHEDULER_STOPPED() hack breaks locking generally, and
mtx_trylock_*() especially. When mtx_trylock_*() returns nonzero,
naive code version here trusts it to have worked. But when
SCHEDULER_STOPPED() is true, mtx_trylock_*() returns 1 without doing
anything. Then mtx_unlock_*() crashes especially badly attempting to
unlock iff the error is detected, since mutex unlocking functions don't
check SCHEDULER_STOPPED().
syscons already didn't trust mtx_trylock_spin(), but it was missing the
logic to turn on sp->kdb_locked when turning off sp->mtx_locked during
panics. It also used panicstr instead of SCHEDULER_LOCKED because I
thought that panicstr was more fragile. They only differ for a window
of lines in panic(), and in broken cases where stop_cpus_hard() in panic()
didn't work.
b9cedb46e2