Date: Mon, 26 Jun 2017 13:34:35 -0700 From: Benno Rice <benno@jeamland.net> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Benjamin Kaduk <bjkfbsd@gmail.com>, Manfred Antar <null@pozo.com>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Current amd64 new error or warning from today's current with ruby r320323 Message-ID: <CC95ECFF-AB66-4D75-B937-045F4CB95283@jeamland.net> In-Reply-To: <20170626202524.GY3437@kib.kiev.ua> 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> <D94B09A1-9090-4C6A-8EC4-19D2AFBBA316@pozo.com> <20170625164115.GD3437@kib.kiev.ua> <CAJ5_RoDd8%2BOXPfeQ10U3f3-ZozhshWBUXdSVFpnx_ZkhO_n4bw@mail.gmail.com> <20170626202524.GY3437@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Jun 26, 2017, at 13:25, Konstantin Belousov <kostikbel@gmail.com> = 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 = <kostikbel@gmail.com> >> 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CC95ECFF-AB66-4D75-B937-045F4CB95283>