Re: zfs: Fatal trap 12: page fault while in kernel mode

On Jul 30, 2009, at 16:46, Andriy Gapon wrote:

> on 30/07/2009 17:39 Thomas Backman said the following:
>> On Jul 30, 2009, at 16:24, Andriy Gapon wrote:
>>>
>>> Could you please add DEBUG_VFS_LOCKS to kernel config and check that
>>> we haven't
>>> broke VFS locking with the patch?
>>> Thank you again!
>>>
>>> --  
>>> Andriy Gapon
>> Hey, thank *you* :)
>> Currently recompiling the kernel, I'll have a look later. What do I  
>> do,
>> though? Just keep an eye on the console, or something more involved?
>> (Or, since the handbook mentions lockedvnods in ddb: when should I  
>> check
>> lockedvnods?)
>
> I think you should get a panic if anything goes wrong.
> And I think you would get one :-)
>
> Next thing to try after that is the updated patch from Pawel:
> http://people.freebsd.org/~pjd/patches/zfs_vnops.c.2.patch
Well, damnit!

KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
vfs_badlock() at vfs_badlock+0x95
VOP_RECLAIM_APV() at VOP_RECLAIM_APV+0x4a
vgonel() at vgonel+0x14d
vrecycle() at vrecycle+0x8b
zfs_freebsd_inactive() at zfs_freebsd_inactive+0x1a
VOP_INACTIVE_APV() at VOP_INACTIVE_APV+0x6c
vinactive() at vinactive+0x85
vput() at vput+0x1d8
dounmount() at dounmount+0x4af
unmount() at unmount+0x3c8
syscall() at syscall+0x28f
Xfast_syscall() at Xfast_syscall+0xe1
--- syscall (22, FreeBSD ELF64, unmount), rip = 0x80104e9ec, rsp =  
0x7fffffffaa98, rbp = 0x801223300 ---
VOP_RECLAIM: 0xffffff007b0ff1d8 interlock is locked but should not be
KDB: enter: lock violation
panic: from debugger

#9  0xffffffff8057eda7 in calltrap ()
     at /usr/src/sys/amd64/amd64/exception.S:224
#10 0xffffffff8036c8ad in kdb_enter (why=0xffffffff80613fd5 "vfslock",
     msg=0xa <Address 0xa out of bounds>) at cpufunc.h:63
#11 0xffffffff805c82fa in VOP_RECLAIM_APV (vop=0xffffffff80b8b220,
     a=0xffffff803ea09930) at vnode_if.c:1923
#12 0xffffffff803cbd5d in vgonel (vp=0xffffff007b0ff1d8) at vnode_if.h: 
830
#13 0xffffffff803cc10b in vrecycle (vp=0xffffff007b0ff1d8, td=Variable  
"td" is not available.
)
     at /usr/src/sys/kern/vfs_subr.c:2504
#14 0xffffffff80b13a9a in zfs_freebsd_inactive () from /boot/kernel/ 
zfs.ko
#15 0xffffffff805c842c in VOP_INACTIVE_APV (vop=0xffffffff80b8b220,
     a=0xffffff803ea099f0) at vnode_if.c:1863
#16 0xffffffff803cb435 in vinactive (vp=0xffffff007b0ff1d8,
     td=0xffffff007b2cd720) at vnode_if.h:807
#17 0xffffffff803cc788 in vput (vp=0xffffff007b0ff1d8)
     at /usr/src/sys/kern/vfs_subr.c:2257
#18 0xffffffff803c5a4f in dounmount (mp=0xffffff0002c438d0, flags=0,  
td=Variable "td" is not available.
)
     at /usr/src/sys/kern/vfs_mount.c:1333
#19 0xffffffff803c6058 in unmount (td=0xffffff007b2cd720,
     uap=0xffffff803ea09bf0) at /usr/src/sys/kern/vfs_mount.c:1174
#20 0xffffffff80598e7f in syscall (frame=0xffffff803ea09c80)
     at /usr/src/sys/amd64/amd64/trap.c:984
#21 0xffffffff8057f081 in Xfast_syscall ()

Happened at (or very close to!) the place of the original panic. :/

Regards,
Thomas

PS. I'll test Pawel's patch sometime after dinner. ;)