Re: lockdebug panic on boot

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

On Fri, Apr 23, 2010 at 10:20:33AM -0500, David Young wrote:
> 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?

Thanks for fixing the doco.  I will try to fix config_makeroom() this
weekend.
 
> > 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.

And this, too.

Dave

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