Date: Thu, 30 Jul 2009 16:39:36 +0200 From: Thomas Backman <serenity@exscape.org> To: Andriy Gapon <avg@FreeBSD.org> Cc: freebsd-fs@freebsd.org, FreeBSD current <freebsd-current@freebsd.org>, Pawel Jakub Dawidek <pjd@freebsd.org> Subject: Re: zfs: Fatal trap 12: page fault while in kernel mode Message-ID: <7544AED1-1216-4A24-B287-F54117641F76@exscape.org> In-Reply-To: <4A71AD29.10705@freebsd.org> References: <20090727072503.GA52309@jpru.ffm.jpru.de> <4A6E06E6.9030300@mail.zedat.fu-berlin.de> <4A6EC9E2.5070200@icyb.net.ua> <20090729084723.GD1586@garage.freebsd.pl> <F4F82B3E-C119-40EF-9AA4-937052876D1E@exscape.org> <4A7030B6.8010205@icyb.net.ua> <97D5950F-4E4D-4446-AC22-92679135868D@exscape.org> <4A7048A9.4020507@icyb.net.ua> <52AA86CB-6C06-4370-BA73-CE19175467D0@exscape.org> <4A705299.8060504@icyb.net.ua> <D3491B77-DA5C-4E10-BE1D-D6EF8CFB112E@exscape.org> <4A7054E1.5060402@icyb.net.ua> <5918824D-A67C-43E6-8685-7B72A52B9CAE@exscape.org> <4A705E50.8070307@icyb.net.ua> <4A70728C.7020004@freebsd.org> <6D47A34B-0753-4CED-BF3D-C505B37748FC@exscape.org> <4A708455.5070304@freebsd.org> <86983A55-E5C4-4C04-A4C7-0AE9A9EE37A3@exscape.org> <4A718E03.6030909@freebsd.org> <71A038EC-02B1-4606-96C2-5E84BE80F005@exscape.org> <4A719CA4.4060400@freebsd.org> <19347561-3CE6-40B3-930A-EB9925D3AFD1@exscape.org> <4A71AD29.10705@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7544AED1-1216-4A24-B287-F54117641F76>