Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

lockdebug panic on boot

0 views
Skip to first unread message

Christoph Egger

unread,
Apr 23, 2010, 4:51:11 AM4/23/10
to

Hi!

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

panic: LOCKDEBUG
fatal breakpoint trap in supervisor mode
trap type 1 code 0 rip ffffffff801fe4ad cs e030 rflags 246 cr2 0 cpl 8 rsp ffffffff80ec29e0
Stopped in pid 0.1 (system) at netbsd:breakpoint+0x5: leave
breakpoint() at netbsd:breakpoint+0x5
panic() at netbsd:panic+0x28f
lockdebug_more() at netbsd:lockdebug_more
mutex_enter() at netbsd:mutex_enter+0x279
vmem_xfree() at netbsd:vmem_xfree+0x34
kmem_free() at netbsd:kmem_free+0xd4
config_devalloc() at netbsd:config_devalloc+0x289
config_attach_loc() at netbsd:config_attach_loc+0x23
mp_pci_scan() at netbsd:mp_pci_scan+0xa5
hypervisor_attach() at netbsd:hypervisor_attach+0x170
config_attach_loc() at netbsd:config_attach_loc+0x16c
mainbus_attach() at netbsd:mainbus_attach+0xb8
config_attach_loc() at netbsd:config_attach_loc+0x16c
cpu_configure() at netbsd:cpu_configure+0x25
main() at netbsd:main+0x210
ds 0x29c0
es 0x1
fs 0x8
gs 0x4f0f
rdi 0x8
rsi 0xffffffff805b7749 printf+0xbc
rbp 0xffffffff80ec29e0
rbx 0xffffffff80ec29f0
rdx 0
rcx 0x1
rax 0x1
r8 0xffffffff80ec2900
r9 0
r10 0xffffffff80ec2900
r11 0x1
r12 0x104
r13 0xffffffff80914f0f copyright+0x2abcf
r14 0x8
r15 0x1
rip 0xffffffff801fe4ad breakpoint+0x5
cs 0xe030
rflags 0x246
rsp 0xffffffff80ec29e0
ss 0xe02b
netbsd:breakpoint+0x5: leave
db>

'last locked' points to sys/kern/subr_autoconf.c:1115

Christoph

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de

Mindaugas Rasiukevicius

unread,
Apr 23, 2010, 5:50:53 AM4/23/10
to
"Christoph Egger" <Christo...@gmx.de> 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. Moreover, config_alldevs_lock() is still entering splhigh(), ??
Hi dyoung@! :)

--
Mindaugas

Andrew Doran

unread,
Apr 23, 2010, 6:41:13 AM4/23/10
to
On Fri, Apr 23, 2010 at 10:50:53AM +0100, Mindaugas Rasiukevicius wrote:
> "Christoph Egger" <Christo...@gmx.de> 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. Moreover, config_alldevs_lock() is still entering splhigh(), ??
> Hi dyoung@! :)

I said it before but I don't see why there is any legitimate reason to
go scanning this stuff from a hard interrupt handler, particularly not
one at IPL_HIGH!

Mindaugas Rasiukevicius

unread,
Apr 23, 2010, 6:54:21 AM4/23/10
to
Andrew Doran <a...@NetBSD.org> wrote:
> > > ...
> > >
> > > 'last locked' points to sys/kern/subr_autoconf.c:1115
> > >
> >
> > config_makeroom() is broken, as it performs kmem_free() with spin-lock
> > held. Moreover, config_alldevs_lock() is still entering splhigh(), ??
> > Hi dyoung@! :)
>
> I said it before but I don't see why there is any legitimate reason to
> go scanning this stuff from a hard interrupt handler, particularly not
> one at IPL_HIGH!
>

Fully agree. And it generally needs more clean-up on locking.

--
Mindaugas

David Young

unread,
Apr 23, 2010, 11:20:33 AM4/23/10
to
On Fri, Apr 23, 2010 at 10:50:53AM +0100, Mindaugas Rasiukevicius wrote:
> "Christoph Egger" <Christo...@gmx.de> 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
dyo...@ojctech.com Urbana, IL * (217) 278-3933

David Young

unread,
Apr 23, 2010, 11:21:39 AM4/23/10
to
On Fri, Apr 23, 2010 at 11:54:21AM +0100, Mindaugas Rasiukevicius wrote:
> Fully agree. And it generally needs more clean-up on locking.

Fully agree. Now there is some semblance of synchronization. You're
welcome.

Dave

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

--

David Young

unread,
Apr 24, 2010, 12:26:42 AM4/24/10
to
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" <Christo...@gmx.de> 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
dyo...@ojctech.com Urbana, IL * (217) 278-3933

--

David Young

unread,
Apr 28, 2010, 6:05:38 PM4/28/10
to
On Fri, Apr 23, 2010 at 10:51:11AM +0200, Christoph Egger wrote:
> panic: LOCKDEBUG
> fatal breakpoint trap in supervisor mode
> trap type 1 code 0 rip ffffffff801fe4ad cs e030 rflags 246 cr2 0 cpl 8 rsp ffffffff80ec29e0
> Stopped in pid 0.1 (system) at netbsd:breakpoint+0x5: leave
> breakpoint() at netbsd:breakpoint+0x5
> panic() at netbsd:panic+0x28f
> lockdebug_more() at netbsd:lockdebug_more
> mutex_enter() at netbsd:mutex_enter+0x279
> vmem_xfree() at netbsd:vmem_xfree+0x34
> kmem_free() at netbsd:kmem_free+0xd4
> config_devalloc() at netbsd:config_devalloc+0x289

Try the attached patch.

subr_autoconf.locking
0 new messages