From owner-freebsd-current@FreeBSD.ORG Tue Jul 28 09:50:34 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 483CE1065688; Tue, 28 Jul 2009 09:50:34 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 136CA8FC0A; Tue, 28 Jul 2009 09:50:32 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA28274; Tue, 28 Jul 2009 12:50:27 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A6EC9E2.5070200@icyb.net.ua> Date: Tue, 28 Jul 2009 12:50:26 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090630) MIME-Version: 1.0 To: "O. Hartmann" References: <20090727072503.GA52309@jpru.ffm.jpru.de> <4A6E06E6.9030300@mail.zedat.fu-berlin.de> In-Reply-To: <4A6E06E6.9030300@mail.zedat.fu-berlin.de> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, Pawel Jakub Dawidek , freebsd-current@freebsd.org, Juergen Unger 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: Tue, 28 Jul 2009 09:50:34 -0000 on 27/07/2009 22:58 O. Hartmann said the following: > Juergen Unger wrote: [snip] >>> _sx_xlock(3c,0,874aa28d,70f,8ae9a9f8,...) at _sx_xlock+0x43 >>> dmu_buf_update_user(0,8ae9a9f8,0,0,0,...) at dmu_buf_update_user+0x35 >>> zfs_znode_dmu_fini(8ae9a9f8,874b312d,1114,110b,879ab000,...) at zfs_znode_dmu_f3 >>> zfs_freebsd_reclaim(fcd29c3c,1,0,8ec63754,fcd29c60,...) at zfs_freebsd_reclaim+0 >>> VOP_RECLAIM_APV(874b65a0,fcd29c3c,0,0,8ec637c8,...) at VOP_RECLAIM_APV+0xa5 >>> vgonel(8ec637c8,0,80c77037,386,0,...) at vgonel+0x1a4 >>> vnlru_free(80f2a0f0,0,80c77037,300,3e8,...) at vnlru_free+0x2d5 >>> vnlru_proc(0,fcd29d38,80c652bc,33e,871932a8,...) at vnlru_proc+0x80 >>> fork_exit(8090d960,0,fcd29d38) at fork_exit+0xb8 >>> fork_trampoline() at fork_trampoline+0x8 [snip] > > I see a similar problem on two SMP boxes (is your SMP?), but in my case, > it seems not to be ZFS related although I also use ZFS as /home filesystem In this case this does seem to be caused by ZFS. >From the backtrace we see that _sx_xlock() is called on bogus struct sx pointer (0x3c) and this is caused by dmu_buf_update_user() called with NULL first argument (dmu_buf_t). Which means that znode_t z_dbuf was NULL - this could have been caught by ASSERT in zfs_znode_dmu_fini if it were enabled. If you have the crash dump, then it would be interesting to examine znode_t structure ('zp' argument) in zfs_znode_dmu_fini. P.S. I see that zfs_inactive checks for z_dbuf being NULL and there is the following comment: /* * The fs has been unmounted, or we did a * suspend/resume and this file no longer exists. */ Maybe zfs_freebsd_reclaim should do the same? P.P.S. I am not a VFS or ZFS expert. -- Andriy Gapon