Re: lockdebug panic on boot

[David Young <dyoung%pobox.com@localhost>]

On Fri, Apr 23, 2010 at 10:50:53AM +0100, Mindaugas Rasiukevicius wrote:
> "Christoph Egger" <Christoph_Egger%gmx.de@localhost> wrote:
> > 
> > I got this lockdebug panic on boot:
> > 
> > Mutex error: lockdebug_barrier: spin lock held
> > 
> > lock address : 0xffffffff80c04c10 type     :               spin
> > initialized  : 0xffffffff805a75a9
> > shared holds :                  0 exclusive:                  1
> > shares wanted:                  0 exclusive:                  0
> > current cpu  :                  0 last held:                  0
> > current lwp  : 0xffffffff80ba9da0 last held: 0xffffffff80ba9da0
> > last locked  : 0xffffffff805a6aca unlocked : 0xffffffff805a6aa4
> > owner field  : 0x0000000000010600 wait/spin:                0/1
> > 
> > ...
> > 
> > 'last locked' points to sys/kern/subr_autoconf.c:1115
> > 
> 
> config_makeroom() is broken, as it performs kmem_free() with spin-lock
> held.

Really? kmem(9) does not say that kmem_free(9) will sleep, does it?

> Moreover, config_alldevs_lock() is still entering splhigh(), ??
> Hi dyoung@! :)

That was supposed to be fixed in rev 1.199 when I changed the mutex from
IPL_HIGH to IPL_VM.  Looks like I overlooked the splhigh()/splx() call.

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933