Date: Sat, 3 May 2014 19:14:24 +0200 From: Fabian Keil <freebsd-listen@fabiankeil.de> To: "FreeBSD-Current" <freebsd-current@FreeBSD.org> Subject: Re: Fatal double fault in ZFS with yesterday's CURRENT Message-ID: <20140503191424.16f9744b@fabiankeil.de> In-Reply-To: <FE7EC65BCB3D44E2B9864D48346CA638@multiplay.co.uk> References: <20140503102923.6fadd904@fabiankeil.de> <FE7EC65BCB3D44E2B9864D48346CA638@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/pHIyTFVZAXT=BiZZO2xpe75 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable "Steven Hartland" <killing@multiplay.co.uk> wrote: > From: "Fabian Keil" <freebsd-listen@fabiankeil.de> >=20 > > After updating my laptop to yesterday's CURRENT (r265216), > > I got the following fatal double fault on boot: > > http://www.fabiankeil.de/bilder/freebsd/kernel-panic-r265216/ > >=20 > > My previous kernel was based on r264721. > > > > I'm using a couple of custom patches, some of them are ZFS-related > > and thus may be part of the problem (but worked fine for months). > > I'll try to reproduce the panic without the patches tomorrow. > > >=20 > Your seeing a stack overflow in the new ZFS queuing code, which I > believe is being triggered by lack of support for TRIM in one of > your devices, something Xin reported to me yesterday. >=20 > I commited a fix for failing TRIM requests processing slowly last > night so you could try updating to after r265253 and see if that > helps. Thanks. The hard disk is indeed unlikely to support TRIM requests, but I can still reproduce the problem with a kernel based on r265255. > I still need to investigate the stack overflow more directly which > appears to be caused by the new zfs queuing code when things are > running slowly and there's a large backlog of IO's. > > I would be interested to know you config there so zpool layout and > hardware in the mean time. The system is a Lenovo ThinkPad R500: http://www.nycbug.org/index.cgi?action=3Ddmesgd&do=3Dview&dmesgid=3D2449 I'm booting from UFS, the panic occurs while the pool is being imported. The pool is located on a single geli-encrypted slice: fk@r500 ~ $zpool status tank pool: tank state: ONLINE scan: scrub repaired 0 in 4h11m with 0 errors on Sat Mar 22 18:25:01 2014 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 ada0s1d.eli ONLINE 0 0 0 errors: No known data errors Maybe geli fails TRIM requests differently. Fabian --Sig_/pHIyTFVZAXT=BiZZO2xpe75 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iEYEARECAAYFAlNlI/MACgkQBYqIVf93VJ1P1wCgvrfnBkZTQ3AD53bnW4GJ0dmc R8oAoIhGMoYpDswbDyy2Z0W/ITGw0I9u =aQ2W -----END PGP SIGNATURE----- --Sig_/pHIyTFVZAXT=BiZZO2xpe75--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140503191424.16f9744b>