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

From: Thomas Backman <serenity_at_exscape.org>
Date: Thu, 30 Jul 2009 16:39:36 +0200
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?)

BTW: Could you (or anyone else with knowledge in these areas) have a  
look at the libzfs_sendrecv patch? Final piece of the puzzle as far as  
all the panics (well, core dump in this case) I've ran in to is  
concerned.
http://lists.freebsd.org/pipermail/freebsd-current/2009-May/006814.html
Or, in patch form (I think the intendation screws the patch up as  
linked there):
http://exscape.org/temp/libzfs_sendrecv.patch

Appears to be a pretty simple patch. I've tried writing a test case,  
but it's a bit of work to make it create separate pools, etc, so I'd  
rather skip that if possible. Without the patch, I can't get send -R - 
I (recursive + auto-incremental, i.e. you can do -I snap1 tank_at_snap4  
instead of -i snap1 -i snap2 ...) to work without core dumping on the  
recv (sending to a file works just fine, but when receiving from the  
file, it core dumps; of course, the same is true for a pipe).

Regards,
Thomas
Received on Thu Jul 30 2009 - 12:39:52 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:52 UTC