On Sun, Jun 25, 2017 at 08:21:33AM -0700, Manfred Antar wrote: > > > On Jun 25, 2017, at 7:50 AM, Konstantin Belousov <kostikbel_at_gmail.com> wrote: > > > > On Sun, Jun 25, 2017 at 07:43:25AM -0700, Manfred Antar wrote: > >> maybe message got reformatted in mail program (mac mail). > >> could you send me a tar file of the patch? > >> also not sure if ???patch -p1 <patchfile??? is the correct invocation of patch > >> > >> you could cc root_at_pozo.com <mailto:root_at_pozo.com> , that way i have copy on freebsd box and on mac. > > > > https://people.freebsd.org/~kib/misc/vm2.1.patch <https://people.freebsd.org/~kib/misc/vm2.1.patch> > > OK patched and built new kernel \ > rebooted, > same ruby message. So it must be a ruby thing. > new kdump.txt at http://www.pozo.com/kernel/kdump.txt <http://www.pozo.com/kernel/kdump.txt> > > also i???ll put a copy of my kernel config in same directory: > > http://www.pozo.com/kernel/pozo <http://www.pozo.com/kernel/pozo> > > only one module is being loaded at boot: > (kernel)4908}kldstat > Id Refs Address Size Name > 1 5 0xffffffff80200000 10380a8 kernel > 2 1 0xffffffff8123a000 e13f50 nvidia.ko > > I can disable nvidia if it helps as I really only access this machine over the net or serial console. > 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. 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. https://people.freebsd.org/~kib/misc/vm2.2.patchReceived on Sun Jun 25 2017 - 14:41:22 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:12 UTC