[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: lockdebug panic on boot
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
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.
David Young OJC Technologies
dyoung%ojctech.com@localhost Urbana, IL * (217) 278-3933
Main Index |
Thread Index |