Re: panic: lockmgr: draining against myself
In message [EMAIL PROTECTED], ryan beasley writes: panic: lockmgr: draining against myself I've just checked in revision 1.426 of vfs_subr.c which may solve this, but I was not able to reproduce it myself. Could you or anybody else who has seen this panic try the above revision to see if it helps? Note that you will need HEAD rather than RELENG_5_0 to get this change. There is probably a better approach to solve the VOP_INACTIVE recursion problem than the one I used though - I think maybe having a vnode flag that remembers whether a VOP_INACTIVE call is necessary would be more general than the VI_DOINGINACT flag. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: lockmgr: draining against myself
On Thu, Apr 18, 2002 at 11:25:10AM +0900, Jun Kuriyama wrote: This is today's kernel. Should I test with -DDEBUG_LOCKS? I'm seeing this again panic: lockmgr: draining against myself syncing disks... panic: bwrite: buffer is not busy??? Uptime: 22m5s I was doing a buildworld to produce this. David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: lockmgr: draining against myself
I just got the same panic on my -current box from yesterday, also:
crash1# panic: lockmgr: draining against myself
cpuid = 0; lapic.id =
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
[EMAIL PROTECTED] 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 = 0100
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
Re: panic: lockmgr: draining against myself
just as a heads up, was just able to recreate it with a simple 'make
install' ... didn't need the -j16 to do it ...
On Sat, 7 Apr 2001, The Hermit Hacker wrote:
doing a 'make -j16 install' on kdebase from cvs, it eventually panic'd
with:
panic: lockmgr: draining against myself
cpuid = 1; lapic.id = 0100
Debugging("panic")
CPU1 stopping CPUs: 0x0001... stopped.
Stopped atDEbuger+0x46: pushl %ebx
trace shows:
Debugger
panic
lockmgr
vop_stdlock
ufs_vnoperate
vclean
vgonel
vrecycle
ufs_inactive
ufs_vnoperate
vput
handle_workitem_freeblocks
softdep_setup_freeblocks
ffs_truncate
ufs_inactive
ufs_vnoperate
vrele
vn_close
vn_closefile
fdrop
closef
close
syscall
syscall_with_err_pushed
Based on kernel upgraded/installed on April 6th ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: panic: lockmgr: draining against myself
problem appears to be fsck related ... fsck -p was only doing two out of 6
of my file systems .. manually ran fsck on each, and right now am doing a
buildworld for last nights upgrade and we'll see what happens ...
On Sat, 7 Apr 2001, The Hermit Hacker wrote:
just as a heads up, was just able to recreate it with a simple 'make
install' ... didn't need the -j16 to do it ...
On Sat, 7 Apr 2001, The Hermit Hacker wrote:
doing a 'make -j16 install' on kdebase from cvs, it eventually panic'd
with:
panic: lockmgr: draining against myself
cpuid = 1; lapic.id = 0100
Debugging("panic")
CPU1 stopping CPUs: 0x0001... stopped.
Stopped at DEbuger+0x46: pushl %ebx
trace shows:
Debugger
panic
lockmgr
vop_stdlock
ufs_vnoperate
vclean
vgonel
vrecycle
ufs_inactive
ufs_vnoperate
vput
handle_workitem_freeblocks
softdep_setup_freeblocks
ffs_truncate
ufs_inactive
ufs_vnoperate
vrele
vn_close
vn_closefile
fdrop
closef
close
syscall
syscall_with_err_pushed
Based on kernel upgraded/installed on April 6th ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
