Re: ci_mtx_count issue on NetBSD/Milkymist

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Yann Sionneau <yann.sionneau%gmail.com@localhost> 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