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

on 29/07/2009 15:45 Thomas Backman said the following:
> On Jul 29, 2009, at 13:21, Andriy Gapon wrote:
> 
>> on 29/07/2009 13:32 Thomas Backman said the following:
>>> OFF TOPIC:
>>> Due to similarities in the backtrace between this and a panic I've been
>>> seeing on exporting after zfs recv (see
>>> http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009105.html and
>>>
>>> also
>>> http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009174.html for
>>>
[snip]
> The DDB output from one panic does involve zfs_znode_dmu_fini and
> dmu_buf_update_user:
> _sx_xlock()
> dmu_buf_update_user()+0x47
> zfs_znode_dmu_fini()
> zfs_freebsd_reclaim()
> VOP_RECLAIM_APV()
> vgonel()
> vflush()
> zfs_umount()
> dounmount()
> unmount()
> syscall()
> Xfast_syscall()
> (Sorry if the formatting got screwed up above.)

Hmm, then you experienced two different kinds of panics.
To quote the link you posted earlier:
[1] http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009174.html
...
#10 0xffffffff8086e007 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:223
#11 0xffffffff805a4989 in _sx_xlock_hard (sx=0xffffff0043557d50,
tid=18446742975830720512, opts=Variable "opts" is not available.) at
/usr/src/sys/kern/kern_sx.c:575
#12 0xffffffff805a52fe in _sx_xlock (sx=Variable "sx" is not available.) at sx.h:155
#13 0xffffffff80fe2995 in zfs_freebsd_reclaim () from /boot/kernel/zfs.ko
...

So now that you said that the patch didn't fix the problem for you, could you
please clarify what panic you do see after applying it?

>> BTW, have you tried to reproduce the problem with INVARIANTS enabled?
>> Do you have crashdumps with debugging symbols?
> 
> I tried again with INVARIANTS, but see no difference in the panic, the
> DDB bt or the KGDB bt. What does invariants really do? (Not sure how to
> use it to my advantage here :)

INVARIANTS enables KASSERTs in various parts of code which can help to catch bugs
earlier that may result in cryptic panics afterwards.

> Re: debugging symbols; isn't that the default? I do have a .symbols file
> for all the files in /boot/kernel, but that's all I know to be honest.

Ok, then if you get a crash dump, you are able use kgdb and it will be able to
produce line numbers and will allow to examine variables.

P.S. sorry if I miss context of your previous reports.

-- 
Andriy Gapon