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

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
>> a panics-every-time script) I tried this patch. Unfortunately, I  
>> still
>> get the same panic (from vgonel() and up, it's the same, except for  
>> my
>> typo in the linked email.)
>
> Your panics are superficially similar but seem to be different.
> But it is hard to tell as function argument values are not available  
> in your
> backtraces for the interesting calls.
> One difference that I see is that your panics happen one level below  
> _sx_xlock, in
> sx_xlock_hard and sx argument value appears to be far from NULL
> (0xffffff0043557d50) - in the panic that started this thread it was  
> near NULL.
> Another difference is that you panics do not involve  
> zfs_znode_dmu_fini and
> mu_buf_update_user, in your case sx_xlock is called directly from
> zfs_freebsd_reclaim. So it must a problem with a different lock.
>
> -- 
> Andriy Gapon
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.)

 > 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 :)
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.

Regards,
Thomas