Yann Sionneau <[email protected]> wrote: > > It asserts for -1 because only the LWP lock should be held at that > > point. > Ok, but locking the LWP lock won't make ci_mtx_count be -1 because the > lock is a MUTEX_DEFAULT and not a MUTEX_SPIN.
MUTEX_DEFAULT can either mean a spin-lock or an adaptive lock, depending on the specified IPL value. Please see mutex(9) manpage for details. All LWP locks (i.e. the locks which can be associated with lwp_t::l_mutex) are spin-locks. > >> Do I miss a MUTEX_SPIN somewhere? which spin mutex is supposed to be > >> held before calling mi_switch()? (or at least before the KASSERTMSG > >> happens). > > That assert is generally for catching locking bugs. Perhaps you missed > > mutex_exit()/mutex_spin_exit() somewhere in your MD code? Get a > > backtrace and inspect the code? > > > Well, it's 0 because no spin lock is locked. So I don't think I missed a > mutex_spin_exit() ... I think I don't understand the situation at all > here :/ If the value is 0 at the point of assertion, then I would suggest to add some debug code to find out when it becomes zero. Perhaps your MD code does not initialise struct cpu_info or the relevant members to zero? -- Mindaugas
