Date: Thu, 16 Oct 2014 17:36:49 +0000 From: Glen Barber <gjb@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: FreeBSD Release Engineering Team <re@freebsd.org>, Steven Hartland <smh@freebsd.org>, freebsd-stable@freebsd.org, Peter Wemm <peter@wemm.org> 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> In-Reply-To: <20141004211530.GB1171@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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141016173649.GD36695>