tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: understanding LOCKDEBUG



On Wed, Sep 30, 2009 at 11:56:03AM +0900, Masao Uebayashi wrote:
> > Does some LWP hold the lock or not?  How do I know?
> 
> If I read the code correctly, the only way to know the owner thread from a
> given (waiting thread, syncobj) is to call (*l->l_syncobj->sobj_owner)().
> 
>       lwp_t *
>       sobj_owner(lwp_t *l, void *sobj)
>       {
> 
>               return (*l->l_syncobj->sobj_owner)(sobj);
>       }
> 
> and in ddb, doing
> 
>       call sobj_owner(<lwp_address>, <lock_address>)
> 
> should return the address of the owner.

I gave that a try, thanks.  Returns NULL for alldevs_mtx.  I am seeing
no indication that alldevs_mtx is held when the cpu_switchto panics.

Below is a backtrace from one of the panics. tty/com has been involved
each time.  The arguments to cpu_switchto are very strange (the second
seems to point to a mutex instead of to an LWP), but it may be DDB
lossage.

Dave

NetBSD/i386 (skyking.ojctech.com) (tty00)

login: Sep 30 12:30:55 skyking getty[452]: /dev/xencons: Device not configured
root
Password:
Sep 30 12:31:00 skyking login: ROOT LOGIN (root) ON tty00
Last login: Wed panic: cpu_switchto: switching above IPL_SCHED (8)
fatal breakpoint trap in supervisor mode
trap type 1 code 0 eip c0227494 cs 8 eflags 292 cr2 bbbb07a4 ilevel 8
Stopped in pid 443.1 (login) at netbsd:breakpoint+0x4:  popl    %ebp
db{1}> bt
breakpoint(c09e8d35,d101f960,d101f954,c05d7c18,d101f94c,c052373c,d101f9b0,d101f9
60,0,d10fcaa0) at netbsd:breakpoint+0x4
cpu_Debugger(d101f94c,c052373c,d101f9b0,d101f960,0,d10fcaa0,d101f9bc,c010038e,c0
100391,8) at netbsd:cpu_Debugger+0xb
panic(c0100391,8,0,d10fcaa0,0,c0486d7c,d10fcaa0,cb1dad20,0,0) at netbsd:panic+0x
1d8
cpu_switchto(d10fcaa0,cb1cb2c0,d101f9ec,c0473abf,c0ae4852,145d61d,1,c0ae4850,d10
fcaa0,cb1cb2c0) at netbsd:cpu_switchto+0x1e
sleepq_block(0,1,c06169de,0,6,c0ae4850,d005ac7c,1,d0050001,d005ac9c) at netbsd:s
leepq_block+0xdc
cv_timedwait_sig(d005ac9c,c0ae4850,0,d005ac04,d005ac04,0,0,1d,d005ac04,d) at net
bsd:cv_timedwait_sig+0x10f
ttysleep(d005ac04,d005ac9c,1,0,d101fad3,3ff,0,cbcf915c,c09f98c0,d10fcaa0) at net
bsd:ttysleep+0x3e
ttwrite(d005ac04,d101fc7c,10,0,d0c58d00,800,d101fb4c,c05c926b,800,0) at netbsd:t
twrite+0x75
comwrite(800,0,d101fc7c,10,1,c05c9246,800,0,d101fb4c,d10fcaa0) at netbsd:comwrit
e+0x6b
cdev_write(800,0,d101fc7c,10,d0c58d00,0,d101fb8c,c06a64cb,d0c58da0,1) at netbsd:
cdev_write+0x3b
spec_write(d101fbe4,6,d101fbec,c06b31f2,c2553e4c,2c5,c094e080,d0c58d00,c094db80,
d0c58d00) at netbsd:spec_write+0x99
--db_more--
VOP_WRITE(d0c58d00,d101fc7c,10,cb1caf00,d0c58d00,20002,c05ead7e,0,ffffffff,fffff
fff) at netbsd:VOP_WRITE+0x6d
vn_write(d12aa940,d12aa940,d101fc7c,cb1caf00,1,d10fcaa0,0,cb1cd2c0,c05eadaf,d0f8
53bc) at netbsd:vn_write+0x98
dofilewrite(1,d12aa940,bfbfc864,2c5,d12aa940,1,d101fd28,d101fd00,d10fcaa0,0) at 
n
etbsd:dofilewrite+0x63
sys_write(d10fcaa0,d101fd00,d101fd28,804c4e0,d109d9f4,d0f853bc,4,1,bfbfc864,2c5)
 at netbsd:sys_write+0x60
syscall(d101fd48,bb9100b3,ab,bfbf001f,bbbb001f,bb913220,0,bfbfe868,804b990,1) at
 netbsd:syscall+0xc4
db{1}> whatis cb1cb2c0
0xcb1cb2c0 is 0xcb1cb000+704 in POOL 'kvakernel' (allocated)
0xcb1cb2c0 is 0xcb1cb2c0+0 in POOL 'mutex' (allocated)
0xcb1cb2c0 is 0xcb1ac000+127680 from VMMAP 0xc0a9ca40
db{1}> whatis d10fcaa0
0xd10fcaa0 is 0xd10fc000+2720 in POOL 'kvakernel' (allocated)
0xd10fcaa0 is 0xd10fcaa0+0 in POOL 'lwppl' (allocated)
0xd10fcaa0 is 0xd10b0000+314016 from VMMAP 0xc0a9ca40
db{1}> show lock alldevs_mtx
lock address : 0x00000000c0a9972c type     :               spin
initialized  : 0x00000000c05c7155
shared holds :                  0 exclusive:                  0
shares wanted:                  0 exclusive:                  0
current cpu  :                  1 last held:                  1
current lwp  : 0x00000000d10fcaa0 last held: 000000000000000000
last locked  : 0x00000000c05c59d8 unlocked : 0x00000000c05c5a03
owner field  : 0x0000000000000800 wait/spin:                0/1
db{1}> 

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


Home | Main Index | Thread Index | Old Index