Date: Wed, 29 Jul 2009 16:46:01 +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: <4A705299.8060504@icyb.net.ua> In-Reply-To: <52AA86CB-6C06-4370-BA73-CE19175467D0@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> <4A7048A9.4020507@icyb.net.ua> <52AA86CB-6C06-4370-BA73-CE19175467D0@exscape.org>
next in thread | previous in thread | raw e-mail | index | archive | help
on 29/07/2009 16:24 Thomas Backman said the following: > Hmm, you are indeed right, it's not the same panic. The backtrace I got > just now with INVARIANTS is the one you quoted above. > I still get the "_sx_xlock (sx=Variable "sx" is not available.)" and > "_sx_xlock_hard (sx=0xffffff00090d5018, ..., opts=Variable "opts" is not > available.)" though. > Am I missing some option (I've got GENERIC, minus WITNESS plus DTRACE, > now that INVARIANTS is back in place), or does this "just happen"? Not sure what this question is about. What option, what "this" :-) > Here's the "full" backtrace (minus the panic(), trap() etc.): > > #10 0xffffffff8057dfe7 in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:224 > #11 0xffffffff80342b99 in _sx_xlock_hard (sx=0xffffff00090d5018, > tid=18446742974952890368, opts=Variable "opts" is not available. > ) at /usr/src/sys/kern/kern_sx.c:575 > #12 0xffffffff8034350e in _sx_xlock (sx=Variable "sx" is not available. > ) at sx.h:155 > #13 0xffffffff80af7596 in zfs_freebsd_reclaim () from /boot/kernel/zfs.ko > #14 0xffffffff805c5c2a in VOP_RECLAIM_APV (vop=0xffffff00090d5018, > a=0xffffff00090d5000) at vnode_if.c:1926 > #15 0xffffffff803c839e in vgonel (vp=0xffffff0009252588) at vnode_if.h:830 > #16 0xffffffff803cc958 in vflush (mp=0xffffff0002cd7bc0, rootrefs=0, > flags=0, > td=0xffffff002cffe000) at /usr/src/sys/kern/vfs_subr.c:2449 > #17 0xffffffff80af2038 in zfs_umount () from /boot/kernel/zfs.ko > #18 0xffffffff803c55ca in dounmount (mp=0xffffff0002cd7bc0, flags=47020992, > td=Variable "td" is not available. > ) at /usr/src/sys/kern/vfs_mount.c:1289 > #19 0xffffffff803c5df8 in unmount (td=0xffffff002cffe000, > uap=0xffffff803e98bbf0) at /usr/src/sys/kern/vfs_mount.c:1174 > #20 0xffffffff805980bf in syscall (frame=0xffffff803e98bc80) > at /usr/src/sys/amd64/amd64/trap.c:984 > #21 0xffffffff8057e2c1 in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:373 > #22 0x000000080104e9ec in ?? () > Previous frame inner to this frame (corrupt stack?) Looks like your zfs module is built without debugging symbols? Maybe because was it built/rebuilt individually, not as part of kernel build? It would be useful to get line number in frame 13 and examine sx object in frame 11, esp. sx_lock field. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A705299.8060504>