Re: Current amd64 new error or warning from today's current with ruby r320323

[Benjamin Kaduk]

On Tue, Jun 27, 2017 at 1:56 PM, Trond Endrestøl <
trond.endres...@fagskolen.gjovik.no> wrote:

> On Tue, 27 Jun 2017 20:28+0200, Trond Endrestøl wrote:
>
> > On Sun, 25 Jun 2017 22:05+0300, Konstantin Belousov wrote:
> >
> > > On Sun, Jun 25, 2017 at 08:51:07PM +0200, Trond Endrest?l wrote:
> > > > > https://people.freebsd.org/~kib/misc/vm2.2.patch
> > > >
> > > > This patch made ruby23 happy on my end. Can't say the same for
> > > > emacs-nox11 or temacs while building the former.
> > >
> > > What exactly do you mean ?  Explain the behaviour and show the ktrace
> log.
> >
> > It builds now.
> >
> > I'm running unpatched r320406, and I'll attempt building and running
> > r320420 with your patch from yesterday.
> >
> > I too suffer from /sbin/zfs' inability to run in singleuser mode, yet
> > somehow it does its job while in multiuser mode.
>
> That patch enables /sbin/zfs to run in singleuser mode.
>
> Next, there seems to be a race condition while running installworld in
> parallel, but that's a story for another time.
>
>
Sorry for the slow reply; I didn't get a usable update window right away.

At r320458 I am not seeing any issues.

-Ben
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Current amd64 new error or warning from today's current with ruby r320323

[Trond Endrestøl]

On Tue, 27 Jun 2017 20:28+0200, Trond Endrestøl wrote:

> On Sun, 25 Jun 2017 22:05+0300, Konstantin Belousov wrote:
> 
> > On Sun, Jun 25, 2017 at 08:51:07PM +0200, Trond Endrest?l wrote:
> > > > https://people.freebsd.org/~kib/misc/vm2.2.patch
> > > 
> > > This patch made ruby23 happy on my end. Can't say the same for 
> > > emacs-nox11 or temacs while building the former.
> > 
> > What exactly do you mean ?  Explain the behaviour and show the ktrace log.
> 
> It builds now.
> 
> I'm running unpatched r320406, and I'll attempt building and running 
> r320420 with your patch from yesterday.
> 
> I too suffer from /sbin/zfs' inability to run in singleuser mode, yet 
> somehow it does its job while in multiuser mode.

That patch enables /sbin/zfs to run in singleuser mode.

Next, there seems to be a race condition while running installworld in 
parallel, but that's a story for another time.

-- 
Trond.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Current amd64 new error or warning from today's current with ruby r320323

[Trond Endrestøl]

On Sun, 25 Jun 2017 22:05+0300, Konstantin Belousov wrote:

> On Sun, Jun 25, 2017 at 08:51:07PM +0200, Trond Endrest?l wrote:
> > > https://people.freebsd.org/~kib/misc/vm2.2.patch
> > 
> > This patch made ruby23 happy on my end. Can't say the same for 
> > emacs-nox11 or temacs while building the former.
> 
> What exactly do you mean ?  Explain the behaviour and show the ktrace log.

It builds now.

I'm running unpatched r320406, and I'll attempt building and running 
r320420 with your patch from yesterday.

I too suffer from /sbin/zfs's inability to run in singleuser mode, yet 
somehow it does its job while in multiuser mode.

-- 
Trond.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Current amd64 new error or warning from today's current with ruby r320323

[Konstantin Belousov]

On Mon, Jun 26, 2017 at 01:34:35PM -0700, Benno Rice wrote:
> 
> > On Jun 26, 2017, at 13:25, Konstantin Belousov  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 
> >> wrote:
> >> 
> >>> 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.patch
> >>> 
> >>> 
> >> 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  
> 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 = 12)
> Abort trap (core dumped)
> 
> I booted into single-user and ran zfs under ktrace and I???ve 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

Try this.  Even if it helps, the patch is being actively discussed and
may be not in its final form.

diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c
index 7b4a86dffd8..2766454d825 100644
--- a/sys/vm/vm_map.c
+++ b/sys/vm/vm_map.c
@@ -1556,6 +1556,25 @@ again:
return (result);
 }
 
+int
+vm_map_find_min(vm_map_t map, vm_object_t object, vm_ooffset_t offset,
+vm_offset_t *addr, vm_size_t length, vm_offset_t min_addr,
+vm_offset_t max_addr, int find_space, vm_prot_t prot, vm_prot_t max,
+int cow)
+{
+   vm_offset_t hint;
+   int rv;
+
+   hint = *addr;
+   for (;;) {
+   rv = vm_map_find(map, object, offset, addr, length, max_addr,
+   find_space, prot, max, cow);
+   if (rv == KERN_SUCCESS || hint == 0 || min_addr >= hint)
+   return (rv);
+   *addr = min_addr;
+   }
+}
+
 /*
  * vm_map_simplify_entry:
  *
diff --git a/sys/vm/vm_map.h b/sys/vm/vm_map.h
index 2c89e1d73d4..78f3f31c226 100644
--- a/sys/vm/vm_map.h
+++ b/sys/vm/vm_map.h
@@ -372,6 +372,8 @@ vm_map_t vm_map_create(pmap_t, vm_offset_t, vm_offset_t);
 int vm_map_delete(vm_map_t, vm_offset_t, vm_offset_t);
 int vm_map_find(vm_map_t, vm_object_t, vm_ooffset_t, vm_offset_t *, vm_size_t,
 vm_offset_t, int, vm_prot_t, vm_prot_t, int);
+int vm_map_find_min(vm_map_t, vm_object_t, vm_ooffset_t, vm_offset_t *,
+vm_size_t, vm_offset_t, vm_offset_t, int, vm_prot_t, vm_prot_t, int);
 int vm_map_fixed(vm_map_t, vm_object_t, vm_ooffset_t, vm_offset_t, vm_size_t,
 vm_prot_t, vm_prot_t, int);
 int vm_map_findspace (vm_map_t, vm_offset_t, vm_size_t, vm_offset_t *);
diff --git a/sys/vm/vm_mmap.c b/sys/vm/vm_mmap.c
index 4d8f6ad9ed7..24360d422e3 100644
--- a/sys/vm/vm_mmap.c
+++ b/sys/vm/vm_mmap.c
@@ -1438,10 +1439,12 @@ vm_mmap_object(vm_map_t map, vm_offset_t *addr, 
vm_size_t size, vm_prot_t prot,
 vm_prot_t maxprot, int flags, vm_object_t object, vm_ooffset_t foff,
 boolean_t writecounted, struct thread *td)
 {
-   boolean_t fitit;
+   boolean_t curmap, fitit;
+   vm_offset_t max_addr;
int docow, error, findspace, rv;
 
-   if (map == &td->td_proc->p_vmspace->vm_map) {
+   curmap = map == &td->td_proc->p_vmspace->vm_map;
+   if (curmap) {
PROC_LOCK(td->td_proc);
if (map->size + size > lim_cur_proc(td->td_proc, RLIMIT_VMEM)) {
PROC_UNLOCK(td->td_proc);
@@ -1529,11 +1532,20 @@ vm_mmap_object(vm_map_t map, vm_offset_t *addr, 
vm_size_t size, vm_prot_t prot,
MAP_ALIGNMENT_SHIFT);
else
findspace = VMFS_OPTIMAL_SPACE;
-   rv = vm_map_find(map, object, foff, addr, size,
+   max_addr = 0;
 #ifdef MAP_32BIT
-   flags & MAP_32BIT ? MAP_32BIT_MAX_ADDR :
+   if ((flag

Re: Current amd64 new error or warning from today's current with ruby r320323

[Benno Rice]

> On Jun 26, 2017, at 13:25, Konstantin Belousov  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 
>> wrote:
>> 
>>> 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.patch
>>> 
>>> 
>> 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  
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 = 12)
Abort trap (core dumped)

I booted into single-user and ran zfs under ktrace and I’ve 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
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Current amd64 new error or warning from today's current with ruby r320323

[Konstantin Belousov]

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:
> 
> > 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.patch
> >
> >
> 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.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Current amd64 new error or warning from today's current with ruby r320323

[Benjamin Kaduk]

On Sun, Jun 25, 2017 at 11:41 AM, Konstantin Belousov 
wrote:

> 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.patch
>
>
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?

-Ben
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Current amd64 new error or warning from today's current with ruby r320323

[Konstantin Belousov]

On Sun, Jun 25, 2017 at 08:51:07PM +0200, Trond Endrest?l wrote:
> > https://people.freebsd.org/~kib/misc/vm2.2.patch
> 
> This patch made ruby23 happy on my end. Can't say the same for 
> emacs-nox11 or temacs while building the former.

What exactly do you mean ?  Explain the behaviour and show the ktrace log.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Current amd64 new error or warning from today's current with ruby r320323

[Trond Endrestøl]

On Sun, 25 Jun 2017 19:41+0300, Konstantin Belousov wrote:

> On Sun, Jun 25, 2017 at 08:21:33AM -0700, Manfred Antar wrote:
> > 
> > > On Jun 25, 2017, at 7:50 AM, Konstantin Belousov  
> > > 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  > >> patch
> > >> 
> > >> you could cc r...@pozo.com  , that way i have copy 
> > >> on freebsd box and on mac.
> > > 
> > > 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 
> > 
> > 
> > also i???ll put a copy of my kernel config in same directory:
> > 
> > http://www.pozo.com/kernel/pozo 
> > 
> > only one module is being loaded at boot:
> > (kernel)4908}kldstat
> > Id Refs AddressSize Name
> >  15 0x8020 10380a8  kernel
> >  21 0x8123a000 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.patch

This patch made ruby23 happy on my end. Can't say the same for 
emacs-nox11 or temacs while building the former.

-- 
+---++
| Vennlig hilsen,   | Best regards,  |
| Trond Endrestøl,  | Trond Endrestøl,   |
| IT-ansvarlig, | System administrator,  |
| Fagskolen Innlandet,  | Gjøvik Technical College, Norway,  |
| tlf. mob.   952 62 567,   | Cellular...: +47 952 62 567,   |
| sentralbord 61 14 54 00.  | Switchboard: +47 61 14 54 00.  |
+---++
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Current amd64 new error or warning from today's current with ruby r320323

[Manfred Antar]

> On Jun 25, 2017, at 10:21 AM, Konstantin Belousov  wrote:
> 
> On Sun, Jun 25, 2017 at 10:09:07AM -0700, Manfred Antar wrote:
>> 
>>> On Jun 25, 2017, at 9:41 AM, Konstantin Belousov  
>>> wrote:
>>> 
>>> On Sun, Jun 25, 2017 at 08:21:33AM -0700, Manfred Antar wrote:
 
> On Jun 25, 2017, at 7:50 AM, Konstantin Belousov  
> 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 > patch
>> 
>> you could cc r...@pozo.com  , that way i have copy 
>> on freebsd box and on mac.
> 
> 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 
 
 
 also i???ll put a copy of my kernel config in same directory:
 
 http://www.pozo.com/kernel/pozo 
 
 only one module is being loaded at boot:
 (kernel)4908}kldstat
 Id Refs AddressSize Name
 15 0x8020 10380a8  kernel
 21 0x8123a000 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.patch
>> 
>> Seems to have worked:
>> 
>> (~)4933}ruby -v
>> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12]
>> (~)4934}
>> 
>> No more message. Do you want new ktrace ?
> 
> Thanks for testing.  You might post the trace.

New trace at :

http://www.pozo.com/kernel/kdump-working.txt 


Thanks
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Current amd64 new error or warning from today's current with ruby r320323

[Konstantin Belousov]

On Sun, Jun 25, 2017 at 10:09:07AM -0700, Manfred Antar wrote:
> 
> > On Jun 25, 2017, at 9:41 AM, Konstantin Belousov  
> > wrote:
> > 
> > On Sun, Jun 25, 2017 at 08:21:33AM -0700, Manfred Antar wrote:
> >> 
> >>> On Jun 25, 2017, at 7:50 AM, Konstantin Belousov  
> >>> 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   patch
>  
>  you could cc r...@pozo.com  , that way i have copy 
>  on freebsd box and on mac.
> >>> 
> >>> 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 
> >> 
> >> 
> >> also i???ll put a copy of my kernel config in same directory:
> >> 
> >> http://www.pozo.com/kernel/pozo 
> >> 
> >> only one module is being loaded at boot:
> >> (kernel)4908}kldstat
> >> Id Refs AddressSize Name
> >> 15 0x8020 10380a8  kernel
> >> 21 0x8123a000 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.patch
> 
> Seems to have worked:
> 
> (~)4933}ruby -v
> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12]
> (~)4934}
> 
> No more message. Do you want new ktrace ?

Thanks for testing.  You might post the trace.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Current amd64 new error or warning from today's current with ruby r320323

[Manfred Antar]

> On Jun 25, 2017, at 9:41 AM, Konstantin Belousov  wrote:
> 
> On Sun, Jun 25, 2017 at 08:21:33AM -0700, Manfred Antar wrote:
>> 
>>> On Jun 25, 2017, at 7:50 AM, Konstantin Belousov  
>>> 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 >>> patch
 
 you could cc r...@pozo.com  , that way i have copy 
 on freebsd box and on mac.
>>> 
>>> 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 
>> 
>> 
>> also i???ll put a copy of my kernel config in same directory:
>> 
>> http://www.pozo.com/kernel/pozo 
>> 
>> only one module is being loaded at boot:
>> (kernel)4908}kldstat
>> Id Refs AddressSize Name
>> 15 0x8020 10380a8  kernel
>> 21 0x8123a000 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.patch

Seems to have worked:

(~)4933}ruby -v
ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12]
(~)4934}

No more message. Do you want new ktrace ?

Thanks
Manfred
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Current amd64 new error or warning from today's current with ruby r320323

[Konstantin Belousov]

On Sun, Jun 25, 2017 at 08:21:33AM -0700, Manfred Antar wrote:
> 
> > On Jun 25, 2017, at 7:50 AM, Konstantin Belousov  
> > 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  >> patch
> >> 
> >> you could cc r...@pozo.com  , that way i have copy 
> >> on freebsd box and on mac.
> > 
> > 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 
> 
> 
> also i???ll put a copy of my kernel config in same directory:
> 
> http://www.pozo.com/kernel/pozo 
> 
> only one module is being loaded at boot:
> (kernel)4908}kldstat
> Id Refs AddressSize Name
>  15 0x8020 10380a8  kernel
>  21 0x8123a000 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.patch
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Current amd64 new error or warning from today's current with ruby r320323

[Trond Endrestøl]

On Sun, 25 Jun 2017 18:08+0200, Trond Endrestøl wrote:

> On Sun, 25 Jun 2017 17:56+0200, Trond Endrestøl wrote:
> 
> > On Sun, 25 Jun 2017 17:18+0200, Trond Endrestøl wrote:
> > 
> > > On Sun, 25 Jun 2017 16:41+0300, Konstantin Belousov wrote:
> > > 
> > > > On Sat, Jun 24, 2017 at 07:19:25PM -0700, Manfred Antar wrote:
> > > > > 
> > > > > > On Jun 24, 2017, at 7:04 PM, Konstantin Belousov 
> > > > > >  wrote:
> > > > > > 
> > > > > > On Sat, Jun 24, 2017 at 06:48:03PM -0700, Manfred Antar wrote:
> > > > > >> 
> > > > > >>> On Jun 24, 2017, at 6:23 PM, Konstantin Belousov 
> > > > > >>>  wrote:
> > > > > >>> 
> > > > > >>> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote:
> > > > >  New world and kernel  r320323
> > > > >  I get a new error or message when using ruby:
> > > > >  
> > > > >  
> > > > >  /usr/local/sbin/portupgrade -av
> > > > >  : warning: pthread_create failed for timer: Resource 
> > > > >  temporarily unavailable, scheduling broken
> > > > >  
> > > > >  everything works just this message when using ruby. I recompiled 
> > > > >  ruby , still same message
> > > > >  
> > > > >  /usr/local/bin/ruby -v
> > > > >  : warning: pthread_create failed for timer: Resource 
> > > > >  temporarily unavailable, scheduling broken
> > > > >  ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12]
> > > > >  
> > > > >  Not sure what???s changed, I noticed some commits to vm stuff, 
> > > > >  maybe thats it.
> > > > > >>> 
> > > > > >>> ktrace your failing ruby invocation, then post output of kdump -H 
> > > > > >>> somewhere.
> > > > > >>> 
> > > > > >> 
> > > > > >> Ok not sure  if this is right , but this is what i did:
> > > > > >> 
> > > > > >> (tmp)4637}ktrace /usr/local/bin/ruby -v
> > > > > >> : warning: pthread_create failed for timer: Resource 
> > > > > >> temporarily unavailable, scheduling broken
> > > > > >> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12]
> > > > > >> 
> > > > > >> (tmp)4638}kdump -H -f ./ktrace.out >  kdump.txt
> > > > > >> 
> > > > > >> you can get kdump.txt at:
> > > > > >> 
> > > > > >> http://www.pozo.com/kernel/kdump 
> > > > > >> .txt
> > > > > >> 
> > > > > >> It???s not failing, I don???t think , I can do portupgrade and it 
> > > > > >> works fine.
> > > > > >> I just get this new message
> > > > > > 
> > > > > > I see what is going on, but it is somewhat strange that it happens.
> > > > > > 
> > > > > > Do you run ruby in a jail with old (say, stable/10) libthr ?
> > > > > > Or do you have environment variable LIBPTHREAD_SPLITSTACK_MAIN set 
> > > > > > in
> > > > > > your environment ?
> > > > > > 
> > > > > > Anyway, the rework of the stack grow indeed have incompatibility 
> > > > > > with the
> > > > > > old (pre-11) libthr, which tries to split main thread stack into 
> > > > > > smaller
> > > > > > stacks for the new threads.  New stack grow code was specifically 
> > > > > > designed
> > > > > > to prevent this.  Some hack would be needed there, to allow reuse of
> > > > > > the main stack gap.
> > > > > > 
> > > > > 
> > > > > Not running any jails
> > > > > all libraries are current as of today
> > > > > locate libthr. |xargs ls -l
> > > > > -r--r--r--  1 root  wheel  120240 Jun 24 12:50 /lib/libthr.so.3
> > > > > -r--r--r--  1 root  wheel  256072 Jun 24 12:50 /usr/lib/libthr.a
> > > > > lrwxr-xr-x  1 root  wheel  21 Jun 24 12:50 /usr/lib/libthr.so -> 
> > > > > ../../lib/libthr.so.3
> > > > > 
> > > > > ldd /usr/local/bin/ruby
> > > > > -rwxr-xr-x  1 root  wheel  2677552 Jun 24 18:22 
> > > > > /usr/local/lib/libruby23.so.2
> > > > > -rwxr-xr-x  1 root  wheel  43832 Jun 24 19:10 
> > > > > /usr/local/lib/libunwind.so.8.0.1
> > > > > 
> > > > > /usr/local/bin/ruby:
> > > > >   libruby23.so.23 => /usr/local/lib/libruby23.so.23 (0x800a0)
> > > > >   libelf.so.2 => /lib/libelf.so.2 (0x800e9d000)
> > > > >   libunwind.so.8 => /usr/local/lib/libunwind.so.8 (0x8010b5000)
> > > > >   libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x8012ce000)
> > > > >   libprocstat.so.1 => /usr/lib/libprocstat.so.1 (0x8014d1000)
> > > > >   libcrypt.so.5 => /lib/libcrypt.so.5 (0x8016db000)
> > > > >   libm.so.5 => /lib/libm.so.5 (0x8018f9000)
> > > > >   libthr.so.3 => /lib/libthr.so.3 (0x801b26000)
> > > > >   libc.so.7 => /lib/libc.so.7 (0x801d4e000)
> > > > >   libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x802335000)
> > > > >   liblzma.so.5 => /usr/lib/liblzma.so.5 (0x80254b000)
> > > > >   libkvm.so.7 => /lib/libkvm.so.7 (0x802774000)
> > > > >   libutil.so.9 => /lib/libutil.so.9 (0x802982000)
> > > > > 
> > > > > no LIBPTHREAD_SPLITSTACK_MAIN set anywhere
> > > > > 
> > > > > This is a fresh buildworld - installworld from noon today California 
> > > > > time.
> > > > > 
> > > > > here are env in make.conf:
> > > > > DEFAULT_VERSIONS= mysql=5.7 apache=2.4 python2=2.7 python3=3.4 

Re: Current amd64 new error or warning from today's current with ruby r320323

[Trond Endrestøl]

On Sun, 25 Jun 2017 17:56+0200, Trond Endrestøl wrote:

> On Sun, 25 Jun 2017 17:18+0200, Trond Endrestøl wrote:
> 
> > On Sun, 25 Jun 2017 16:41+0300, Konstantin Belousov wrote:
> > 
> > > On Sat, Jun 24, 2017 at 07:19:25PM -0700, Manfred Antar wrote:
> > > > 
> > > > > On Jun 24, 2017, at 7:04 PM, Konstantin Belousov 
> > > > >  wrote:
> > > > > 
> > > > > On Sat, Jun 24, 2017 at 06:48:03PM -0700, Manfred Antar wrote:
> > > > >> 
> > > > >>> On Jun 24, 2017, at 6:23 PM, Konstantin Belousov 
> > > > >>>  wrote:
> > > > >>> 
> > > > >>> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote:
> > > >  New world and kernel  r320323
> > > >  I get a new error or message when using ruby:
> > > >  
> > > >  
> > > >  /usr/local/sbin/portupgrade -av
> > > >  : warning: pthread_create failed for timer: Resource 
> > > >  temporarily unavailable, scheduling broken
> > > >  
> > > >  everything works just this message when using ruby. I recompiled 
> > > >  ruby , still same message
> > > >  
> > > >  /usr/local/bin/ruby -v
> > > >  : warning: pthread_create failed for timer: Resource 
> > > >  temporarily unavailable, scheduling broken
> > > >  ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12]
> > > >  
> > > >  Not sure what???s changed, I noticed some commits to vm stuff, 
> > > >  maybe thats it.
> > > > >>> 
> > > > >>> ktrace your failing ruby invocation, then post output of kdump -H 
> > > > >>> somewhere.
> > > > >>> 
> > > > >> 
> > > > >> Ok not sure  if this is right , but this is what i did:
> > > > >> 
> > > > >> (tmp)4637}ktrace /usr/local/bin/ruby -v
> > > > >> : warning: pthread_create failed for timer: Resource 
> > > > >> temporarily unavailable, scheduling broken
> > > > >> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12]
> > > > >> 
> > > > >> (tmp)4638}kdump -H -f ./ktrace.out >  kdump.txt
> > > > >> 
> > > > >> you can get kdump.txt at:
> > > > >> 
> > > > >> http://www.pozo.com/kernel/kdump 
> > > > >> .txt
> > > > >> 
> > > > >> It???s not failing, I don???t think , I can do portupgrade and it 
> > > > >> works fine.
> > > > >> I just get this new message
> > > > > 
> > > > > I see what is going on, but it is somewhat strange that it happens.
> > > > > 
> > > > > Do you run ruby in a jail with old (say, stable/10) libthr ?
> > > > > Or do you have environment variable LIBPTHREAD_SPLITSTACK_MAIN set in
> > > > > your environment ?
> > > > > 
> > > > > Anyway, the rework of the stack grow indeed have incompatibility with 
> > > > > the
> > > > > old (pre-11) libthr, which tries to split main thread stack into 
> > > > > smaller
> > > > > stacks for the new threads.  New stack grow code was specifically 
> > > > > designed
> > > > > to prevent this.  Some hack would be needed there, to allow reuse of
> > > > > the main stack gap.
> > > > > 
> > > > 
> > > > Not running any jails
> > > > all libraries are current as of today
> > > > locate libthr. |xargs ls -l
> > > > -r--r--r--  1 root  wheel  120240 Jun 24 12:50 /lib/libthr.so.3
> > > > -r--r--r--  1 root  wheel  256072 Jun 24 12:50 /usr/lib/libthr.a
> > > > lrwxr-xr-x  1 root  wheel  21 Jun 24 12:50 /usr/lib/libthr.so -> 
> > > > ../../lib/libthr.so.3
> > > > 
> > > > ldd /usr/local/bin/ruby
> > > > -rwxr-xr-x  1 root  wheel  2677552 Jun 24 18:22 
> > > > /usr/local/lib/libruby23.so.2
> > > > -rwxr-xr-x  1 root  wheel  43832 Jun 24 19:10 
> > > > /usr/local/lib/libunwind.so.8.0.1
> > > > 
> > > > /usr/local/bin/ruby:
> > > > libruby23.so.23 => /usr/local/lib/libruby23.so.23 (0x800a0)
> > > > libelf.so.2 => /lib/libelf.so.2 (0x800e9d000)
> > > > libunwind.so.8 => /usr/local/lib/libunwind.so.8 (0x8010b5000)
> > > > libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x8012ce000)
> > > > libprocstat.so.1 => /usr/lib/libprocstat.so.1 (0x8014d1000)
> > > > libcrypt.so.5 => /lib/libcrypt.so.5 (0x8016db000)
> > > > libm.so.5 => /lib/libm.so.5 (0x8018f9000)
> > > > libthr.so.3 => /lib/libthr.so.3 (0x801b26000)
> > > > libc.so.7 => /lib/libc.so.7 (0x801d4e000)
> > > > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x802335000)
> > > > liblzma.so.5 => /usr/lib/liblzma.so.5 (0x80254b000)
> > > > libkvm.so.7 => /lib/libkvm.so.7 (0x802774000)
> > > > libutil.so.9 => /lib/libutil.so.9 (0x802982000)
> > > > 
> > > > no LIBPTHREAD_SPLITSTACK_MAIN set anywhere
> > > > 
> > > > This is a fresh buildworld - installworld from noon today California 
> > > > time.
> > > > 
> > > > here are env in make.conf:
> > > > DEFAULT_VERSIONS= mysql=5.7 apache=2.4 python2=2.7 python3=3.4 ruby=2.3 
> > > > perl5=5.24 php=5.6 tcltk=8.6 samba=4.4 ssl=base ncurses=base
> > > > MALLOC_PRODUCTION=yes
> > > > WITH_BDB_VERSION=5
> > > > 
> > > > env in src.conf:
> > > > WITHOUT_DYNAMICROOT=yes 
> > > > WITHOUT_UNBOUND=yes
> > > > WITHOUT_CASPER=yes
> > >

Re: Current amd64 new error or warning from today's current with ruby r320323

[Trond Endrestøl]

On Sun, 25 Jun 2017 17:18+0200, Trond Endrestøl wrote:

> On Sun, 25 Jun 2017 16:41+0300, Konstantin Belousov wrote:
> 
> > On Sat, Jun 24, 2017 at 07:19:25PM -0700, Manfred Antar wrote:
> > > 
> > > > On Jun 24, 2017, at 7:04 PM, Konstantin Belousov  
> > > > wrote:
> > > > 
> > > > On Sat, Jun 24, 2017 at 06:48:03PM -0700, Manfred Antar wrote:
> > > >> 
> > > >>> On Jun 24, 2017, at 6:23 PM, Konstantin Belousov 
> > > >>>  wrote:
> > > >>> 
> > > >>> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote:
> > >  New world and kernel  r320323
> > >  I get a new error or message when using ruby:
> > >  
> > >  
> > >  /usr/local/sbin/portupgrade -av
> > >  : warning: pthread_create failed for timer: Resource 
> > >  temporarily unavailable, scheduling broken
> > >  
> > >  everything works just this message when using ruby. I recompiled 
> > >  ruby , still same message
> > >  
> > >  /usr/local/bin/ruby -v
> > >  : warning: pthread_create failed for timer: Resource 
> > >  temporarily unavailable, scheduling broken
> > >  ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12]
> > >  
> > >  Not sure what???s changed, I noticed some commits to vm stuff, maybe 
> > >  thats it.
> > > >>> 
> > > >>> ktrace your failing ruby invocation, then post output of kdump -H 
> > > >>> somewhere.
> > > >>> 
> > > >> 
> > > >> Ok not sure  if this is right , but this is what i did:
> > > >> 
> > > >> (tmp)4637}ktrace /usr/local/bin/ruby -v
> > > >> : warning: pthread_create failed for timer: Resource temporarily 
> > > >> unavailable, scheduling broken
> > > >> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12]
> > > >> 
> > > >> (tmp)4638}kdump -H -f ./ktrace.out >  kdump.txt
> > > >> 
> > > >> you can get kdump.txt at:
> > > >> 
> > > >> http://www.pozo.com/kernel/kdump .txt
> > > >> 
> > > >> It???s not failing, I don???t think , I can do portupgrade and it 
> > > >> works fine.
> > > >> I just get this new message
> > > > 
> > > > I see what is going on, but it is somewhat strange that it happens.
> > > > 
> > > > Do you run ruby in a jail with old (say, stable/10) libthr ?
> > > > Or do you have environment variable LIBPTHREAD_SPLITSTACK_MAIN set in
> > > > your environment ?
> > > > 
> > > > Anyway, the rework of the stack grow indeed have incompatibility with 
> > > > the
> > > > old (pre-11) libthr, which tries to split main thread stack into smaller
> > > > stacks for the new threads.  New stack grow code was specifically 
> > > > designed
> > > > to prevent this.  Some hack would be needed there, to allow reuse of
> > > > the main stack gap.
> > > > 
> > > 
> > > Not running any jails
> > > all libraries are current as of today
> > > locate libthr. |xargs ls -l
> > > -r--r--r--  1 root  wheel  120240 Jun 24 12:50 /lib/libthr.so.3
> > > -r--r--r--  1 root  wheel  256072 Jun 24 12:50 /usr/lib/libthr.a
> > > lrwxr-xr-x  1 root  wheel  21 Jun 24 12:50 /usr/lib/libthr.so -> 
> > > ../../lib/libthr.so.3
> > > 
> > > ldd /usr/local/bin/ruby
> > > -rwxr-xr-x  1 root  wheel  2677552 Jun 24 18:22 
> > > /usr/local/lib/libruby23.so.2
> > > -rwxr-xr-x  1 root  wheel  43832 Jun 24 19:10 
> > > /usr/local/lib/libunwind.so.8.0.1
> > > 
> > > /usr/local/bin/ruby:
> > >   libruby23.so.23 => /usr/local/lib/libruby23.so.23 (0x800a0)
> > >   libelf.so.2 => /lib/libelf.so.2 (0x800e9d000)
> > >   libunwind.so.8 => /usr/local/lib/libunwind.so.8 (0x8010b5000)
> > >   libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x8012ce000)
> > >   libprocstat.so.1 => /usr/lib/libprocstat.so.1 (0x8014d1000)
> > >   libcrypt.so.5 => /lib/libcrypt.so.5 (0x8016db000)
> > >   libm.so.5 => /lib/libm.so.5 (0x8018f9000)
> > >   libthr.so.3 => /lib/libthr.so.3 (0x801b26000)
> > >   libc.so.7 => /lib/libc.so.7 (0x801d4e000)
> > >   libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x802335000)
> > >   liblzma.so.5 => /usr/lib/liblzma.so.5 (0x80254b000)
> > >   libkvm.so.7 => /lib/libkvm.so.7 (0x802774000)
> > >   libutil.so.9 => /lib/libutil.so.9 (0x802982000)
> > > 
> > > no LIBPTHREAD_SPLITSTACK_MAIN set anywhere
> > > 
> > > This is a fresh buildworld - installworld from noon today California time.
> > > 
> > > here are env in make.conf:
> > > DEFAULT_VERSIONS= mysql=5.7 apache=2.4 python2=2.7 python3=3.4 ruby=2.3 
> > > perl5=5.24 php=5.6 tcltk=8.6 samba=4.4 ssl=base ncurses=base
> > > MALLOC_PRODUCTION=yes
> > > WITH_BDB_VERSION=5
> > > 
> > > env in src.conf:
> > > WITHOUT_DYNAMICROOT=yes 
> > > WITHOUT_UNBOUND=yes
> > > WITHOUT_CASPER=yes
> > > WITHOUT_CAPSICUM=yes
> > > WITHOUT_DMAGENT=yes
> > > WITHOUT_PROFILE=yes
> > > WITHOUT_TESTS=yes
> > > WITHOUT_KERNEL_SYMBOLS=yes
> > > WITHOUT_DEBUG_FILES=1
> > > WITHOUT_LIB32=yes
> > > INSTALL_NODEBUG=yes
> > > 
> > > # Don't die on warnings
> > > NO_WERROR=
> > > WERROR=
> > > KERNCONF=pozo
> > > WITH_CCACHE_BUILD=yes
> > 
> > Weird, I do not see where such behaviour could come from. 

Re: Current amd64 new error or warning from today's current with ruby r320323

[Trond Endrestøl]

On Sun, 25 Jun 2017 16:41+0300, Konstantin Belousov wrote:

> On Sat, Jun 24, 2017 at 07:19:25PM -0700, Manfred Antar wrote:
> > 
> > > On Jun 24, 2017, at 7:04 PM, Konstantin Belousov  
> > > wrote:
> > > 
> > > On Sat, Jun 24, 2017 at 06:48:03PM -0700, Manfred Antar wrote:
> > >> 
> > >>> On Jun 24, 2017, at 6:23 PM, Konstantin Belousov  
> > >>> wrote:
> > >>> 
> > >>> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote:
> >  New world and kernel  r320323
> >  I get a new error or message when using ruby:
> >  
> >  
> >  /usr/local/sbin/portupgrade -av
> >  : warning: pthread_create failed for timer: Resource temporarily 
> >  unavailable, scheduling broken
> >  
> >  everything works just this message when using ruby. I recompiled ruby 
> >  , still same message
> >  
> >  /usr/local/bin/ruby -v
> >  : warning: pthread_create failed for timer: Resource temporarily 
> >  unavailable, scheduling broken
> >  ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12]
> >  
> >  Not sure what???s changed, I noticed some commits to vm stuff, maybe 
> >  thats it.
> > >>> 
> > >>> ktrace your failing ruby invocation, then post output of kdump -H 
> > >>> somewhere.
> > >>> 
> > >> 
> > >> Ok not sure  if this is right , but this is what i did:
> > >> 
> > >> (tmp)4637}ktrace /usr/local/bin/ruby -v
> > >> : warning: pthread_create failed for timer: Resource temporarily 
> > >> unavailable, scheduling broken
> > >> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12]
> > >> 
> > >> (tmp)4638}kdump -H -f ./ktrace.out >  kdump.txt
> > >> 
> > >> you can get kdump.txt at:
> > >> 
> > >> http://www.pozo.com/kernel/kdump .txt
> > >> 
> > >> It???s not failing, I don???t think , I can do portupgrade and it works 
> > >> fine.
> > >> I just get this new message
> > > 
> > > I see what is going on, but it is somewhat strange that it happens.
> > > 
> > > Do you run ruby in a jail with old (say, stable/10) libthr ?
> > > Or do you have environment variable LIBPTHREAD_SPLITSTACK_MAIN set in
> > > your environment ?
> > > 
> > > Anyway, the rework of the stack grow indeed have incompatibility with the
> > > old (pre-11) libthr, which tries to split main thread stack into smaller
> > > stacks for the new threads.  New stack grow code was specifically designed
> > > to prevent this.  Some hack would be needed there, to allow reuse of
> > > the main stack gap.
> > > 
> > 
> > Not running any jails
> > all libraries are current as of today
> > locate libthr. |xargs ls -l
> > -r--r--r--  1 root  wheel  120240 Jun 24 12:50 /lib/libthr.so.3
> > -r--r--r--  1 root  wheel  256072 Jun 24 12:50 /usr/lib/libthr.a
> > lrwxr-xr-x  1 root  wheel  21 Jun 24 12:50 /usr/lib/libthr.so -> 
> > ../../lib/libthr.so.3
> > 
> > ldd /usr/local/bin/ruby
> > -rwxr-xr-x  1 root  wheel  2677552 Jun 24 18:22 
> > /usr/local/lib/libruby23.so.2
> > -rwxr-xr-x  1 root  wheel  43832 Jun 24 19:10 
> > /usr/local/lib/libunwind.so.8.0.1
> > 
> > /usr/local/bin/ruby:
> > libruby23.so.23 => /usr/local/lib/libruby23.so.23 (0x800a0)
> > libelf.so.2 => /lib/libelf.so.2 (0x800e9d000)
> > libunwind.so.8 => /usr/local/lib/libunwind.so.8 (0x8010b5000)
> > libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x8012ce000)
> > libprocstat.so.1 => /usr/lib/libprocstat.so.1 (0x8014d1000)
> > libcrypt.so.5 => /lib/libcrypt.so.5 (0x8016db000)
> > libm.so.5 => /lib/libm.so.5 (0x8018f9000)
> > libthr.so.3 => /lib/libthr.so.3 (0x801b26000)
> > libc.so.7 => /lib/libc.so.7 (0x801d4e000)
> > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x802335000)
> > liblzma.so.5 => /usr/lib/liblzma.so.5 (0x80254b000)
> > libkvm.so.7 => /lib/libkvm.so.7 (0x802774000)
> > libutil.so.9 => /lib/libutil.so.9 (0x802982000)
> > 
> > no LIBPTHREAD_SPLITSTACK_MAIN set anywhere
> > 
> > This is a fresh buildworld - installworld from noon today California time.
> > 
> > here are env in make.conf:
> > DEFAULT_VERSIONS= mysql=5.7 apache=2.4 python2=2.7 python3=3.4 ruby=2.3 
> > perl5=5.24 php=5.6 tcltk=8.6 samba=4.4 ssl=base ncurses=base
> > MALLOC_PRODUCTION=yes
> > WITH_BDB_VERSION=5
> > 
> > env in src.conf:
> > WITHOUT_DYNAMICROOT=yes 
> > WITHOUT_UNBOUND=yes
> > WITHOUT_CASPER=yes
> > WITHOUT_CAPSICUM=yes
> > WITHOUT_DMAGENT=yes
> > WITHOUT_PROFILE=yes
> > WITHOUT_TESTS=yes
> > WITHOUT_KERNEL_SYMBOLS=yes
> > WITHOUT_DEBUG_FILES=1
> > WITHOUT_LIB32=yes
> > INSTALL_NODEBUG=yes
> > 
> > # Don't die on warnings
> > NO_WERROR=
> > WERROR=
> > KERNCONF=pozo
> > WITH_CCACHE_BUILD=yes
> 
> Weird, I do not see where such behaviour could come from.  I mean,
> the behaviour of the libthr, assuming that the failing call is from
> libthr and not from the ruby.
> 
> Anyway, please try the following.  Note that this might be not the final
> fix, but I am interesting in seeing whether it fixed the issue for you.
> I want to see the kdump output fr

Re: Current amd64 new error or warning from today's current with ruby r320323

[Konstantin Belousov]

On Sat, Jun 24, 2017 at 07:19:25PM -0700, Manfred Antar wrote:
> 
> > On Jun 24, 2017, at 7:04 PM, Konstantin Belousov  
> > wrote:
> > 
> > On Sat, Jun 24, 2017 at 06:48:03PM -0700, Manfred Antar wrote:
> >> 
> >>> On Jun 24, 2017, at 6:23 PM, Konstantin Belousov  
> >>> wrote:
> >>> 
> >>> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote:
>  New world and kernel  r320323
>  I get a new error or message when using ruby:
>  
>  
>  /usr/local/sbin/portupgrade -av
>  : warning: pthread_create failed for timer: Resource temporarily 
>  unavailable, scheduling broken
>  
>  everything works just this message when using ruby. I recompiled ruby , 
>  still same message
>  
>  /usr/local/bin/ruby -v
>  : warning: pthread_create failed for timer: Resource temporarily 
>  unavailable, scheduling broken
>  ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12]
>  
>  Not sure what???s changed, I noticed some commits to vm stuff, maybe 
>  thats it.
> >>> 
> >>> ktrace your failing ruby invocation, then post output of kdump -H 
> >>> somewhere.
> >>> 
> >> 
> >> Ok not sure  if this is right , but this is what i did:
> >> 
> >> (tmp)4637}ktrace /usr/local/bin/ruby -v
> >> : warning: pthread_create failed for timer: Resource temporarily 
> >> unavailable, scheduling broken
> >> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12]
> >> 
> >> (tmp)4638}kdump -H -f ./ktrace.out >  kdump.txt
> >> 
> >> you can get kdump.txt at:
> >> 
> >> http://www.pozo.com/kernel/kdump .txt
> >> 
> >> It???s not failing, I don???t think , I can do portupgrade and it works 
> >> fine.
> >> I just get this new message
> > 
> > I see what is going on, but it is somewhat strange that it happens.
> > 
> > Do you run ruby in a jail with old (say, stable/10) libthr ?
> > Or do you have environment variable LIBPTHREAD_SPLITSTACK_MAIN set in
> > your environment ?
> > 
> > Anyway, the rework of the stack grow indeed have incompatibility with the
> > old (pre-11) libthr, which tries to split main thread stack into smaller
> > stacks for the new threads.  New stack grow code was specifically designed
> > to prevent this.  Some hack would be needed there, to allow reuse of
> > the main stack gap.
> > 
> 
> Not running any jails
> all libraries are current as of today
> locate libthr. |xargs ls -l
> -r--r--r--  1 root  wheel  120240 Jun 24 12:50 /lib/libthr.so.3
> -r--r--r--  1 root  wheel  256072 Jun 24 12:50 /usr/lib/libthr.a
> lrwxr-xr-x  1 root  wheel  21 Jun 24 12:50 /usr/lib/libthr.so -> 
> ../../lib/libthr.so.3
> 
> ldd /usr/local/bin/ruby
> -rwxr-xr-x  1 root  wheel  2677552 Jun 24 18:22 /usr/local/lib/libruby23.so.2
> -rwxr-xr-x  1 root  wheel  43832 Jun 24 19:10 
> /usr/local/lib/libunwind.so.8.0.1
> 
> /usr/local/bin/ruby:
>   libruby23.so.23 => /usr/local/lib/libruby23.so.23 (0x800a0)
>   libelf.so.2 => /lib/libelf.so.2 (0x800e9d000)
>   libunwind.so.8 => /usr/local/lib/libunwind.so.8 (0x8010b5000)
>   libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x8012ce000)
>   libprocstat.so.1 => /usr/lib/libprocstat.so.1 (0x8014d1000)
>   libcrypt.so.5 => /lib/libcrypt.so.5 (0x8016db000)
>   libm.so.5 => /lib/libm.so.5 (0x8018f9000)
>   libthr.so.3 => /lib/libthr.so.3 (0x801b26000)
>   libc.so.7 => /lib/libc.so.7 (0x801d4e000)
>   libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x802335000)
>   liblzma.so.5 => /usr/lib/liblzma.so.5 (0x80254b000)
>   libkvm.so.7 => /lib/libkvm.so.7 (0x802774000)
>   libutil.so.9 => /lib/libutil.so.9 (0x802982000)
> 
> no LIBPTHREAD_SPLITSTACK_MAIN set anywhere
> 
> This is a fresh buildworld - installworld from noon today California time.
> 
> here are env in make.conf:
> DEFAULT_VERSIONS= mysql=5.7 apache=2.4 python2=2.7 python3=3.4 ruby=2.3 
> perl5=5.24 php=5.6 tcltk=8.6 samba=4.4 ssl=base ncurses=base
> MALLOC_PRODUCTION=yes
> WITH_BDB_VERSION=5
> 
> env in src.conf:
> WITHOUT_DYNAMICROOT=yes 
> WITHOUT_UNBOUND=yes
> WITHOUT_CASPER=yes
> WITHOUT_CAPSICUM=yes
> WITHOUT_DMAGENT=yes
> WITHOUT_PROFILE=yes
> WITHOUT_TESTS=yes
> WITHOUT_KERNEL_SYMBOLS=yes
> WITHOUT_DEBUG_FILES=1
> WITHOUT_LIB32=yes
> INSTALL_NODEBUG=yes
> 
> # Don't die on warnings
> NO_WERROR=
> WERROR=
> KERNCONF=pozo
> WITH_CCACHE_BUILD=yes

Weird, I do not see where such behaviour could come from.  I mean,
the behaviour of the libthr, assuming that the failing call is from
libthr and not from the ruby.

Anyway, please try the following.  Note that this might be not the final
fix, but I am interesting in seeing whether it fixed the issue for you.
I want to see the kdump output from ktrace _without_ -di, same as in 
your first trace.

diff --git a/lib/libc/sys/mprotect.2 b/lib/libc/sys/mprotect.2
index 3be81c6582a..ca4d6307c44 100644
--- a/lib/libc/sys/mprotect.2
+++ b/lib/libc/sys/mprotect.2
@@ -28,7 +28,7 @@
 .\"@(#)mprotect.2  8.1 (Berkeley) 6/9/93
 .\" $FreeBSD$

Re: Current amd64 new error or warning from today's current with ruby r320323

[Manfred Antar]

> On Jun 24, 2017, at 7:04 PM, Konstantin Belousov  wrote:
> 
> On Sat, Jun 24, 2017 at 06:48:03PM -0700, Manfred Antar wrote:
>> 
>>> On Jun 24, 2017, at 6:23 PM, Konstantin Belousov  
>>> wrote:
>>> 
>>> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote:
 New world and kernel  r320323
 I get a new error or message when using ruby:
 
 
 /usr/local/sbin/portupgrade -av
 : warning: pthread_create failed for timer: Resource temporarily 
 unavailable, scheduling broken
 
 everything works just this message when using ruby. I recompiled ruby , 
 still same message
 
 /usr/local/bin/ruby -v
 : warning: pthread_create failed for timer: Resource temporarily 
 unavailable, scheduling broken
 ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12]
 
 Not sure what???s changed, I noticed some commits to vm stuff, maybe thats 
 it.
>>> 
>>> ktrace your failing ruby invocation, then post output of kdump -H somewhere.
>>> 
>> 
>> Ok not sure  if this is right , but this is what i did:
>> 
>> (tmp)4637}ktrace /usr/local/bin/ruby -v
>> : warning: pthread_create failed for timer: Resource temporarily 
>> unavailable, scheduling broken
>> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12]
>> 
>> (tmp)4638}kdump -H -f ./ktrace.out >  kdump.txt
>> 
>> you can get kdump.txt at:
>> 
>> http://www.pozo.com/kernel/kdump .txt
>> 
>> It???s not failing, I don???t think , I can do portupgrade and it works fine.
>> I just get this new message
> 
> I see what is going on, but it is somewhat strange that it happens.
> 
> Do you run ruby in a jail with old (say, stable/10) libthr ?
> Or do you have environment variable LIBPTHREAD_SPLITSTACK_MAIN set in
> your environment ?
> 
> Anyway, the rework of the stack grow indeed have incompatibility with the
> old (pre-11) libthr, which tries to split main thread stack into smaller
> stacks for the new threads.  New stack grow code was specifically designed
> to prevent this.  Some hack would be needed there, to allow reuse of
> the main stack gap.
> 

Not running any jails
all libraries are current as of today
locate libthr. |xargs ls -l
-r--r--r--  1 root  wheel  120240 Jun 24 12:50 /lib/libthr.so.3
-r--r--r--  1 root  wheel  256072 Jun 24 12:50 /usr/lib/libthr.a
lrwxr-xr-x  1 root  wheel  21 Jun 24 12:50 /usr/lib/libthr.so -> 
../../lib/libthr.so.3

ldd /usr/local/bin/ruby
-rwxr-xr-x  1 root  wheel  2677552 Jun 24 18:22 /usr/local/lib/libruby23.so.2
-rwxr-xr-x  1 root  wheel  43832 Jun 24 19:10 /usr/local/lib/libunwind.so.8.0.1

/usr/local/bin/ruby:
libruby23.so.23 => /usr/local/lib/libruby23.so.23 (0x800a0)
libelf.so.2 => /lib/libelf.so.2 (0x800e9d000)
libunwind.so.8 => /usr/local/lib/libunwind.so.8 (0x8010b5000)
libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x8012ce000)
libprocstat.so.1 => /usr/lib/libprocstat.so.1 (0x8014d1000)
libcrypt.so.5 => /lib/libcrypt.so.5 (0x8016db000)
libm.so.5 => /lib/libm.so.5 (0x8018f9000)
libthr.so.3 => /lib/libthr.so.3 (0x801b26000)
libc.so.7 => /lib/libc.so.7 (0x801d4e000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x802335000)
liblzma.so.5 => /usr/lib/liblzma.so.5 (0x80254b000)
libkvm.so.7 => /lib/libkvm.so.7 (0x802774000)
libutil.so.9 => /lib/libutil.so.9 (0x802982000)

no LIBPTHREAD_SPLITSTACK_MAIN set anywhere

This is a fresh buildworld - installworld from noon today California time.

here are env in make.conf:
DEFAULT_VERSIONS= mysql=5.7 apache=2.4 python2=2.7 python3=3.4 ruby=2.3 
perl5=5.24 php=5.6 tcltk=8.6 samba=4.4 ssl=base ncurses=base
MALLOC_PRODUCTION=yes
WITH_BDB_VERSION=5

env in src.conf:
WITHOUT_DYNAMICROOT=yes 
WITHOUT_UNBOUND=yes
WITHOUT_CASPER=yes
WITHOUT_CAPSICUM=yes
WITHOUT_DMAGENT=yes
WITHOUT_PROFILE=yes
WITHOUT_TESTS=yes
WITHOUT_KERNEL_SYMBOLS=yes
WITHOUT_DEBUG_FILES=1
WITHOUT_LIB32=yes
INSTALL_NODEBUG=yes

# Don't die on warnings
NO_WERROR=
WERROR=
KERNCONF=pozo
WITH_CCACHE_BUILD=yes

Manfred



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Current amd64 new error or warning from today's current with ruby r320323

[Manfred Antar]

> On Jun 24, 2017, at 6:55 PM, David Wolfskill  wrote:
> 
> On Sat, Jun 24, 2017 at 06:48:03PM -0700, Manfred Antar wrote:
>> ... 
>>> ktrace your failing ruby invocation, then post output of kdump -H somewhere.
>>> 
>> 
>> Ok not sure  if this is right , but this is what i did:
>> 
>> (tmp)4637}ktrace /usr/local/bin/ruby -v
> 
> You might want to re-do that, specifying the "-di" flags to ktrace (if
> the output fails to include activities from child processes, and tracing
> those is of interest).

Ok did:
ktrace -di /usr/local/bin/ruby -v

kdump -H -f ./ktrace.out >kdump-new.txt

File is at :

http://www.pozo.com/kernel/kdump-new.txt 


smaller than the first one.

Manfred
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Current amd64 new error or warning from today's current with ruby r320323

[Konstantin Belousov]

On Sat, Jun 24, 2017 at 06:48:03PM -0700, Manfred Antar wrote:
> 
> > On Jun 24, 2017, at 6:23 PM, Konstantin Belousov  
> > wrote:
> > 
> > On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote:
> >> New world and kernel  r320323
> >> I get a new error or message when using ruby:
> >> 
> >> 
> >> /usr/local/sbin/portupgrade -av
> >> : warning: pthread_create failed for timer: Resource temporarily 
> >> unavailable, scheduling broken
> >> 
> >> everything works just this message when using ruby. I recompiled ruby , 
> >> still same message
> >> 
> >> /usr/local/bin/ruby -v
> >> : warning: pthread_create failed for timer: Resource temporarily 
> >> unavailable, scheduling broken
> >> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12]
> >> 
> >> Not sure what???s changed, I noticed some commits to vm stuff, maybe thats 
> >> it.
> > 
> > ktrace your failing ruby invocation, then post output of kdump -H somewhere.
> > 
> 
> Ok not sure  if this is right , but this is what i did:
> 
> (tmp)4637}ktrace /usr/local/bin/ruby -v
> : warning: pthread_create failed for timer: Resource temporarily 
> unavailable, scheduling broken
> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12]
> 
> (tmp)4638}kdump -H -f ./ktrace.out >  kdump.txt
> 
> you can get kdump.txt at:
> 
> http://www.pozo.com/kernel/kdump .txt
> 
> It???s not failing, I don???t think , I can do portupgrade and it works fine.
> I just get this new message

I see what is going on, but it is somewhat strange that it happens.

Do you run ruby in a jail with old (say, stable/10) libthr ?
Or do you have environment variable LIBPTHREAD_SPLITSTACK_MAIN set in
your environment ?

Anyway, the rework of the stack grow indeed have incompatibility with the
old (pre-11) libthr, which tries to split main thread stack into smaller
stacks for the new threads.  New stack grow code was specifically designed
to prevent this.  Some hack would be needed there, to allow reuse of
the main stack gap.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Current amd64 new error or warning from today's current with ruby r320323

[Manfred Antar]

> On Jun 24, 2017, at 6:23 PM, Konstantin Belousov  wrote:
> 
> On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote:
>> New world and kernel  r320323
>> I get a new error or message when using ruby:
>> 
>> 
>> /usr/local/sbin/portupgrade -av
>> : warning: pthread_create failed for timer: Resource temporarily 
>> unavailable, scheduling broken
>> 
>> everything works just this message when using ruby. I recompiled ruby , 
>> still same message
>> 
>> /usr/local/bin/ruby -v
>> : warning: pthread_create failed for timer: Resource temporarily 
>> unavailable, scheduling broken
>> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12]
>> 
>> Not sure what???s changed, I noticed some commits to vm stuff, maybe thats 
>> it.
> 
> ktrace your failing ruby invocation, then post output of kdump -H somewhere.
> 

Ok not sure  if this is right , but this is what i did:

(tmp)4637}ktrace /usr/local/bin/ruby -v
: warning: pthread_create failed for timer: Resource temporarily 
unavailable, scheduling broken
ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12]

(tmp)4638}kdump -H -f ./ktrace.out >  kdump.txt

you can get kdump.txt at:

http://www.pozo.com/kernel/kdump .txt

It’s not failing, I don’t think , I can do portupgrade and it works fine.
I just get this new message



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Current amd64 new error or warning from today's current with ruby r320323

[Konstantin Belousov]

On Sat, Jun 24, 2017 at 06:08:50PM -0700, Manfred Antar wrote:
> New world and kernel  r320323
> I get a new error or message when using ruby:
> 
> 
> /usr/local/sbin/portupgrade -av
> : warning: pthread_create failed for timer: Resource temporarily 
> unavailable, scheduling broken
> 
> everything works just this message when using ruby. I recompiled ruby , still 
> same message
> 
> /usr/local/bin/ruby -v
> : warning: pthread_create failed for timer: Resource temporarily 
> unavailable, scheduling broken
> ruby 2.3.4p301 (2017-03-30 revision 58214) [amd64-freebsd12]
> 
> Not sure what???s changed, I noticed some commits to vm stuff, maybe thats it.

ktrace your failing ruby invocation, then post output of kdump -H somewhere.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"