Make spinlocks panic-friendly.
authorMatthew Dillon <dillon@dragonflybsd.org>
Thu, 18 May 2006 17:53:45 +0000 (17:53 +0000)
committerMatthew Dillon <dillon@dragonflybsd.org>
Thu, 18 May 2006 17:53:45 +0000 (17:53 +0000)
commitb02926de2885706f5bc7add92a256b25e9b56a72
tree59760a313c48cc2e1f70584f9c9179db8bb0961b
parent9d2657296aa7bc5e2ef7c9a564ed9375f6e03771
Make spinlocks panic-friendly.

* Add code to detect indefinite waits.  If a spinlock cannot be obtained
  after one second a warning is issued to the console.  After 10 seconds
  a DDB backtrace is output to the console.

* Count the number of contested events, short and long, via two sysctls:
  debug.spinlocks_contested1 and debug.spinlocks.contested2.

* Add a sysctl to test the indefinite wait code: sysctl debug.spin_lock_test=1.
  (only if INVARIANTS is turned on).

* If an indefinite wait occurs while the system is paniced, the spinlock
  code will hand the spinlock over to the requester after 1 second.  This
  should allow panics to proceed even if they occur at a bad point in the
  code.

* lwkt_switch normally panics if spinlocks are held by the current thread
  (and it tries to switch).  Do not panic if the system is already in a
  panic.  This should allow the system to restabilize itself due to the
  indefinite wait panic handling code, well enough to generate a dump
  or enter into DDB, anyhow.
sys/kern/kern_spinlock.c
sys/kern/lwkt_thread.c