Date: Wed, 29 Jul 2009 10:47:23 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Andriy Gapon <avg@icyb.net.ua> Cc: freebsd-fs@FreeBSD.org, "O. Hartmann" <ohartman@mail.zedat.fu-berlin.de>, freebsd-current@FreeBSD.org, Juergen Unger <lists@jpru.de> Subject: Re: zfs: Fatal trap 12: page fault while in kernel mode Message-ID: <20090729084723.GD1586@garage.freebsd.pl> In-Reply-To: <4A6EC9E2.5070200@icyb.net.ua> References: <20090727072503.GA52309@jpru.ffm.jpru.de> <4A6E06E6.9030300@mail.zedat.fu-berlin.de> <4A6EC9E2.5070200@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
--8GpibOaaTibBMecb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Jul 28, 2009 at 12:50:26PM +0300, Andriy Gapon wrote:
> 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_z=
node_dmu_f3
> >>> zfs_freebsd_reclaim(fcd29c3c,1,0,8ec63754,fcd29c60,...) at zfs_freebs=
d_reclaim+0
> >>> VOP_RECLAIM_APV(874b65a0,fcd29c3c,0,0,8ec637c8,...) at VOP_RECLAIM_AP=
V+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]
> >=20
> > 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 filesys=
tem
>=20
> 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 b=
een
> caught by ASSERT in zfs_znode_dmu_fini if it were enabled.
>=20
> If you have the crash dump, then it would be interesting to examine znode=
_t
> structure ('zp' argument) in zfs_znode_dmu_fini.
>=20
> 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?
Yes, you might be right.
Could you guys, who can reproduce it, try this patch:
http://people.freebsd.org/~pjd/patches/zfs_vnops.c.2.patch
--=20
Pawel Jakub Dawidek http://www.wheel.pl
pjd@FreeBSD.org http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!
--8GpibOaaTibBMecb
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)
iD8DBQFKcAybForvXbEpPzQRAr1LAJ4hh/MnGNtjpDIj53DAz9C6pRYm9QCfcwlj
o4+rX0e6DP6AhsOI90IrHKw=
=/BOp
-----END PGP SIGNATURE-----
--8GpibOaaTibBMecb--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090729084723.GD1586>