Date: Fri, 5 Jun 2009 16:17:44 +0200 From: Thomas Backman <serenity@exscape.org> To: Kip Macy <kmacy@freebsd.org> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Fatal trap 12: page fault panic with recent kernel with ZFS Message-ID: <3AB9BCA0-DCEA-4E64-A01D-8BA9B75C3ECD@exscape.org> In-Reply-To: <3c1674c90905211131q607e05a9m68e906f2d3620414@mail.gmail.com> References: <20090518145614.GF82547@egr.msu.edu> <alpine.BSF.2.00.0905181031240.35767@thebighonker.lerctr.org> <alpine.BSF.2.00.0905181830490.1756@borg> <3c1674c90905181659g1d20f0f1w3f623966ae4440ec@mail.gmail.com> <alpine.BSF.2.00.0905181906001.2008@borg> <3c1674c90905181800x469d3cabx5df959d3585b4b5a@mail.gmail.com> <040ce5cee10b3b92fd127bbce83f4c77.squirrel@webmail.lerctr.org> <3c1674c90905181815r49a5bbe2u5d4a73e4f91f89a6@mail.gmail.com> <E419A991-E81E-44D8-9E17-1027B56AAD48@exscape.org> <3c1674c90905211131q607e05a9m68e906f2d3620414@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 21, 2009, at 08:31 PM, Kip Macy wrote: >> Hey, I (not the OP) am still having trouble with this. The panics >> appear to >> be gone since I set arc_min to 30M and arc_max to 100M, though (2GB >> RAM). >> I get/got them during a full zfs send -R | zfs recv -Fvd of a >> ~3.3GB pool. >> The only modification I've done to the source tree is the >> libzfs_sendrecv >> patch here: >> http://lists.freebsd.org/pipermail/freebsd-current/2009-May/006814.html > > > I'll apply the patch this weekend. > > If I get time I'll also try to reproduce your panic. > > > Thanks, > Kip Two weekends later and still the same deal with send | recv. ;) Just worried that this'll make it into 8.0-RELEASE, that's all. That would be bad. The patch linked above seems to solve the problem for me, anyway. I just tried a fresh build (sources from June 5th at 10AM CEST), without the patch, and I got the same core dump on zfs recv, with a SIGSEGV in strcmp(). (See the linked thread.) Applied the patch, rebuild libzfs, rebooted, and it works again. It seems something along the lines of zfs snapshot -r tank@initial-snapshot zfs send -R tank@initial-snapshot | zfs recv -vFd slave and then zfs snapshot -r tank@testsnap # some other, unrelated snapshot in between may or may not be needed to crash, I'm not sure zfs snapshot -r tank@second-snapshot zfs send -R -I initial-snapshot tank@second-snapshot | zfs recv -Fvd slave causes the core dump. Regards, Thomas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3AB9BCA0-DCEA-4E64-A01D-8BA9B75C3ECD>