Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 18 Apr 2002 00:04:43 -0400 (EDT)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Jun Kuriyama <kuriyama@imgsrc.co.jp>
Cc:        Current <FreeBSD-current@FreeBSD.org>
Subject:   Re: panic: lockmgr: draining against myself
Message-ID:  <Pine.NEB.3.96L.1020418000309.64976d-100000@fledge.watson.org>
In-Reply-To: <7mbsch4ubd.wl@waterblue.imgsrc.co.jp>

next in thread | previous in thread | raw e-mail | index | archive | help
I just got the same panic on my -current box from yesterday, also:

crash1# panic: lockmgr: draining against myself
cpuid = 0; lapic.id = 00000000
Debugger("panic")
Stopped at      Debugger+0x41:  xorl    %eax,%eax
db> trace
Debugger(c03dd41a) at Debugger+0x41
panic(c03dadc0,c9f35c30,c8f06418,0,0) at panic+0xd8
lockmgr(c9f35cd8,10007,c9f35c98,c8f06418,c8f16994) at lockmgr+0x3ef
vop_stdlock(c8f169c8,c8f169d8,c028d1b0,c8f169c8,c9f35c30) at
vop_stdlock+0x1f
ufs_vnoperate(c8f169c8) at ufs_vnoperate+0x15
vclean(c9f35c30,8,c8f06418,c9f35c30,c8f16a08) at vclean+0x64
vgonel(c9f35c30,c8f06418,c9f35c30,c9cc3000,c8f16a40) at vgonel+0x37
vrecycle(c9f35c30,0,c8f06418,c9f35c30,c8f06418) at vrecycle+0x4b
ufs_inactive(c8f16a60,c8f16a70,c028cd5e,c8f16a60,ca015600) at
ufs_inactive+0x185
ufs_vnoperate(c8f16a60) at ufs_vnoperate+0x15
vput(c9f35c30) at vput+0xea
handle_workitem_freeblocks(ca015600,0,c9cc3000,c9cc3000,c8f16c60) at
handle_workitem_freeblocks+0x193
softdep_setup_freeblocks(c9cc3000,0,0,c9f35c30,c9cc3000) at
softdep_setup_freeblocks+0x32f
ffs_truncate(c9f35c30,0,0,0,0) at ffs_truncate+0x264
ufs_inactive(c8f16c60,c8f16c70,c028cd5e,c8f16c60,0) at ufs_inactive+0xa9
ufs_vnoperate(c8f16c60) at ufs_vnoperate+0x15
vput(c9f35c30,c045bf3c,c9a47400,c982d600,0) at vput+0xea
handle_workitem_remove(c9a47400,0,c8f06418,0,0) at
handle_workitem_remove+0x172
process_worklist_item(0,0) at process_worklist_item+0x113
softdep_process_worklist(0) at softdep_process_worklist+0x106
sched_sync(0,c8f16d48,c8f06418,c028c0fc,0) at sched_sync+0x194
fork_exit(c028c0fc,0,c8f16d48) at fork_exit+0x88
fork_trampoline() at fork_trampoline+0x37


Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org      NAI Labs, Safeport Network Services

On Thu, 18 Apr 2002, Jun Kuriyama wrote:

> 
> This is today's kernel.  Should I test with -DDEBUG_LOCKS?
> 
> -----
> panic: lockmgr: draining against myself
> cpuid = 1; lapic.id = 01000000
> Debugger("panic")
> Stopped at      Debugger+0x41:  xorl    %eax,%eax
> db> trace
> Debugger(c029d1ba) at Debugger+0x41
> panic(c029ae60,e908e780,e325cd50,0,0) at panic+0xd8
> lockmgr(e908e828,10007,e908e7e8,e325cd50,e326099c) at lockmgr+0x3ef
> vop_stdlock(e32609d0,e32609e0,c01c51f6,e32609d0,e908e780) at vop_stdlock+0x1f
> ufs_vnoperate(e32609d0) at ufs_vnoperate+0x15
> vclean(e908e780,8,e325cd50,e908e780,e3260a10) at vclean+0x62
> vgonel(e908e780,e325cd50,e908e780,e909b300,e3260a48) at vgonel+0x37
> vrecycle(e908e780,0,e325cd50,e908e780,e325cd50) at vrecycle+0x4b
> ufs_inactive(e3260a68,e3260a78,c01c4da4,e3260a68,e8482580) at ufs_inactive+0x160
> ufs_vnoperate(e3260a68) at ufs_vnoperate+0x15
> vput(e908e780) at vput+0xe4
> handle_workitem_freeblocks(e8482580,0,e909b300,e909b300,e325cd50) at handle_workitem_freeblocks+0x193
> softdep_setup_freeblocks(e909b300,0,0,e908e780,e909b300) at softdep_setup_freeblocks+0x31f
> ffs_truncate(e908e780,0,0,0,0) at ffs_truncate+0x240
> ufs_inactive(e3260c60,e3260c70,c01c4da4,e3260c60,0) at ufs_inactive+0x91
> ufs_vnoperate(e3260c60) at ufs_vnoperate+0x15
> vput(e908e780,c02e3bdc,e7f65f40,e79d8000,0) at vput+0xe4
> handle_workitem_remove(e7f65f40,0,e325cd50,0,0) at handle_workitem_remove+0x15f
> process_worklist_item(0,0) at process_worklist_item+0x113
> softdep_process_worklist(0) at softdep_process_worklist+0x106
> sched_sync(0,e3260d48,e325cd50,c01c414c,0) at sched_sync+0x190
> fork_exit(c01c414c,0,e3260d48) at fork_exit+0x88
> fork_trampoline() at fork_trampoline+0x37
> -----
> (kgdb) where
> #0  doadump () at ../../../kern/kern_shutdown.c:213
> #1  0xc0188e4c in boot (howto=260) at ../../../kern/kern_shutdown.c:346
> #2  0xc018905d in panic (fmt=0xc028c74a "from debugger")
>     at ../../../kern/kern_shutdown.c:490
> #3  0xc012f591 in db_panic (addr=-1071235275, have_addr=0, count=-1, 
>     modif=0xe3260804 "") at ../../../ddb/db_command.c:449
> #4  0xc012f52f in db_command (last_cmdp=0xc02c8fc4, cmd_table=0xc02c8de4, 
>     aux_cmd_tablep=0xc02c31c8, aux_cmd_tablep_end=0xc02c31cc)
>     at ../../../ddb/db_command.c:345
> #5  0xc012f5fb in db_command_loop () at ../../../ddb/db_command.c:471
> #6  0xc013198f in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:72
> #7  0xc0263c76 in kdb_trap (type=3, code=0, regs=0xe3260900)
>     at ../../../i386/i386/db_interface.c:161
> #8  0xc0277c5c in trap (frame={tf_fs = -385351656, tf_es = -484048880, 
>       tf_ds = -1072168944, tf_edi = 7, tf_esi = 256, tf_ebp = -484046520, 
>       tf_isp = -484046548, tf_ebx = -1071010208, tf_edx = -484061872, 
>       tf_ecx = 1, tf_eax = 18, tf_trapno = 3, tf_err = 0, 
>       tf_eip = -1071235275, tf_cs = 8, tf_eflags = 582, tf_esp = -1070878077, 
>       tf_ss = -1071001158}) at ../../../i386/i386/trap.c:585
> #9  0xc0263f35 in Debugger (msg=0xc029d1ba "panic") at machine/cpufunc.h:68
> #10 0xc0189048 in panic (fmt=0xc029ae60 "lockmgr: draining against myself")
>     at ../../../kern/kern_shutdown.c:477
> #11 0xc017ef37 in lockmgr (lkp=0xe908e828, flags=65543, interlkp=0xe908e7e8, 
>     td=0xe325cd50) at ../../../kern/kern_lock.c:427
> #12 0xc01c0bef in vop_stdlock (ap=0xe32609d0)
>     at ../../../kern/vfs_default.c:282
> #13 0xc02396bd in ufs_vnoperate (ap=0xe32609d0)
>     at ../../../ufs/ufs/ufs_vnops.c:2660
> ...
> (kgdb) up 11
> #11 0xc017ef37 in lockmgr (lkp=0xe908e828, flags=65543, interlkp=0xe908e7e8, 
>     td=0xe325cd50) at ../../../kern/kern_lock.c:427
> 427                             panic("lockmgr: draining against myself");
> (kgdb) list
> 422                      * never drain if we do. Unfortunately, we have no way to
> 423                      * check for holding a shared lock, but at least we can
> 424                      * check for an exclusive one.
> 425                      */
> 426                     if (lkp->lk_lockholder == pid)
> 427                             panic("lockmgr: draining against myself");
> 428     
> 429                     error = acquiredrain(lkp, extflags);
> 430                     if (error)
> 431                             break;
> (kgdb) up
> #12 0xc01c0bef in vop_stdlock (ap=0xe32609d0)
>     at ../../../kern/vfs_default.c:282
> 282             return (lockmgr(&vp->v_lock, ap->a_flags, &vp->v_interlock, ap->a_td));
> (kgdb) list
> 277             } */ *ap;
> 278     {               
> 279             struct vnode *vp = ap->a_vp;
> 280     
> 281     #ifndef DEBUG_LOCKS
> 282             return (lockmgr(&vp->v_lock, ap->a_flags, &vp->v_interlock, ap->a_td));
> 283     #else
> 284             return (debuglockmgr(&vp->v_lock, ap->a_flags, &vp->v_interlock,
> 285                 ap->a_td, "vop_stdlock", vp->filename, vp->line));
> 286     #endif
> 
> 
> -- 
> Jun Kuriyama <kuriyama@imgsrc.co.jp> // IMG SRC, Inc.
>              <kuriyama@FreeBSD.org> // FreeBSD Project
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message
> 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020418000309.64976d-100000>