From owner-freebsd-stable@FreeBSD.ORG Sat Oct 4 15:16:56 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 2C62DC9E; Sat, 4 Oct 2014 15:16:56 +0000 (UTC) Date: Sat, 4 Oct 2014 11:16:51 -0400 From: Glen Barber To: Steven Hartland Subject: Re: Heads-up: Possible regression between 10.0-RELEASE and 10.1-BETA1 with '/ on ZFS' setup Message-ID: <20141004151651.GG1199@hub.FreeBSD.org> References: <20141004024011.GC1199@hub.FreeBSD.org> <64F0D761D09546C7B47DFAA1551500BE@multiplay.co.uk> <20141004031614.GD1199@hub.FreeBSD.org> <6618E7E0B17D41D09DB9B0160C2D4DF1@multiplay.co.uk> <9E274FD2D44943ED9F9C6057068C8CE0@multiplay.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kjpMrWxdCilgNbo1" Content-Disposition: inline In-Reply-To: <9E274FD2D44943ED9F9C6057068C8CE0@multiplay.co.uk> 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-stable@FreeBSD.org, FreeBSD Release Engineering Team 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: Sat, 04 Oct 2014 15:16:56 -0000 --kjpMrWxdCilgNbo1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 04, 2014 at 04:03:39PM +0100, Steven Hartland wrote: > >>On Sat, Oct 04, 2014 at 03:51:39AM +0100, Steven Hartland wrote: > >>> > This has been a known issue on i386 since the switch to Clang see U= PDATING: > >>> 20121223: > >>> After switching to Clang as the default compiler some users of= ZFS > >>> on i386 systems started to experience stack overflow kernel pa= nics. > >>> Please consider using 'options KSTACK_PAGES=3D4' in such confi= gurations. > >>> > In my experience your millage may vary but essentially without 4 st= ack pages > >>> > all bets are off in terms of stability. >=20 > Oh and just looking at the code kern.kstack_pages is read only so wont ha= ve > any effect, hence you will definitely need to set the kernel option as per > the UPDATING entry. >=20 Indeed, it is readonly. I'm building kernel on the test VM, but may have to get the kernel built somewhere else from a non-ZFS VM, because the i386 VM with ZFS is unusable. I'm not familiar with these parts of the kernel internals. What is the harm in making KSTACK_PAGES=3D4 the default in i386 GENERIC ? Glen --kjpMrWxdCilgNbo1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUMA9jAAoJEAMUWKVHj+KTuV8P/0LnCTRHveqPj+5IYJO04T8H NTNZ8T7lirZuzRrJfLAZCudrjjKODhja9s2nzjVb3TPNymoKfO+tl1IQwbZgbuxG 65KwoGVkZx37/0lUyZaHP0hCDAwGSTumItrf9VWl6vXpWNJ57Vf3+D0Henp7iF1T bkwHduin7W9E2M/cCT69hcwQl3cijDPhGoGWKwYKadlXZLkg8uYxPAOr2ws03kk2 i3HW1RGz8FeLYRGwoAzQKiW8YWBPoRnWFHp98pabuXY6WeZPhltYJ4M215N4YWfR GBNEONtzq0yEC6imYYhqZcishq69xO5f4KhY5efJ+V6AWDQNXLspdW1AiSceoBn7 sBXv2jp38+M4xYqqxFzxV+jES28kzcWnvVZp0AWGGpdUzJq5wf9lhrk+zE7Iz4wf mRUmElSGb5urLACuWk0NHndIwSsodgdryb0inenLA6MJa5cgcBnj6N2cCX+ndtkH LW/Gr5JNDjaHpTs1lIg1ldquRPBfaElai0t929SNMVaFo0J1m7GAu4aa89hEE8s3 4hBTDqZMabASyMq4gvf0AwWJrWEQF8BabpjQWikvs+5s0o6PYs0uvpmhljh1uHvi DdwfegNUBwjTlbztueVdzD3k3QLqfIhhceoHJEBYFgetSusaBjI5pRl4gWmv/5F0 sHuESRnjP5VGID08c5wO =UdJq -----END PGP SIGNATURE----- --kjpMrWxdCilgNbo1--