> On Jun 26, 2017, at 13:25, Konstantin Belousov <kostik...@gmail.com> wrote:
> On Mon, Jun 26, 2017 at 02:53:14PM -0500, Benjamin Kaduk wrote:
>> On Sun, Jun 25, 2017 at 11:41 AM, Konstantin Belousov <kostik...@gmail.com>
>>> 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
>>> 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.
>>> Try this.
>> 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.
>> Is it worth trying that patch out?
> Ensure that you run a kernel past r320344 and then show me ktrace of
> the failing process.
So I’m 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
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 = 12)
Abort trap (core dumped)
I booted into single-user and ran zfs under ktrace and I’ve put the results up
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"