From owner-freebsd-current@freebsd.org Mon Jun 26 20:34:42 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32EC1D91688 for ; Mon, 26 Jun 2017 20:34:42 +0000 (UTC) (envelope-from benno@jeamland.net) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ADEDC653AC for ; Mon, 26 Jun 2017 20:34:39 +0000 (UTC) (envelope-from benno@jeamland.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 0FDCB20B9A; Mon, 26 Jun 2017 16:34:38 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Mon, 26 Jun 2017 16:34:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jeamland.net; h= cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=aYk3jjNlChJ4fAvJOzpVww0V5EovPZtycUp/wXA/1 Ug=; b=ZF9oVwsOUmJH+Z2WfgAIxOpb394z4pWmrKhDbh7dHPKSVCDPcSDdCHSjQ tNxw2SgcB1Qhg5rOrVi/Bp2q1qhEwlB7Lm08n7so4ttH1wo4vnBhMh0XHmPSnJ6f 4CbMYwfPTrAZt4I1VegJFdXhFhHsrRNgGdV4Y2MBWKCaKbFzCokFoH0hcyfrqkSl a3YUegbm0Wd5szZgWBS760mvkW2bY3+tBz/lDmXnAcCsM+1UFyhQhsAABOiUTELr 0DF+JLBCYkslPB2KU4mA3X7Ud0C90JgZX36eRvPYPrQqgvCmlJivHKwdo88XTBjI S4yAd5d4Sx2qTBse2TvmemxvXoM7g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=aYk3jjNlChJ4fAvJOz pVww0V5EovPZtycUp/wXA/1Ug=; b=N6HJQjVSphWZ8+XgvJ5mzVVshaCfJa/Xur s546dP5MmXMjqspgY3F5Z+r6fuv0vtGqyDJne7CBiAmBZ5dL1U/QXX0XfjMY8QZF embzFF1YblDcX2//UsRDB53WxwHhvKe96IWoP+WNMpX8FmMJeM+aC8mK8hEAsAtN ICY7G3YMkvLXHu5CGhK9WXTblEpx0q+ZtdCBKqsF9ZXl/pEhVRLmWdla7MfArKil 7kwXyRB8aHM4npi1dGaQzsc8Ho3ehFYGwzFXAh04XElIAUTaoNKhGUudKDYMCEB3 M07rIeHyGpCwm98g4v1gkm8tW1YXoAgVh0CGMcU+K6oXM1+Rc9yA== X-ME-Sender: X-Sasl-enc: RPJraGkeZUh3LQvLLHB76KNjlQGxyBhheXMF9fVqvBDE 1498509277 Received: from mittlerweile.west.isilon.com (c-76-104-201-218.hsd1.wa.comcast.net [76.104.201.218]) by mail.messagingengine.com (Postfix) with ESMTPA id 46BD87E7EE; Mon, 26 Jun 2017 16:34:37 -0400 (EDT) From: Benno Rice Message-Id: Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Current amd64 new error or warning from today's current with ruby r320323 Date: Mon, 26 Jun 2017 13:34:35 -0700 In-Reply-To: <20170626202524.GY3437@kib.kiev.ua> Cc: Benjamin Kaduk , Manfred Antar , FreeBSD Current To: Konstantin Belousov References: <20170625012359.GS3437@kib.kiev.ua> <040BF7D1-2FDF-415B-9A17-ADD608503F14@pozo.com> <20170625020441.GT3437@kib.kiev.ua> <219E6B59-EF90-443D-8B53-4C39C4D6CFBD@pozo.com> <20170625134133.GA3437@kib.kiev.ua> <3FEA16E1-673F-4C58-8362-C1DCC0680698@pozo.com> <20170625145008.GB3437@kib.kiev.ua> <20170625164115.GD3437@kib.kiev.ua> <20170626202524.GY3437@kib.kiev.ua> X-Mailer: Apple Mail (2.3273) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 20:34:42 -0000 > On Jun 26, 2017, at 13:25, Konstantin Belousov = wrote: >=20 > On Mon, Jun 26, 2017 at 02:53:14PM -0500, Benjamin Kaduk wrote: >> On Sun, Jun 25, 2017 at 11:41 AM, Konstantin Belousov = >> wrote: >>=20 >>> No need, I understood why MAP_STACK failed in this case, thanks to = the >>> ktrace log. This is indeed something ruby-specific, or rather, = triggered >>> by ruby special use of libthr. It is not related to the main stack >>> split. >>>=20 >>> It seems that ruby requested very small stack for a new thread, only = 5 >>> pages in size. This size caused the stack gap to be correctly = calculated >>> as having zero size, because the whole stack is allocated by initial = grow. >>> But then there is no space for the guard page, which caused mapping = failure >>> for it, and overall stack mapping failure. >>>=20 >>> Try this. >>> https://people.freebsd.org/~kib/misc/vm2.2.patch >>>=20 >>>=20 >> I managed to get the "Cannot allocate red zone for initial thread" at = the >> start of installworld (doing CC feature detection, IIRC) going from = r306247 >> to r320328. >>=20 >> Is it worth trying that patch out? >=20 > Ensure that you run a kernel past r320344 and then show me ktrace of > the failing process. So I=E2=80=99m running r320364 with a ZFS root: > uname -a FreeBSD bjrbsd 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r320364: Mon Jun 26 = 12:35:03 PDT 2017 = benno@bjrbsd:/src/obj/src/freebsd/sys/GENERIC-NODEBUG amd64 While upgrading I discovered that the zfs command works fine in = multiuser but fails in single-user in the way described above: # zfs mount -a Fatal error 'Cannot allocate red zone for initial thread' at line 393 in = file /src/freebsd/lib(something)/thread/thr_init.c (errno =3D 12) Abort trap (core dumped) I booted into single-user and ran zfs under ktrace and I=E2=80=99ve put = the results up for you: https://people.freebsd.org/~benno/ktrace.out.txt https://people.freebsd.org/~benno/ktrace.out https://people.freebsd.org/~benno/zfs.core=