Re: ci_mtx_count issue on NetBSD/Milkymist

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

Yann Sionneau <yann.sionneau%gmail.com@localhost> wrote:
> > It is a reference count on the IPL raised by spin-mutexes.  The IPL
> > should be lowered (straight to IPL_NONE) on a last reference.  Notice
> > that this is a negative counter - mutex_spin_enter() decrements, while
> > mutex_spin_exit() incremenets.  Not the other way round.
> >
> Why should curcpu()->ci_mtx_count be -1 during mi_switch()?
> Using watchpoint I discovered that I never access cpu0->ci_mtx_count.

It asserts for -1 because only the LWP lock should be held at that point.

> This, as you said, should be incremented/decremented upon 
> mutex_spin_enter or exit, but in my case mutex_spin_enter() is aliased 
> to mutex_vector_enter because I don't have any stubs and anyway I have 
> enabled LOCKDEBUG kernel option.

If you have __HAVE_SIMPLE_MUTEXES defined and __HAVE_{SPIN_}MUTEX_STUBS
undefined, then MD code does not need any extra handling.

> mutex_spin_enter() only touches curcpu()->ci_mtx_count when the mutex is 
> a MUTEX_SPIN, I put a breakpoint in mutex_init() and tested all "type" 
> argument: I never initialize any MUTEX_SPIN.
> It seems I only use MUTEX_DEFAULT or MUTEX_DRIVER.

You should generally use only MUTEX_DEFAULT, mutex_init(9) will determine
the type from IPL value.

> 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?

-- 
Mindaugas