From owner-freebsd-current@FreeBSD.ORG Wed Jul 29 13:52:44 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D857A1065693; Wed, 29 Jul 2009 13:52:43 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 5BDA88FC24; Wed, 29 Jul 2009 13:52:43 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:46627 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1MW9a1-0001Fa-49; Wed, 29 Jul 2009 15:52:31 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id B68C9163F72; Wed, 29 Jul 2009 15:52:29 +0200 (CEST) Message-Id: From: Thomas Backman To: Andriy Gapon In-Reply-To: <4A705299.8060504@icyb.net.ua> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 29 Jul 2009 15:52:27 +0200 References: <20090727072503.GA52309@jpru.ffm.jpru.de> <4A6E06E6.9030300@mail.zedat.fu-berlin.de> <4A6EC9E2.5070200@icyb.net.ua> <20090729084723.GD1586@garage.freebsd.pl> <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> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MW9a1-0001Fa-49. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MW9a1-0001Fa-49 97b855054291372e8d10e59664a6bd61 Cc: freebsd-fs@FreeBSD.org, FreeBSD current , Pawel Jakub Dawidek Subject: Re: zfs: Fatal trap 12: page fault while in kernel mode X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 13:52:45 -0000 On Jul 29, 2009, at 15:46, Andriy Gapon wrote: > 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 The "this" (above) was referring to variable values not being available in a vmcore. :) The zfs module appears to be built with symbols, and the symbols appear to be loaded in kgdb: Reading symbols from /boot/kernel/zfs.ko...Reading symbols from / bootdir/boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /bootdir/boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko I didn't build the module(s) individually, either; in the previous cases, it was a clean buildworld/buildkernel (even with rm -rf /usr/ obj/* beforehand), and in this case "just" a buildkernel (no manual cleaning, but no -DNO_CLEAN either). Regards, Thomas