From owner-freebsd-stable@FreeBSD.ORG Thu Oct 16 17:36:54 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7694CB0F; Thu, 16 Oct 2014 17:36:53 +0000 (UTC) Date: Thu, 16 Oct 2014 17:36:49 +0000 From: Glen Barber To: Konstantin Belousov Subject: Re: Heads-up: Possible regression between 10.0-RELEASE and 10.1-BETA1 with '/ on ZFS' setup Message-ID: <20141016173649.GD36695@hub.FreeBSD.org> References: <20141004024011.GC1199@hub.FreeBSD.org> <20141004160052.GR26076@kib.kiev.ua> <20141004170137.GA1171@hub.FreeBSD.org> <1684676.g0E56GkSvf@overcee.wemm.org> <20141004174600.GU26076@kib.kiev.ua> <20141004211530.GB1171@hub.FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="io440R/5/oAEBxrM" Content-Disposition: inline In-Reply-To: <20141004211530.GB1171@hub.FreeBSD.org> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD Release Engineering Team , Steven Hartland , freebsd-stable@freebsd.org, Peter Wemm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 17:36:54 -0000 --io440R/5/oAEBxrM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 04, 2014 at 05:15:30PM -0400, Glen Barber wrote: > On Sat, Oct 04, 2014 at 08:46:00PM +0300, Konstantin Belousov wrote: > > On Sat, Oct 04, 2014 at 10:03:48AM -0700, Peter Wemm wrote: > > > > If we cannot increase KSTACK_PAGES by default, do we have any > > > > alternative solution outside of suggesting to avoid using ZFS on i3= 86 > > > > with more than one disk? > > >=20 > > > When zfs creates its kthreads it can specify how much stack it needs.= For=20 > > > i386 it could ask for more for the zfs threads. Its not a good optio= n but its=20 > > > better than more stack for everything when it's already easy to run o= ut=20 > > > without zfs. > >=20 > > This one probably happens in the init thread, not some of the zfs hord. > > Glen did not show the backtrace from ddb yet (I hope that ddb did not > > regressed and can step over double-fault boundary). > >=20 > > We could specifically increment the init thread stack size as well, but > > I have no idea if normal VFS calls into ZFS are affected and cause over= flow > > for the normal threads after the multitasking is fired. >=20 > As soon as I get the kernel built with debugging support, I'll be able > to get the backtrace. This, however, is proving to be non-trivial. >=20 I was finally able to get a VM configured in a way that would allow getting a ddb backtrace after panic. Screenshots of the panic are available here: https://people.freebsd.org/~gjb/i386-zfs/zfs-i386-1.png https://people.freebsd.org/~gjb/i386-zfs/zfs-i386-2.png https://people.freebsd.org/~gjb/i386-zfs/zfs-i386-3.png https://people.freebsd.org/~gjb/i386-zfs/zfs-i386-4.png I'll leave the VM in its current state in case more information is needed. I also want to point out that 10.0-RELEASE also crashes upon mounting the ZFS filesystems when the machine boots after an unclean shutdown, so although the behavior of "when" the machine crashes has changed, I am not certain this is a regression since 10.0-RELEASE. Glen --io440R/5/oAEBxrM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUQAIxAAoJEAMUWKVHj+KTe74QAIOC5FrHY4AQgeeNXvpJTv1+ hRKRZbUjB60Fk/N1930+Zo7vi5Vbok2o8B+VoBK9oAlyFJPscelS1Dck4nG69vWI CX+QEqG/V0o8LAF376ov8exe2GLvur2cAV6PywG76kSmghASvcJ7JrEjnHg9wdBr K/vGmWf+QUSn62NtML/jpIPst0SRjI2aplPLTnYWMNidok8XojvkBl6iiu0qVL8c mIhjV0A7JJru0NOHsFgnBSUcPtxV8b3qA6liROCzwzQcgTjB212SeSKtNQmyrlp3 Vz+Do5lwR61LIpsipBhpvCY05lkmh3w+3/BFfKj5GFtO0xZF6T7XKmlV3uEr1mA5 gRqEIlLOBUAmXnx82DvClTSme+27Mh9nMx0JpyQ6fMgxdJdlR3wAp8Nwe2ytY16m PN8yfDP+VdA7PGymkph7ZlsMeYVbXfWmOwVHvS3wWZYmpbmluiyW8Mzz+wXteKJY Stlun6/K1ly2PAe+ZgyeVNdAEK7aN7gmFlK0PsFkYVqiXWSBnr0l66z5gwHG6+SJ BaOVGgTZ49YVHkIUdrXjtfauNZ83OsGHurwlWOrapAthJ6lHxAEx2ln9oGz/M6iN Ggq4Bvw502xt8dUm9WWH5RZJq6DVikzTrJqWJJp4cx50+RZU7h2AmBnYrV2ssqND jwKju9LvFo6fGUVCLqt+ =eQw9 -----END PGP SIGNATURE----- --io440R/5/oAEBxrM--