On Mon, Sep 23, 2013 at 03:37:08PM +0200, Patrick Lamaiziere wrote: > Le Fri, 20 Sep 2013 15:17:05 +0200, > Patrick Lamaiziere <[email protected]> a ?crit : > > > Le Thu, 12 Sep 2013 10:36:43 +0300, > > Konstantin Belousov <[email protected]> a ?crit : > > > > Hello, > > > > > Might be, your issue is that some filesystems do not care about > > > proper locking mode for the fifos. UFS carefully disables shared > > > locking for VFIFO, but it seems ZFS is not. I can propose the > > > following band-aid, which could help you. > > > > > > I have no idea is it the same issue as the kqueue panic. > > > > > > diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c > > > index c53030a..00bd998 100644 > > > --- a/sys/kern/vfs_vnops.c > > > +++ b/sys/kern/vfs_vnops.c > > > @@ -267,6 +267,8 @@ vn_open_vnode(struct vnode *vp, int fmode, > > > struct ucred *cred, return (error); > > > } > > > } > > > + if (vp->v_type == VFIFO && VOP_ISLOCKED(vp) != > > > LK_EXCLUSIVE) > > > + vn_lock(vp, LK_UPGRADE | LK_RETRY); > > > if ((error = VOP_OPEN(vp, fmode, cred, td, fp)) != 0) > > > return (error); > > > > > > @@ -358,7 +360,7 @@ vn_close(vp, flags, file_cred, td) > > > struct mount *mp; > > > int error, lock_flags; > > > > > > - if (!(flags & FWRITE) && vp->v_mount != NULL && > > > + if (vp->v_type != VFIFO && !(flags & FWRITE) && > > > vp->v_mount != NULL && vp->v_mount->mnt_kern_flag & > > > MNTK_EXTENDED_SHARED) lock_flags = LK_SHARED; > > > else > > > > Ok This has been mfced to 9.2-STABLE. But I still see this panic with > 9-2/STABLE of today (Revision : 255811). This may be better because > before the box paniced within minutes and now within hours (still using > poudriere). > > panic: > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff808ebfcd > stack pointer = 0x28:0xffffff824c2e0630 > frame pointer = 0x28:0xffffff824c2e06a0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 54243 (gvfsd-trash) > trap number = 12 > panic: page fault > cpuid = 2 > KDB: stack backtrace: > #0 0xffffffff80939ad6 at kdb_backtrace+0x66 > #1 0xffffffff808ffacd at panic+0x1cd > #2 0xffffffff80cdfbe9 at trap_fatal+0x289 > #3 0xffffffff80cdff4f at trap_pfault+0x20f > #4 0xffffffff80ce0504 at trap+0x344 > #5 0xffffffff80cc9b43 at calltrap+0x8 > #6 0xffffffff8099d043 at filt_vfsvnode+0xf3 > #7 0xffffffff808c4793 at kqueue_register+0x3e3 > #8 0xffffffff808c4de8 at kern_kevent+0x108 > #9 0xffffffff808c5950 at sys_kevent+0x90 > #10 0xffffffff80cdf3a8 at amd64_syscall+0x5d8 > #11 0xffffffff80cc9e27 at Xfast_syscall+0xf7 > > Full core.txt : > http://user.lamaiziere.net/patrick/public/vfs_vnode-core.txt.0
For start, please load the core into kgdb and for frame 8 p *kn Also, please follow http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html to recompile kernel with the debugging options and try to recreate the panic.
pgpNUT12ewyWc.pgp
Description: PGP signature
