panic: lockmgr: locking against myself (current of 09-20th)
NFS Server:
FreeBSD titan.klemm.apsfilter.org 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sun Sep 21
13:16:17 CEST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/TITAN i386
NFS Client:
FreeBSD aklemm.klemm.apsfilter.org 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Mon Sep 22
21:29:32 CEST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/AKLEMM i386
Was checking out ports under /use. CVS repository resides on
NFS server, mounted via automounter.
My first checkout attempts failed with GENERIC kernel:
ep 22 20:40:25 aklemm kernel: Out of mbuf address space!
Sep 22 20:40:25 aklemm kernel: Consider increasing NMBCLUSTERS
Sep 22 20:40:25 aklemm kernel: All mbufs or mbuf clusters exhausted, please see
tuning(7).
So I rebuild kernel with BMBCLUSTERS raised to 1024
Kernel profile in attachement.
With new kernel I get panics in different subsystems whenever
I checkout ports, in the middle I think
BTW Checking out src tree went fine ...
The panic here is:
(kgdb) symbol-file kernel.debug
Reading symbols from kernel.debug...done.
(kgdb) core-file /var/crash/vmcore.0
No kernel exec file specified
(kgdb) exec-file kernel
(kgdb) core-file /var/crash/vmcore.0
panic: lockmgr: locking against myself
panic messages:
---
panic: lockmgr: locking against myself
panic: from debugger
Uptime: 10m26s
Dumping 191 MB
16 32 48 64 80 96 112 128 144 160 176
---
Reading symbols from
/usr/src/sys/i386/compile/AKLEMM/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done.
Loaded symbols for
/usr/src/sys/i386/compile/AKLEMM/modules/usr/src/sys/modules/acpi/acpi.ko.debug
Reading symbols from
/usr/src/sys/i386/compile/AKLEMM/modules/usr/src/sys/modules/msdosfs/msdosfs.ko.debug...done.
Loaded symbols for
/usr/src/sys/i386/compile/AKLEMM/modules/usr/src/sys/modules/msdosfs/msdosfs.ko.debug
Reading symbols from
/usr/src/sys/i386/compile/AKLEMM/modules/usr/src/sys/modules/ipfw/ipfw.ko.debug...done.
Loaded symbols for
/usr/src/sys/i386/compile/AKLEMM/modules/usr/src/sys/modules/ipfw/ipfw.ko.debug
Reading symbols from
/usr/src/sys/i386/compile/AKLEMM/modules/usr/src/sys/modules/nfsclient/nfsclient.ko.debug...done.
Loaded symbols for
/usr/src/sys/i386/compile/AKLEMM/modules/usr/src/sys/modules/nfsclient/nfsclient.ko.debug
Reading symbols from
/usr/src/sys/i386/compile/AKLEMM/modules/usr/src/sys/modules/nfsserver/nfsserver.ko.debug...done.
Loaded symbols for
/usr/src/sys/i386/compile/AKLEMM/modules/usr/src/sys/modules/nfsserver/nfsserver.ko.debug
Reading symbols from
/usr/src/sys/i386/compile/AKLEMM/modules/usr/src/sys/modules/usb/usb.ko.debug...done.
Loaded symbols for
/usr/src/sys/i386/compile/AKLEMM/modules/usr/src/sys/modules/usb/usb.ko.debug
Reading symbols from /boot/kernel/logo_saver.ko...done.
Loaded symbols for /boot/kernel/logo_saver.ko
Reading symbols from
/usr/src/sys/i386/compile/AKLEMM/modules/usr/src/sys/modules/linux/linux.ko.debug...done.
Loaded symbols for
/usr/src/sys/i386/compile/AKLEMM/modules/usr/src/sys/modules/linux/linux.ko.debug
#0 doadump () at ../../../kern/kern_shutdown.c:240
240 dumping++;
(kgdb) where
#0 doadump () at ../../../kern/kern_shutdown.c:240
#1 0xc01babc7 in boot (howto=260) at ../../../kern/kern_shutdown.c:372
#2 0xc01bafa8 in panic () at ../../../kern/kern_shutdown.c:550
#3 0xc01231e2 in db_panic () at ../../../ddb/db_command.c:450
#4 0xc0123142 in db_command (last_cmdp=0xc03438c0, cmd_table=0x0,
aux_cmd_tablep=0xc031c550, aux_cmd_tablep_end=0xc031c554)
at ../../../ddb/db_command.c:346
#5 0xc0123285 in db_command_loop () at ../../../ddb/db_command.c:472
#6 0xc01262a5 in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:73
#7 0xc02c82cc in kdb_trap (type=3, code=0, regs=0xd323722c)
at ../../../i386/i386/db_interface.c:171
#8 0xc02d9c7a in trap (frame=
{tf_fs = -752680936, tf_es = -1070858224, tf_ds = 16, tf_edi = 1, tf_esi =
-1070560517, tf_ebp = -752651656, tf_isp = -752651688, tf_ebx = 0, tf_edx = 0, tf_ecx
= 32, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1070824060, tf_cs = 8,
tf_eflags = 646, tf_esp = -1070500194, tf_ss = -1070555829})
at ../../../i386/i386/trap.c:578
#9 0xc02c9cb8 in calltrap () at {standard input}:102
#10 0xc01baee5 in panic (fmt=0xc0308afb lockmgr: locking against myself)
at ../../../kern/kern_shutdown.c:534
#11 0xc01acffe in lockmgr (lkp=0xc54ecc64, flags=34144290, interlkp=0x220,
td=0xc180cbe0) at ../../../kern/kern_lock.c:439
#12 0xc0208d6d in getblk (vp=0xc18a0c8c, blkno=4140064, size=16384, slpflag=0,
slptimeo=0, flags=0) at ../../../sys/buf.h:313
#13 0xc0204742 in breadn (vp=0xc18a0c8c, blkno=0, size=0, rablkno=0x0,
rabsize=0x0, cnt=0, cred=0x0, bpp=0x0) at ../../../kern/vfs_bio.c:696
#14 0xc02046ec in bread (vp=0x0, blkno=0, size=0, cred=0x0, bpp=0x0)
at ../../../kern/vfs_bio.c:678
#15 0xc025b66c in ffs_alloccg (ip=0xc216b230, cg=11, bpref=1034976, size=16384)
at ../../../ufs/ffs/ffs_alloc.c:1287
#16 0xc025b097 in ffs_hashalloc (ip=0xc216b230, cg=11, pref=0, size=16384
Re: panic: lockmgr: locking against myself (current of 09-20th)
On Monday 22 September 2003 04:28 pm, Andreas Klemm wrote: The panic here is: (kgdb) symbol-file kernel.debug Reading symbols from kernel.debug...done. (kgdb) core-file /var/crash/vmcore.0 No kernel exec file specified (kgdb) exec-file kernel (kgdb) core-file /var/crash/vmcore.0 panic: lockmgr: locking against myself panic messages: --- panic: lockmgr: locking against myself panic: from debugger Uptime: 10m26s Dumping 191 MB 16 32 48 64 80 96 112 128 144 160 176 I had a similar panic on 5.0-R. Do you happen to have any snapshots on any of the filesystems to which you might be writing at the time of the panic? I don't know how I determined it, but I found that the panic was the result of a snapshot on my /var filesystem. Removing the snapshot solved the panic. -- Jonathan Fosburgh AIX/SAN Administrator UT MD Anderson Cancer Center Houston, TX Home Page: http://www.fosburgh.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: lockmgr: locking against myself (current of 09-20th)
On Mon, Sep 22, 2003 at 06:48:14PM -0500, Jonathan E Fosburgh wrote: On Monday 22 September 2003 04:28 pm, Andreas Klemm wrote: The panic here is: (kgdb) symbol-file kernel.debug Reading symbols from kernel.debug...done. (kgdb) core-file /var/crash/vmcore.0 No kernel exec file specified (kgdb) exec-file kernel (kgdb) core-file /var/crash/vmcore.0 panic: lockmgr: locking against myself panic messages: --- panic: lockmgr: locking against myself panic: from debugger Uptime: 10m26s Dumping 191 MB 16 32 48 64 80 96 112 128 144 160 176 I had a similar panic on 5.0-R. Do you happen to have any snapshots on any of the filesystems to which you might be writing at the time of the panic? I don't know how I determined it, but I found that the panic was the result of a snapshot on my /var filesystem. Removing the snapshot solved the panic. No, fresh installation on Laptop. Andreas /// -- Andreas Klemm - Powered by FreeBSD 5.1-CURRENT Need a magic printfilter today ? - http://www.apsfilter.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: lockmgr: locking against myself
As always, whenever I crash before background fsck is finished...
[EMAIL PROTECTED]:/opt/home/dcs$ gdb -k /usr/obj/usr/src/sys/DCS/kernel.debug
/var/crash/vmcore.8
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: lockmgr: locking against myself
panic messages:
---
panic: lockmgr: locking against myself
syncing disks, buffers remaining... 882 882 880 880 880 880 880 880 880
880 880 822 823 822 822 822 822 822 unknown: device timeout
unknown: DMA timeout
824 822 827 822 822 822 822 822 822 822 822 822 822 822 822 822 822 822
822 822 822 822 822
giving up on 710 buffers
Uptime: 4m41s
Dumping 255 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
---
Reading symbols from /boot/kernel/snd_cmi.ko...done.
Loaded symbols for /boot/kernel/snd_cmi.ko
Reading symbols from /boot/kernel/snd_pcm.ko...done.
Loaded symbols for /boot/kernel/snd_pcm.ko
Reading symbols from
/usr/obj/usr/src/sys/DCS/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/DCS/modules/usr/src/sys/modules/acpi/acpi.ko.debug
Reading symbols from /boot/kernel/green_saver.ko...done.
Loaded symbols for /boot/kernel/green_saver.ko
Reading symbols from
/usr/obj/usr/src/sys/DCS/modules/usr/src/sys/modules/linux/linux.ko.debug...done.
Loaded symbols for
/usr/obj/usr/src/sys/DCS/modules/usr/src/sys/modules/linux/linux.ko.debug
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
239 dumping++;
(kgdb) bt full
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239
No locals.
#1 0xc01ec443 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:371
No locals.
#2 0xc01ec743 in panic () at /usr/src/sys/kern/kern_shutdown.c:542
td = (struct thread *) 0xc29fc980
bootopt = 256
newpanic = 1
buf = lockmgr: locking against myself, '\0' repeats 224 times
#3 0xc01d0c22 in lockmgr (lkp=0xc77cf97c, flags=34144290,
interlkp=0x220, td=0xc29fc980)
at /usr/src/sys/kern/kern_lock.c:447
error = 0
thr = (struct thread *) 0xc29fc980
extflags = 33554464
lockflags = 34144290
#4 0xc0245f10 in BUF_TIMELOCK (bp=0xc77cf97c, locktype=34144290,
interlock=0x0, wmesg=0x0, catch=0, timo=0)
at buf.h:319
ret = 0
#5 0xc0241528 in flushbuflist (blist=0xc77cf8b0, flags=4,
vp=0xc2ef86d8, slpflag=0, slptimeo=0, errorp=0x0)
at /usr/src/sys/kern/vfs_subr.c:1226
bp = (struct buf *) 0xc77cf97c
nbp = (struct buf *) 0x2090022
found = 1
error = 0
#6 0xc02411d9 in vinvalbuf (vp=0xc2ef86d8, flags=4, cred=0x0, td=0x0,
slpflag=0, slptimeo=0)
at /usr/src/sys/kern/vfs_subr.c:1140
blist = (struct buf *) 0x0
error = 0
object = (struct vm_object *) 0xc038d420
#7 0xc027ef0a in ffs_truncate (vp=0xc2ef86d8, length=0, flags=2048,
cred=0x0, td=0xc29fc980)
at /usr/src/sys/ufs/ffs/ffs_inode.c:273
ovp = (struct vnode *) 0xc2ef86d8
oip = (struct inode *) 0xc2506510
bn = -4595188392983498048
lbn = -4595796903951530429
---Type return to continue, or q return to quit---
lastblock = -3284296585705422848
lastiblock = {7825250020, 4294852608, 4294983680}
indir_lbn = {-3284295173694292736, 0, -3976995127051695744}
oldblks = {-4422543730025529563, -4597468310878027639,
-4603193868120500600, 7560230888,
1545117794085, -407461993958781, 3530282736,
-4603163193464072504, 3265263592, 591635055342,
24892416000, 1425736, 1427344, 3262735212, -941709473941328}
newblks = {-4595796560354146749, -4595830507774119232,
-4595689636071734605, -4602925638822930956,
-3284296118623889348, -4595830507775840915, -4597472472701337599,
-4422543733250063938,
-3284296015545203986, -4597468307654643792, 16109450424,
-3284295792166188672, -4597468310878027194,
-4597197328506420774, -4595797247547378808}
count = -3284296431086600192
blocksreleased = 0
datablocks = 96
fs = (struct fs *) 0xc279d000
bp = (struct buf *) 0xc0210643
needextclean = 0
softdepslowdown = 0
extblocks = 0
offset = -1024489768
size = 0
level = 0
nblocks = -764684924
i = -1024489768
error = 0
allerror = 0
osize = 3224950592
#8 0xc02825c0 in ffs_snapshot (mp=0xc25ecc00, snapfile=---Can't read
userspace from dump, or kernel process---
) at /usr/src/sys/ufs/ffs/ffs_snapshot.c:654
numblks = 262138
blkno = -4595798621938448829
blkp = (ufs2_daddr_t *) 0xc0387108
snapblklist = (ufs2_daddr_t *) 0xc03862a8
error = 5
Re: nfs panic: lockmgr: locking against myself
Jeff Roberson writes: On Mon, 17 Mar 2003, Andrew Gallatin wrote: I'm seeing the following panic under heavy NFS client usage on an SMP w/kernel sources from Weds. evening. Has this been fixed? Thanks, Drew I believe that is fixed in nfs_vnops.c 1.200. Yep, it seems to be fixed now. Thanks! Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
nfs panic: lockmgr: locking against myself
I'm seeing the following panic under heavy NFS client usage on an SMP w/kernel sources from Weds. evening. Has this been fixed? Thanks, Drew panic: lockmgr: locking against myself cpuid = 0; lapic.id = Debugger(panic) Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0 db t Debugger(c0355e8c,0,c0354b5c,d8e2793c,1) at Debugger+0x55 panic(c0354b5c,0,c0354b22,ef,c41d6400) at panic+0x11f lockmgr(ce6abce4,2090022,c470136c,c41d6400,26b) at lockmgr+0x491 BUF_TIMELOCK(ce6abc18,10022,c470136c,c035d2bf,0) at BUF_TIMELOCK+0x80 nfs_flush(c470136c,c443e480,1,c41d6400,1) at nfs_flush+0x607 nfs_fsync(d8e27a9c,0,c035a68f,45a,c1df8858) at nfs_fsync+0x31 vinvalbuf(c470136c,1,c443e480,c41d6400,0) at vinvalbuf+0xe4 nfs_vinvalbuf(c470136c,1,c443e480,c41d6400,1) at nfs_vinvalbuf+0x191 nfs_setattr(d8e27b60,20002,c41d6400,0,0) at nfs_setattr+0x1f5 setutimes(c41d6400,c470136c,d8e27ca8,2,0) at setutimes+0x1c4 kern_utimes(c41d6400,bfbff8e8,0,bfbfece0,0) at kern_utimes+0x9c utimes(c41d6400,d8e27d10,c03667a3,404,2) at utimes+0x31 syscall(2f,2f,2f,bfbff8e8,4) at syscall+0x24e Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (138, FreeBSD ELF32, utimes), eip = 0x8049e8f, esp = 0xbfbfecbc, ebp = 0xbfbfed08 --- db To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: nfs panic: lockmgr: locking against myself
Andrew Gallatin wrote: I'm seeing the following panic under heavy NFS client usage on an SMP w/kernel sources from Weds. evening. Has this been fixed? If I'm not mistaken, this is the problem Jeff fixed in revision 1.134 of vfs_cluster.c. Cheers, Maxime To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: nfs panic: lockmgr: locking against myself
On Mon, 17 Mar 2003, Andrew Gallatin wrote: I'm seeing the following panic under heavy NFS client usage on an SMP w/kernel sources from Weds. evening. Has this been fixed? Thanks, Drew I believe that is fixed in nfs_vnops.c 1.200. panic: lockmgr: locking against myself cpuid = 0; lapic.id = Debugger(panic) Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0 db t Debugger(c0355e8c,0,c0354b5c,d8e2793c,1) at Debugger+0x55 panic(c0354b5c,0,c0354b22,ef,c41d6400) at panic+0x11f lockmgr(ce6abce4,2090022,c470136c,c41d6400,26b) at lockmgr+0x491 BUF_TIMELOCK(ce6abc18,10022,c470136c,c035d2bf,0) at BUF_TIMELOCK+0x80 nfs_flush(c470136c,c443e480,1,c41d6400,1) at nfs_flush+0x607 nfs_fsync(d8e27a9c,0,c035a68f,45a,c1df8858) at nfs_fsync+0x31 vinvalbuf(c470136c,1,c443e480,c41d6400,0) at vinvalbuf+0xe4 nfs_vinvalbuf(c470136c,1,c443e480,c41d6400,1) at nfs_vinvalbuf+0x191 nfs_setattr(d8e27b60,20002,c41d6400,0,0) at nfs_setattr+0x1f5 setutimes(c41d6400,c470136c,d8e27ca8,2,0) at setutimes+0x1c4 kern_utimes(c41d6400,bfbff8e8,0,bfbfece0,0) at kern_utimes+0x9c utimes(c41d6400,d8e27d10,c03667a3,404,2) at utimes+0x31 syscall(2f,2f,2f,bfbff8e8,4) at syscall+0x24e Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (138, FreeBSD ELF32, utimes), eip = 0x8049e8f, esp = 0xbfbfecbc, ebp = 0xbfbfed08 --- db To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: nfs panic: lockmgr: locking against myself
Maxime Henrion writes: Andrew Gallatin wrote: I'm seeing the following panic under heavy NFS client usage on an SMP w/kernel sources from Weds. evening. Has this been fixed? If I'm not mistaken, this is the problem Jeff fixed in revision 1.134 of vfs_cluster.c. Great! Thanks! Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: lockmgr: locking against myself
flag@newluxor$ uname -a FreeBSD newluxor.skynet.org 5.0-RC FreeBSD 5.0-RC #6: Sun Dec 8 13:45:45 CET 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NEWLUXOR i386 flag@newluxor$ i get a panic everytime i launch tin to read the newsgroup: panic: lockmgr: locking against myself syncing disks, buffers remaining... panic: bdwrite: buffer is not busy . . . any idea? if u want, i can recompile the kernel with backtrace support and give u more info... bye -- Paolo Italian FreeBSD User Group: http://www.gufi.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: lockmgr: locking against myself
On Sun, Dec 08, 2002 at 02:05:41PM +0100, Paolo Pisati wrote:
flag@newluxor$ uname -a
FreeBSD newluxor.skynet.org 5.0-RC FreeBSD 5.0-RC #6: Sun Dec 8 13:45:45 CET 2002
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/NEWLUXOR i386
flag@newluxor$
i get a panic everytime i launch tin to read the newsgroup:
panic: lockmgr: locking against myself
syncing disks, buffers remaining... panic: bdwrite: buffer is not busy
and here is the dump:
Script started on Sun Dec 8 15:22:34 2002
bash-2.05b# gdb -l k /usr/obj/usr/src/sys/NEWLUXOR/kernel.debug vmcore.0
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: bdwrite: buffer is not busy
panic messages:
---
panic: lockmgr: locking against myself
syncing disks, buffers remaining... panic: bdwrite: buffer is not busy
Uptime: 1m1s
Dumping 191 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:232
232 dumping++;
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:232
#1 0xc0225e8c in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:364
#2 0xc02260b7 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#3 0xc0263ee8 in bdwrite (bp=0xc5babff8) at /usr/src/sys/kern/vfs_bio.c:950
#4 0xc02df9c8 in ffs_update (vp=0xc2001ce4, waitfor=0)
at /usr/src/sys/ufs/ffs/ffs_inode.c:125
#5 0xc02f1b95 in ffs_fsync (ap=0xd3a9e888)
at /usr/src/sys/ufs/ffs/ffs_vnops.c:315
#6 0xc02f0e1c in ffs_sync (mp=0xc1f27800, waitfor=2, cred=0xc0d3ae80,
td=0xc03c5ae0) at vnode_if.h:612
#7 0xc0276146 in sync (td=0xc03c5ae0, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:138
#8 0xc0225ad9 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:273
#9 0xc02260b7 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#10 0xc021a647 in lockmgr (lkp=0xc0d539fc, flags=2, interlkp=0x0,
td=0xc1faa1c0) at /usr/src/sys/kern/kern_lock.c:441
#11 0xc030487a in _vm_map_lock_read (map=0xc0d539c0, file=0x0, line=0)
at /usr/src/sys/vm/vm_map.c:386
#12 0xc03072e0 in vm_map_lookup (var_map=0xd3a9ea24, vaddr=0,
fault_typea=2 '\002', out_entry=0xd3a9ea28, object=0x0, pindex=0x0,
out_prot=0x0, wired=0xd3a9ea00) at /usr/src/sys/vm/vm_map.c:2684
#13 0xc0301275 in vm_fault (map=0xc0d539c0, vaddr=0, fault_type=2 '\002',
fault_flags=8) at /usr/src/sys/vm/vm_fault.c:214
---Type return to continue, or q return to quit---
#14 0xc034409c in trap_pfault (frame=0xd3a9eae8, usermode=0, eva=62)
at /usr/src/sys/i386/i386/trap.c:734
#15 0xc0343d16 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi = 13, tf_ebp =
-743838936, tf_isp = -743838956, tf_ebx = -1037074680, tf_edx = 0, tf_ecx = 1, tf_eax
= 4096, tf_trapno = 12, tf_err = 2, tf_eip = -1070557399, tf_cs = 8, tf_eflags =
66054, tf_esp = -743838844, tf_ss = -1070564930})
at /usr/src/sys/i386/i386/trap.c:445
#16 0xc0335958 in calltrap () at {standard input}:98
#17 0xc03079be in vm_uiomove (mapa=0xc0d539c0, srcobject=0x0, cp=53248,
cnta=4096, uaddra=135434240, npages=0x0) at /usr/src/sys/vm/vm_map.c:3030
#18 0xc022aa4b in userspaceco (
cp=0xcb527000 1 y\r\nsaar.org.handshake.aktuell 1 1
y\r\nsaar.org.handshake.diskussion 1 1 y\r\nsaar.org.handshake.gastinfo 1 1
y\r\nsaar.org.handshake.hilfe 1 1 y\r\nsaar.org.handshake.offizielles 1 1
y\r\nsaar.org.ip.general...,
cnt=4096, uio=0x0, obj=0x0, disposable=0)
at /usr/src/sys/kern/kern_subr.c:266
#19 0xc022aaf6 in uiomoveco (
cp=0xcb527000 1 y\r\nsaar.org.handshake.aktuell 1 1
y\r\nsaar.org.handshake.diskussion 1 1 y\r\nsaar.org.handshake.gastinfo 1 1
y\r\nsaar.org.handshake.hilfe 1 1 y\r\nsaar.org.handshake.offizielles 1 1
y\r\nsaar.org.ip.general...,
n=4096, uio=0xd3a9ec88, obj=0x0, disposable=0)
at /usr/src/sys/kern/kern_subr.c:334
---Type return to continue, or q return to quit---
#20 0xc025b913 in soreceive (so=0xc2302900, psa=0x0, uio=0xd3a9ec88, mp0=0x0,
controlp=0x0, flagsp=0x0) at /usr/src/sys/kern/uipc_socket.c:993
#21 0xc024c48f in soo_read (fp=0x0, uio=0xd3a9ec88, active_cred=0xc22f9d80,
flags=0, td=0xc1faa1c0) at /usr/src/sys/kern/sys_socket.c:81
#22 0xc02466a4 in dofileread (td=0xc1faa1c0, fp=0xc1fe91a4, fd=3,
buf=0x8129000, nbyte=0, offset=0, flags=0) at file.h:203
#23 0xc024659d in read (td=0xc1faa1c0, uap=0xd3a9ed14)
at /usr/src/sys/kern/sys_generic.c:107
#24 0xc034469c in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 499, tf_esi = 674022528, tf_ebp =
-1077938616, tf_isp = -743838348, tf_ebx = 673944348, tf_edx = -63356, tf_ecx = 0
Re: panic: lockmgr: locking against myself
While local package initilization I get a panic. World and kernel from today. This I found in messages: Sep 30 15:49:55 leeloo kernel: panic: lockmgr: locking against myself This problem is gone with today's kernel. Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: lockmgr: locking against myself
Hi! While local package initilization I get a panic. World and kernel from today. This I found in messages: Sep 30 15:49:55 leeloo kernel: panic: lockmgr: locking against myself Sep 30 15:49:55 leeloo kernel: Sep 30 15:49:55 leeloo kernel: syncing disks... panic: bremfree: bp 0xd381a080 not locked Sep 30 15:49:55 leeloo kernel: Uptime: 26s Sep 30 15:49:55 leeloo kernel: pfs_vncache_unload(): 4 entries remaining Sep 30 15:49:55 leeloo kernel: Dumping 1535 MB Sep 30 15:49:55 leeloo kernel: ata0: resetting devices .. Sep 30 15:49:55 leeloo kernel: panic: bremfree: bp 0xd3886870 not locked Sep 30 15:49:55 leeloo kernel: Uptime: 26s Sep 30 15:49:55 leeloo kernel: pfs_vncache_unload(): 4 entries remaining Sep 30 15:49:55 leeloo kernel: panic: witness_destroy: lock (sleep mutex) pseudofs_vncache is not initialized The hand-written tr: panic: lockmgr: locking against myself lockmgr vm_map_lookup vm_pfault trap_pfault(18,10,10,0,2e) call trap Please let me know if (and how) I could provide more info. Marc msg43608/pgp0.pgp Description: PGP signature
Re: nfs_inactive() bug? - panic: lockmgr: locking against myself
On 11 Sep, Ian Dowse wrote: In message [EMAIL PROTECTED], Don Lewis writes: A potentially better solution just occurred to me. It looks like it would be better if vrele() waited to decrement v_usecount until *after* the call to VOP_INACTIVE() (and after the call to VI_LOCK()). If that were done, nfs_inactive() wouldn't need to muck with v_usecount at all. I've looked at this before; I think some filesystems (ufs anyway) depend on v_usecount being 0 when VOP_INACTIVE() is called. Yup, though it would easy to tweak ufs_inactive() to expect the v_usecount to be one greater. A bigger problem is the call to vrecycle() in ufs_inactive(). The patch I have had lying around for quite a while is below. It adds a vnode flag to avoid recursion into the last-reference handling code in vrele/vput, which is the real problem. It also guarantees that a vnode will not be recycled during VOP_INACTIVE(), so the nfs code no longer needs to hold an extra reference in the first place. The flag manipulation code got a bit messy after Jeff's vnode flag splitting work, so the patch could probably be improved. If the need for nfs_inactive() to manipulate the reference count is eliminated, that should be sufficient to eliminate the vrele/vput recursion problem as well. Whatever way this is done, we should try to avoid adding more hacks to the nfs_inactive() code anyway. Tweaking nfs_inactive() has the advantage of being the least intrusive fix for this problem, but it isn't architecturally clean. I'd also argue that decrementing the vnode reference count to zero, but holding on to the reference for an extended period of time while doing I/O on the vnode is also a kludge. It also causes problems that require kludgey fixes, like the reference count manipulation in nfs_inactive(). For the most part the VI_INACTIVE flag is just another way of indicating that we are holding a reference to the vnode, so both the flag and the reference count need to be checked to see if the vnode is in use. The advantage of adding this flag versus just bumping the reference count is that the flag allows us to avoid the bugs in the current implementation while not requiring changes to code that expects the reference count to be zero in code called from VOP_INACTIVE(). Here are the three proposed fixes along with their advantages and disadvantages: Inline the v_usecount decrement code in nfs_inactive() + Least intrusive fix for the recursion bug - Adds a kludge to a kludge Call VOP_INACTIVE() before decrementing the reference count and tweak the foo_inactive() methods to expect the reference count to be one instead of zero + Eliminates the kludge from nfs_inactive() + We aren't lying about holding a reference, so hopefully less potential for bugs - It is not obvious to how to adapt ufs_inactive() Add VI_INACTIVE flag to prevent the vnode from being recycled + Eliminates the kludge from nfs_inactive() + Doesn't require changes to the other filesystems - Code complexity - Programmer needs to know when to look at VI_INACTIVE and when looking at just the reference count is ok After looking at ufs_inactive(), I'd like to add a fourth proposal that would involve splitting VOP_INACTIVE() into two separate methods. The first method would be called before the reference count is decremented and would do any I/O. The second method would be called after the reference count is decremented and could only be used for freeing resources, manipulating flags, putting it on the free list with vrecycle(), etc. + Eliminates the kludge from nfs_inactive() + We don't lie about holding a reference while doing I/O - More extensive code changes - Bikeshed arguments about what to call the two methods To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: nfs_inactive() bug? - panic: lockmgr: locking against myself
In message [EMAIL PROTECTED], Don Lewis writes: After looking at ufs_inactive(), I'd like to add a fourth proposal And I've just remembered a fifth :-) I think the old BSD code had both an `open' count and a reference count. The open count is a count of the real users of the vnode (it is what ufs_inactive really wants to compare against 0), and the reference count is just for places that you don't want the vnode to be recycled or destroyed. This was probably lost when the encumbered BSD sources were rewritten. At the time I was looking at it last, I remember thinking that the open count would allow vrele/vput to keep the reference count at 1 during the VOP_INACTIVE() call, which is what you were proposing. It would also allow us to fix the problem of many places not matching each VOP_OPEN() with a VOP_CLOSE(). I suspect we could clean up a lot of related problems if the open count was brought back. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: nfs_inactive() bug? - panic: lockmgr: locking against myself
Ian Dowse wrote: And I've just remembered a fifth :-) I think the old BSD code had both an `open' count and a reference count. The open count is a count of the real users of the vnode (it is what ufs_inactive really wants to compare against 0), and the reference count is just for places that you don't want the vnode to be recycled or destroyed. This was probably lost when the encumbered BSD sources were rewritten. No, this went away with the vnode locking changes; it was in the 4.4 code, for sure. I think references are the correct thing here, and SunOS seems to agree, since that's how they implement, too. 8-). At the time I was looking at it last, I remember thinking that the open count would allow vrele/vput to keep the reference count at 1 during the VOP_INACTIVE() call, which is what you were proposing. It would also allow us to fix the problem of many places not matching each VOP_OPEN() with a VOP_CLOSE(). I suspect we could clean up a lot of related problems if the open count was brought back. Yes. It was murdered for good reason. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: nfs_inactive() bug? - panic: lockmgr: locking against myself
In message [EMAIL PROTECTED], Terry Lambert writes: Ian Dowse wrote: And I've just remembered a fifth :-) I think the old BSD code had both an `open' count and a reference count. The open count is a count of the real users of the vnode (it is what ufs_inactive really wants to compare against 0), and the reference count is just for places that you don't want the vnode to be recycled or destroyed. This was probably lost when the encumbered BSD sources were rewritten. No, this went away with the vnode locking changes; it was in the 4.4 code, for sure. I think references are the correct thing here, and SunOS seems to agree, since that's how they implement, too. 8-). I seem to have mis-remembered the details anyway :-) It doesn't look as if there ever was ever the `open' count that I mentioned above. Maybe I was just thinking that it would be a good way to solve the issues of matching VOP_CLOSEs with VOP_OPENs, since there are many cases in the kernel that do not guarantee to do a VOP_CLOSE for each VOP_OPEN that was performed. Handling the dropping of a last reference is always tricky to get right when complex operations can be performed from the reference dropping function (especially where that includes adding and then removing references multiple times). It's even harder to do it in a way that continues to catch missing or extra references caused by bugs in the functions called when the reference count hits zero. For example, if you hold the reference count at 1 while calling the cleanup function, it allows that function to safely add and drop references, but if that cleanup function has a bug that drops one too many references then you end up recursing instead of detecting it as a negative reference count. I've found in some other code that it works reasonably well to leave the reference count at zero, but set a flag to stop further 1-0 transitions from retriggering the cleanup. Obviously other approaches will work too. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: nfs_inactive() bug? - panic: lockmgr: locking against myself
On 13 Sep, Ian Dowse wrote: For example, if you hold the reference count at 1 while calling the cleanup function, it allows that function to safely add and drop references, but if that cleanup function has a bug that drops one too many references then you end up recursing instead of detecting it as a negative reference count. I've found in some other code that it works reasonably well to leave the reference count at zero, but set a flag to stop further 1-0 transitions from retriggering the cleanup. Obviously other approaches will work too. The cleanup function shouldn't be mucking with the reference count, which means that the present implementation of nfs_inactive() is broken, but I think there is already general agreement on that point. The only possible exception would be to increase the reference count to pass a reference to another thread, but that would be a silly thing for a cleanup function to do, since it would no longer be cleaning up. We could add a flag that would cause an immediate panic if the cleanup function fiddled with the reference count as an aid to tracking down broken code ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
nfs_inactive() bug? - panic: lockmgr: locking against myself
I've gotten a couple lockmgr: locking against myself panics today and
it seems to be somewhat reproduceable. I had the serial console hooked
up for the last one, so I was able to get a stack trace:
panic: lockmgr: locking against myself
Debugger(panic)
Stopped at Debugger+0x45: xchgl %ebx,in_Debugger.0
db tr
Debugger(c0449abc) at Debugger+0x45
panic(c0447760,215,0,c6cd7de0,10002) at panic+0x7c
lockmgr(c6cd7ea8,10002,c6cd7de0,c6381f00,c6cd7de0) at lockmgr+0x412
vop_sharedlock(e4b90b58,c047c440,c6cd7de0,1010002,c6381f00) at vop_sharedlock+0x
6e
vn_lock(c6cd7de0,10002,c6381f00) at vn_lock+0xb4
vrele(c6cd7de0,c6cd7de0,0,c681cb00,c6381f00,1) at vrele+0x8d
nfs_inactive(e4b90bdc,c047c3c0,c6cd7de0,c6381f00,c6381f00) at nfs_inactive+0xbd
VOP_INACTIVE(c6cd7de0,c6381f00) at VOP_INACTIVE+0xa0
vrele(c6cd7de0,c6834474,c6834474,e4b90c38,c02eed4a) at vrele+0x9b
vn_close(c6cd7de0,2,c681cb00,c6381f00,e4b90c70) at vn_close+0x37
vn_closefile(c6834474,c6381f00) at vn_closefile+0x1e
fdrop_locked(c6834474,c6381f00,c04fe8ac,0,c0446020) at fdrop_locked+0x102
fdrop(c6834474,c6381f00,c028a1ec,c6381f00,c6377c8c) at fdrop+0x24
closef(c6834474,c6381f00,c6834474,c6c0d3f8,c6381f00) at closef+0x77
close(c6381f00,e4b90d14,1,b9,202) at close+0x107
syscall(2f,2f,2f,82124cc,23) at syscall+0x243
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (6, FreeBSD ELF32, close), eip = 0x4862ff3b, esp = 0xbfbff2dc, ebp =
0xbfbff358 ---
db show lockedvnods
Locked vnodes
0xc6cd7de0: type VREG, usecount 0, writecount 0, refcount 0, flags (VV_OBJBUF)
tag VT_NFS, fileid 112174 fsid 0x100ff02
It looks like the call to vrele() from vn_close() is executing the
following code:
if (vp-v_usecount == 1) {
vp-v_usecount--;
/*
* We must call VOP_INACTIVE with the node locked.
* If we are doing a vput, the node is already locked,
* but, in the case of vrele, we must explicitly lock
* the vnode before calling VOP_INACTIVE.
*/
if (vn_lock(vp, LK_EXCLUSIVE | LK_INTERLOCK, td) == 0)
VOP_INACTIVE(vp, td);
VI_LOCK(vp);
if (VSHOULDFREE(vp))
vfree(vp);
else
vlruvp(vp);
VI_UNLOCK(vp);
It has decremented v_usecount to 0, grabbed an exclusive lock on the
vnode, and has called VOP_INACTIVE().
It looks like nfs_inactive() is executing the following code:
if (sp) {
/*
* We need a reference to keep the vnode from being
* recycled by getnewvnode while we do the I/O
* associated with discarding the buffers unless we
* are being forcibly unmounted in which case we already
* have our own reference.
*/
if (ap-a_vp-v_usecount 0)
(void) nfs_vinvalbuf(ap-a_vp, 0, sp-s_cred, td, 1);
else if (vget(ap-a_vp, 0, td))
panic(nfs_inactive: lost vnode);
else {
(void) nfs_vinvalbuf(ap-a_vp, 0, sp-s_cred, td, 1);
vrele(ap-a_vp);
}
Because v_usecount was 0, nfs_inactive() calls vget(), which increments
v_usecount to 1, has called nfs_vinvalbuf(), and finally calls vrele()
again.
Because v_usecount is 1, vrele() is re-executing the same code and blows
up when it tries to grab the lock again. If that didn't cause a panic,
VOP_INACTIVE() and nfs_inactive() would be called recursively, which
would probably be a bad thing ...
I suspect that nfs_inactive() needs to avoid calling vrele() here and
should just decrement the v_usecount with the appropriate locking.
Something like:
VI_LOCK(ap-a_vp);
ap-a_vp-v_usecount--;
VI_UNLOCK(ap-a_vp);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: nfs_inactive() bug? - panic: lockmgr: locking against myself
On 10 Sep, Don Lewis wrote:
It looks like the call to vrele() from vn_close() is executing the
following code:
if (vp-v_usecount == 1) {
vp-v_usecount--;
/*
* We must call VOP_INACTIVE with the node locked.
* If we are doing a vput, the node is already locked,
* but, in the case of vrele, we must explicitly lock
* the vnode before calling VOP_INACTIVE.
*/
if (vn_lock(vp, LK_EXCLUSIVE | LK_INTERLOCK, td) == 0)
VOP_INACTIVE(vp, td);
VI_LOCK(vp);
if (VSHOULDFREE(vp))
vfree(vp);
else
vlruvp(vp);
VI_UNLOCK(vp);
It has decremented v_usecount to 0, grabbed an exclusive lock on the
vnode, and has called VOP_INACTIVE().
It looks like nfs_inactive() is executing the following code:
if (sp) {
/*
* We need a reference to keep the vnode from being
* recycled by getnewvnode while we do the I/O
* associated with discarding the buffers unless we
* are being forcibly unmounted in which case we already
* have our own reference.
*/
if (ap-a_vp-v_usecount 0)
(void) nfs_vinvalbuf(ap-a_vp, 0, sp-s_cred, td, 1);
else if (vget(ap-a_vp, 0, td))
panic(nfs_inactive: lost vnode);
else {
(void) nfs_vinvalbuf(ap-a_vp, 0, sp-s_cred, td, 1);
vrele(ap-a_vp);
}
A potentially better solution just occurred to me. It looks like it
would be better if vrele() waited to decrement v_usecount until *after*
the call to VOP_INACTIVE() (and after the call to VI_LOCK()). If that
were done, nfs_inactive() wouldn't need to muck with v_usecount at all.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: nfs_inactive() bug? - panic: lockmgr: locking against myself
I remember seeing this panic many months back. I had fixed this in our
Freebsd source base.
Here is the scenario:
vrele() {
if (vp-v_usecount == 1) {
vp-usecount--;
if (VSHOULDFREE(vp))
vfree(vp);
vn_lock(vp, LK_EXCLUSIVE | LK_INTERLOCK, p);
(A)
VOP_INACTIVE() { /* translates to nfs_inactive() */
sp = np-n_sillyrename;
if (sp) {
if (ap-a_vp-v_usecount 0) {
...
} else {
vget(ap-a_vp, 0, p);
nfs_vinvalbuf(ap-a_vp, 0, ...);
vrele(ap-a_vp);
(B)
}
...
}
}
}
}
vrele() calls nfs_inactive() since the vp-v_usecount == 0. Before
calling nfs_inactive, it locks the vnode at (A) (since VOP_INACTIVE()
expects the vnode to be locked and VOP_INACTIVE() releases the lock at
the end).
In nfs_inactive() a check is made for to see if the file was
renamed/deleted while it was still in use. In this case it was, and so
np-n_sillyrename is valid. To make sure that the vnode does not get
reused while doing the I/O associated with discarding the buffers, the
use_count is bumped up using vget(). Then nfs_vinvalbuf() is called to
flush and invalidate all dirty buffers. After that vrele() is done on
the vnode at (B). vrele() again comes to (A) and tries to lock the
vnode, which was already locked before by the same process in the 1st
pass. The kernel panics with locking against myself.
The vrele() that is done at (B) causes the cycle to be repeated. vrele()
calls nfs_inactive() which calls vrele() and so forth. In
nfs_inactive(), we know that the function calling it will free the
vnode. So we need not call vfree(). We also know that we should not lock
the vnode, again, and call VOP_INACTIVE(). So the fix is to inline the
part of vrele() that just decrements the usecount.
The following would be the fix. This is 4.3 source base.
//depot/dev/freebsd-brick/src/sys/nfs/nfs_node.c#3 (text)
225c225,244
vrele(ap-a_vp);
---
/*
* Inline part of vrele() since VOP_INACTIVE
* has already been called.
*/
simple_lock(ap-a_vp-v_interlock);
if (--ap-a_vp-v_usecount = 0) {
#ifdef DIAGNOSTIC
if (ap-a_vp-v_usecount 0 ||
ap-a_vp-v_writecount != 0) {
vprint(nfs_inactive: bad ref
count,
ap-a_vp);
panic(nfs_inactive: ref cnt);
}
#endif
/*
* Since this is nfs_inactive(), vfree()
* would be called from the caller.
*/
}
simple_unlock(ap-a_vp-v_interlock);
Deepankar
Don Lewis wrote:
I've gotten a couple lockmgr: locking against myself panics today and
it seems to be somewhat reproduceable. I had the serial console hooked
up for the last one, so I was able to get a stack trace:
panic: lockmgr: locking against myself
Debugger(panic)
Stopped at Debugger+0x45: xchgl %ebx,in_Debugger.0
db tr
Debugger(c0449abc) at Debugger+0x45
panic(c0447760,215,0,c6cd7de0,10002) at panic+0x7c
lockmgr(c6cd7ea8,10002,c6cd7de0,c6381f00,c6cd7de0) at lockmgr+0x412
vop_sharedlock(e4b90b58,c047c440,c6cd7de0,1010002,c6381f00) at vop_sharedlock+0x
6e
vn_lock(c6cd7de0,10002,c6381f00) at vn_lock+0xb4
vrele(c6cd7de0,c6cd7de0,0,c681cb00,c6381f00,1) at vrele+0x8d
nfs_inactive(e4b90bdc,c047c3c0,c6cd7de0,c6381f00,c6381f00) at nfs_inactive+0xbd
VOP_INACTIVE(c6cd7de0,c6381f00) at VOP_INACTIVE+0xa0
vrele(c6cd7de0,c6834474,c6834474,e4b90c38,c02eed4a) at vrele+0x9b
vn_close(c6cd7de0,2,c681cb00,c6381f00,e4b90c70) at vn_close+0x37
vn_closefile(c6834474,c6381f00) at vn_closefile+0x1e
fdrop_locked(c6834474,c6381f00,c04fe8ac,0,c0446020) at fdrop_locked+0x102
fdrop(c6834474,c6381f00,c028a1ec,c6381f00,c6377c8c) at fdrop+0x24
closef(c6834474,c6381f00,c6834474,c6c0d3f8,c6381f00) at closef+0x77
close(c6381f00,e4b90d14,1,b9,202) at close+0x107
syscall(2f,2f,2f,82124cc,23) at syscall+0x243
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (6, FreeBSD ELF32, close), eip = 0x4862ff3b, esp = 0xbfbff2dc, ebp =
0xbfbff358 ---
db show lockedvnods
Locked vnodes
0xc6cd7de0: type VREG, usecount 0, writecount 0, refcount 0, flags (VV_OBJBUF)
tag VT_NFS, fileid 112174 fsid 0x100ff02
It looks like
Re: nfs_inactive() bug? - panic: lockmgr: locking against myself
In message [EMAIL PROTECTED], Don Lewis writes:
A potentially better solution just occurred to me. It looks like it
would be better if vrele() waited to decrement v_usecount until *after*
the call to VOP_INACTIVE() (and after the call to VI_LOCK()). If that
were done, nfs_inactive() wouldn't need to muck with v_usecount at all.
I've looked at this before; I think some filesystems (ufs anyway)
depend on v_usecount being 0 when VOP_INACTIVE() is called. The
patch I have had lying around for quite a while is below. It adds
a vnode flag to avoid recursion into the last-reference handling
code in vrele/vput, which is the real problem.
It also guarantees that a vnode will not be recycled during
VOP_INACTIVE(), so the nfs code no longer needs to hold an extra
reference in the first place. The flag manipulation code got a bit
messy after Jeff's vnode flag splitting work, so the patch could
probably be improved.
Whatever way this is done, we should try to avoid adding more hacks
to the nfs_inactive() code anyway.
Ian
Index: sys/vnode.h
===
RCS file: /home/iedowse/CVS/src/sys/sys/vnode.h,v
retrieving revision 1.206
diff -u -r1.206 vnode.h
--- sys/vnode.h 1 Sep 2002 20:37:21 - 1.206
+++ sys/vnode.h 11 Sep 2002 11:06:46 -
@@ -220,6 +220,7 @@
#defineVI_DOOMED 0x0080 /* This vnode is being recycled */
#defineVI_FREE 0x0100 /* This vnode is on the freelist */
#defineVI_OBJDIRTY 0x0400 /* object might be dirty */
+#defineVI_INACTIVE 0x0800 /* VOP_INACTIVE is in progress */
/*
* XXX VI_ONWORKLST could be replaced with a check for NULL list elements
* in v_synclist.
@@ -377,14 +378,14 @@
/* Requires interlock */
#defineVSHOULDFREE(vp) \
- (!((vp)-v_iflag (VI_FREE|VI_DOOMED)) \
+ (!((vp)-v_iflag (VI_FREE|VI_DOOMED|VI_INACTIVE)) \
!(vp)-v_holdcnt !(vp)-v_usecount \
(!(vp)-v_object || \
!((vp)-v_object-ref_count || (vp)-v_object-resident_page_count)))
/* Requires interlock */
#define VMIGHTFREE(vp) \
- (!((vp)-v_iflag (VI_FREE|VI_DOOMED|VI_XLOCK)) \
+ (!((vp)-v_iflag (VI_FREE|VI_DOOMED|VI_XLOCK|VI_INACTIVE)) \
LIST_EMPTY((vp)-v_cache_src) !(vp)-v_usecount)
/* Requires interlock */
Index: nfsclient/nfs_node.c
===
RCS file: /home/iedowse/CVS/src/sys/nfsclient/nfs_node.c,v
retrieving revision 1.55
diff -u -r1.55 nfs_node.c
--- nfsclient/nfs_node.c11 Jul 2002 17:54:58 - 1.55
+++ nfsclient/nfs_node.c11 Sep 2002 11:06:46 -
@@ -289,21 +289,7 @@
} else
sp = NULL;
if (sp) {
- /*
-* We need a reference to keep the vnode from being
-* recycled by getnewvnode while we do the I/O
-* associated with discarding the buffers unless we
-* are being forcibly unmounted in which case we already
-* have our own reference.
-*/
- if (ap-a_vp-v_usecount 0)
- (void) nfs_vinvalbuf(ap-a_vp, 0, sp-s_cred, td, 1);
- else if (vget(ap-a_vp, 0, td))
- panic(nfs_inactive: lost vnode);
- else {
- (void) nfs_vinvalbuf(ap-a_vp, 0, sp-s_cred, td, 1);
- vrele(ap-a_vp);
- }
+ (void)nfs_vinvalbuf(ap-a_vp, 0, sp-s_cred, td, 1);
/*
* Remove the silly file that was rename'd earlier
*/
Index: kern/vfs_subr.c
===
RCS file: /home/iedowse/CVS/src/sys/kern/vfs_subr.c,v
retrieving revision 1.401
diff -u -r1.401 vfs_subr.c
--- kern/vfs_subr.c 5 Sep 2002 20:46:19 - 1.401
+++ kern/vfs_subr.c 11 Sep 2002 11:06:46 -
@@ -829,7 +829,8 @@
for (count = 0; count freevnodes; count++) {
vp = TAILQ_FIRST(vnode_free_list);
- KASSERT(vp-v_usecount == 0,
+ KASSERT(vp-v_usecount == 0
+ (vp-v_iflag VI_INACTIVE) == 0,
(getnewvnode: free vnode isn't));
TAILQ_REMOVE(vnode_free_list, vp, v_freelist);
@@ -1980,8 +1981,8 @@
KASSERT(vp-v_writecount vp-v_usecount || vp-v_usecount 1,
(vrele: missed vn_close));
- if (vp-v_usecount 1) {
-
+ if (vp-v_usecount 1 ||
+ ((vp-v_iflag VI_INACTIVE) vp-v_usecount == 1)) {
vp-v_usecount--;
VI_UNLOCK(vp);
@@ -1991,13 +1992,20 @@
if (vp-v_usecount == 1) {
vp-v_usecount--;
/*
-* We must call VOP_INACTIVE with the node locked.
-* If we are doing a vput, the node is already locked,
-
panic: lockmgr: locking against myself with yesterday's -CURRENT
I got the word about the changes to vfs_subr.c vfs_bio.c fixing the hang at shutdown for yesterday's -CURRENT fairly late in the day yesterday, and since the problem didn't seem (as far as I could tell) to affect normal operation, I figured I'd just pick up the change at the following update (which would be this morning). However, once I started the make -j8 buildworld on this SMP machine (this morning), I got a panic. Here's a cut-and-paste from the serial console: Recovering vi editor sessions:. Initial rc.i386 initialization:. Configuring syscons: blanktime. Additional ABI support:. Local package initiCalization:reating DISK md10 md10: invalid primary partition table: no magic md10: invalid primary partition table: no magic [1] 232 Floating point exception (core dumped) Jul 7 05:41:21 freebeast kernel: pid 232 (newfs), uid 0: exited on signal 8 (core dumped) apache cvsupd . Additional TCP options:. Starting background filesystem checks Sun Jul 7 05:41:23 PDT 2002 FreeBSD/i386 (freebeast.catwhisker.org) (cuaa0) login: panic: lockmgr: locking against myself cpuid = 0; lapic.id = Debugger(panic) Stopped at Debugger+0x46: xchgl %ebx,in_Debugger.0 db tr Debugger(c030085a) at Debugger+0x46 panic(c02fe680,7,0,ce6811c0,2010022) at panic+0xd6 lockmgr(ce6811c0,2010022,c0347060,c1584cc0) at lockmgr+0x36b BUF_TIMELOCK(ce681114,22,c03085c1,0,0) at BUF_TIMELOCK+0x62 getblk(c421a200,e44030,0,2000,0) at getblk+0x97 breadn(c421a200,e44030,0,2000,0) at breadn+0x2f bread(c421a200,e44030,0,2000,0,d69d7920) at bread+0x20 ffs_blkfree(c41ad800,c421a200,723f8e,0,400) at ffs_blkfree+0x2ba ffs_truncate(c469a300,0,0,0,0) at ffs_truncate+0xff5 ufs_inactive(d69d7bac,d69d7bc4,c01eecd1,d69d7bac,c03312c0) at ufs_inactive+0x8e ufs_vnoperate(d69d7bac) at ufs_vnoperate+0x13 vrele(c469a300,ce76ce60,c46a5258,d69d7bec,c029d4fd) at vrele+0xb1 vm_object_vndeallocate(c46a5258,ce76ce60,ce76ce60,d69d7bfc,c01ee0c6) at vm_object_vndeallocate+0x6e vm_object_deallocate(c46a5258,c09b5334,d69d7c14,c01e3673,ce76ce60) at vm_object_deallocate+0x35 brelvp(ce76ce60) at brelvp+0xd2 vfs_vmio_release(ce76ce60) at vfs_vmio_release+0x14f getnewbuf(0,0,2000,4000,200010a4) at getnewbuf+0x15e geteblk(2000,0,c02fe5e2,23b,ce681114) at geteblk+0x23 bwrite(ce681114,d69d7cb0,c0188a5d,ce681114,2710) at bwrite+0x126 bawrite(ce681114) at bawrite+0x14 spec_fsync(d69d7ce0,d69d7d1c,c01ee24a,d69d7ce0,3d2837b7) at spec_fsync+0xc9 spec_vnoperate(d69d7ce0,3d2837b7,c41ba200,c0331380,c41b6e00) at spec_vnoperate+0x13 sched_sync(0,d69d7d48,c1584cc0,c01ee154,0) at sched_sync+0xf6 fork_exit(c01ee154,0,d69d7d48) at fork_exit+0xa8 fork_trampoline() at fork_trampoline+0x37 db show pcpu 0 cpuid= 0 curthread= 0xc1584cc0: pid 7 syncer curpcb = 0xd69d7da0 fpcurthread = none idlethread = 0xc1583d80: pid 12 idle: cpu0 currentldt = 0x28 spin locks held: db show pcpu 1 cpuid= 1 curthread= 0xc1583e40: pid 11 idle: cpu1 curpcb = 0xd699eda0 fpcurthread = none idlethread = 0xc1583e40: pid 11 idle: cpu1 currentldt = 0x28 spin locks held: db show locks exclusive sleep mutex Giant r = 1 (0xc0340d00) locked @ /usr/src/sys/vm/vm_object.c:1721 db I'm going ahead and sending this in because it seems fairly different from the traceback that was reported for yesterday's hang, so there might be some other problem that is shows. I will go ahead and reboot, and upgrade the kernel first, then see how a make buildworld goes. Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] Trying to support or use Microsoft products makes about as much sense as painting the outside of a house with watercolors. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: lockmgr: locking against myself with yesterday's -CURRENT
On 2002-07-07 06:01 +, David Wolfskill wrote: I got the word about the changes to vfs_subr.c vfs_bio.c fixing the hang at shutdown for yesterday's -CURRENT fairly late in the day yesterday, and since the problem didn't seem (as far as I could tell) to affect normal operation, I figured I'd just pick up the change at the following update (which would be this morning). However, once I started the make -j8 buildworld on this SMP machine (this morning), I got a panic. Here's a cut-and-paste from the serial console: Recovering vi editor sessions:. Initial rc.i386 initialization:. Configuring syscons: blanktime. Additional ABI support:. Local package initiCalization:reating DISK md10 md10: invalid primary partition table: no magic md10: invalid primary partition table: no magic [1] 232 Floating point exception (core dumped) Jul 7 05:41:21 freebeast kernel: pid 232 (newfs), uid 0: exited on signal 8 (core dumped) apache cvsupd . Additional TCP options:. Starting background filesystem checks Sun Jul 7 05:41:23 PDT 2002 FreeBSD/i386 (freebeast.catwhisker.org) (cuaa0) login: panic: lockmgr: locking against myself This is exactly what's showing up for me (and possibly others) in the KSE M-III status junior hacker project. thread. I'm currently building world too (this is a UP machine btw.), I guess we'll see if the most recent commits change this. -- Munish Chopra The FreeBSD NVIDIA Driver Initiative http://nvidia.netexplorer.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
