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

On Jul 29, 2009, at 10:47, Pawel Jakub Dawidek wrote:

> On Tue, Jul 28, 2009 at 12:50:26PM +0300, Andriy Gapon wrote:
>> on 27/07/2009 22:58 O. Hartmann said the following:
>>> Juergen Unger wrote:
>> [snip]
>>>>> _sx_xlock(3c,0,874aa28d,70f,8ae9a9f8,...) at _sx_xlock+0x43
>>>>> dmu_buf_update_user(0,8ae9a9f8,0,0,0,...) at dmu_buf_update_user 
>>>>> +0x35
>>>>> zfs_znode_dmu_fini(8ae9a9f8,874b312d,1114,110b,879ab000,...) at  
>>>>> zfs_znode_dmu_f3
>>>>> zfs_freebsd_reclaim(fcd29c3c,1,0,8ec63754,fcd29c60,...) at  
>>>>> zfs_freebsd_reclaim+0
>>>>> VOP_RECLAIM_APV(874b65a0,fcd29c3c,0,0,8ec637c8,...) at  
>>>>> VOP_RECLAIM_APV+0xa5
>>>>> vgonel(8ec637c8,0,80c77037,386,0,...) at vgonel+0x1a4
>>>>> vnlru_free(80f2a0f0,0,80c77037,300,3e8,...) at vnlru_free+0x2d5
>>>>> vnlru_proc(0,fcd29d38,80c652bc,33e,871932a8,...) at vnlru_proc 
>>>>> +0x80
>>>>> fork_exit(8090d960,0,fcd29d38) at fork_exit+0xb8
>>>>> fork_trampoline() at fork_trampoline+0x8
>> [snip]
>>>
>>> I see a similar problem on two SMP boxes (is your SMP?), but in my  
>>> case,
>>> it seems not to be ZFS related although I also use ZFS as /home  
>>> filesystem
>>
>> In this case this does seem to be caused by ZFS.
>>> From the backtrace we see that _sx_xlock() is called on bogus  
>>> struct sx pointer
>> (0x3c) and this is caused by dmu_buf_update_user() called with NULL  
>> first argument
>> (dmu_buf_t). Which means that znode_t z_dbuf was NULL - this could  
>> have been
>> caught by ASSERT in zfs_znode_dmu_fini if it were enabled.
>>
>> If you have the crash dump, then it would be interesting to examine  
>> znode_t
>> structure ('zp' argument) in zfs_znode_dmu_fini.
>>
>> P.S. I see that zfs_inactive checks for z_dbuf being NULL and there  
>> is the
>> following comment:
>> /*
>> * The fs has been unmounted, or we did a
>> * suspend/resume and this file no longer exists.
>> */
>> Maybe zfs_freebsd_reclaim should do the same?
>
> Yes, you might be right.
>
> Could you guys, who can reproduce it, try this patch:
>
> 	http://people.freebsd.org/~pjd/patches/zfs_vnops.c.2.patch
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.)
Just thought I should point it out. Except for temporary storage  
problems when moving my data to ZFS, this panic is the last hurdle in  
not using FreeBSD for me. :/

Regards,
Thomas