Date: Wed, 29 Jul 2009 16:03:37 +0300 From: Andriy Gapon <avg@icyb.net.ua> To: Thomas Backman <serenity@exscape.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: <4A7048A9.4020507@icyb.net.ua> In-Reply-To: <97D5950F-4E4D-4446-AC22-92679135868D@exscape.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>
next in thread | previous in thread | raw e-mail | index | archive | help
on 29/07/2009 15:45 Thomas Backman said the following: > 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 >>> [snip] > 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.) Hmm, then you experienced two different kinds of panics. To quote the link you posted earlier: [1] http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009174.html ... #10 0xffffffff8086e007 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:223 #11 0xffffffff805a4989 in _sx_xlock_hard (sx=0xffffff0043557d50, tid=18446742975830720512, opts=Variable "opts" is not available.) at /usr/src/sys/kern/kern_sx.c:575 #12 0xffffffff805a52fe in _sx_xlock (sx=Variable "sx" is not available.) at sx.h:155 #13 0xffffffff80fe2995 in zfs_freebsd_reclaim () from /boot/kernel/zfs.ko ... So now that you said that the patch didn't fix the problem for you, could you please clarify what panic you do see after applying it? >> 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 :) INVARIANTS enables KASSERTs in various parts of code which can help to catch bugs earlier that may result in cryptic panics afterwards. > 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. Ok, then if you get a crash dump, you are able use kgdb and it will be able to produce line numbers and will allow to examine variables. P.S. sorry if I miss context of your previous reports. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A7048A9.4020507>