Re: hg clone segmentation fault on octeon

2018-05-19 Thread Juan Francisco Cantero Hurtado 
No problem. I was asking because I think that the problem is on python
or maybe on libressl, not on mercurial. Mercurial has very few C files
and they don't use C for that part of the clone, just simple python
code.

If you can't run the full tests set, you could also find some small
python example which crashes when it tries to connect to https. That
would be enough.

Meanwhile, if you need to use mercurial, try with ssh:// repos and avoid
the https:// ones.


On Sat, May 19, 2018 at 01:48:30PM -0700, Nick Owens wrote:
> my ERL is very sad and slow with a 500mhz cpu/512M ram and the usb drive is
> very sad and slow at around 1-2MB/s throughput.
> 
> i will see about getting ports going on it, but it may take a while, if it
> even works.
> 
> 
> On Sat, May 19, 2018 at 12:41 PM, Juan Francisco Cantero Hurtado <
> i...@juanfra.info> wrote:
> 
> > The segfault is in:
> > httppeer.py(901): resp.close()
> >
> > (the line number is not the same because I'm using a different version)
> >
> > Can you run "make test" within /usr/ports/lang/python/2.7 ?
> >
> > At the end of the long list of tests, it will run a few tests against
> > the SSL library. You should see some segfaults there.
> >
> >
> >
> > On Sat, May 19, 2018 at 10:19:17AM -0700, Nick Owens wrote:
> > > no, that's working fine. it does not crash and i see the HTML content
> > from
> > > the webserver.
> > >
> > > i've discovered python has a tracing module and tried it out, but it's
> > not
> > > making the fault any clearer.
> > >
> > > python2.7 -m trace --trace `which hg` clone
> > > https://www.mercurial-scm.org/repo/hello
> > >
> > > here's the last 40 or so lines.
> > >
> > >  --- modulename: socket, funcname: readline
> > > socket.py(411): buf = self._rbuf
> > > socket.py(412): buf.seek(0, 2)  # seek end
> > > socket.py(413): if buf.tell() > 0:
> > > socket.py(415): buf.seek(0)
> > > socket.py(416): bline = buf.readline(size)
> > > socket.py(417): if bline.endswith('\n') or len(bline) ==
> > size:
> > > socket.py(418): self._rbuf = StringIO()
> > > socket.py(419): self._rbuf.write(buf.read())
> > > socket.py(420): return bline
> > > keepalive.py(462): if not line:
> > > keepalive.py(466): if line == '\r\n':
> > > keepalive.py(467): break
> > > keepalive.py(470): self.close()
> > >  --- modulename: keepalive, funcname: close
> > > keepalive.py(386): if self.fp:
> > > keepalive.py(387): self.fp.close()
> > >  --- modulename: socket, funcname: close
> > > socket.py(281): try:
> > > socket.py(282): if self._sock:
> > > socket.py(283): self.flush()
> > >  --- modulename: socket, funcname: flush
> > > socket.py(297): if self._wbuf:
> > > socket.py(285): if self._close:
> > > socket.py(286): self._sock.close()
> > >  --- modulename: ssl, funcname: close
> > > ssl.py(815): if self._makefile_refs < 1:
> > > ssl.py(819): self._makefile_refs -= 1
> > > socket.py(287): self._sock = None
> > > keepalive.py(388): self.fp = None
> > >  --- modulename: socket, funcname: __del__
> > > socket.py(290): try:
> > > socket.py(291): self.close()
> > >  --- modulename: socket, funcname: close
> > > socket.py(281): try:
> > > socket.py(282): if self._sock:
> > > socket.py(285): if self._close:
> > > socket.py(286): self._sock.close()
> > > socket.py(292): except:
> > > socket.py(294): pass
> > > keepalive.py(389): if self._handler:
> > > keepalive.py(390): self._handler._request_closed(self,
> > > self._host,
> > > keepalive.py(391):
> > > self._connection)
> > >  --- modulename: keepalive, funcname: _request_closed
> > > keepalive.py(199): self._cm.set_ready(connection, 1)
> > >  --- modulename: keepalive, funcname: set_ready
> > > keepalive.py(146): try:
> > > keepalive.py(147): self._readymap[connection] = ready
> > > keepalive.py(472): return ''.join(parts)
> > > keepalive.py(416): self._rbuf = ''
> > > keepalive.py(417): return s
> > > Segmentation fault (core dumped)
> > >
> > >
> > >
> > > On Sat, May 19, 2018 at 7:55 AM, Juan Francisco Cantero Hurtado <
> > > i...@juanfra.info> wrote:
> > >
> > > > Try this:
> > > >
> > > > python2.7 -c 'import urllib2; web = urllib2.urlopen("https://www.
> > > > mercurial-scm.org/repo/hello"); print web.read()'
> > > >
> > > > Does python crash?
> > > >
> > > >
> > > > On Fri, May 18, 2018 at 02:18:13PM -0700, Nick Owens wrote:
> > > > > it looks like that's working. with this test mercurial prints
> > (falling
> > > > back
> > > > > to static-http) whereas in the mercurial 'hello' repo it does not. i
> > > > wonder
> > > > > if it has something todo with the web

Re: hg clone segmentation fault on octeon

2018-05-19 Thread Nick Owens 
my ERL is very sad and slow with a 500mhz cpu/512M ram and the usb drive is
very sad and slow at around 1-2MB/s throughput.

i will see about getting ports going on it, but it may take a while, if it
even works.


On Sat, May 19, 2018 at 12:41 PM, Juan Francisco Cantero Hurtado <
i...@juanfra.info> wrote:

> The segfault is in:
> httppeer.py(901): resp.close()
>
> (the line number is not the same because I'm using a different version)
>
> Can you run "make test" within /usr/ports/lang/python/2.7 ?
>
> At the end of the long list of tests, it will run a few tests against
> the SSL library. You should see some segfaults there.
>
>
>
> On Sat, May 19, 2018 at 10:19:17AM -0700, Nick Owens wrote:
> > no, that's working fine. it does not crash and i see the HTML content
> from
> > the webserver.
> >
> > i've discovered python has a tracing module and tried it out, but it's
> not
> > making the fault any clearer.
> >
> > python2.7 -m trace --trace `which hg` clone
> > https://www.mercurial-scm.org/repo/hello
> >
> > here's the last 40 or so lines.
> >
> >  --- modulename: socket, funcname: readline
> > socket.py(411): buf = self._rbuf
> > socket.py(412): buf.seek(0, 2)  # seek end
> > socket.py(413): if buf.tell() > 0:
> > socket.py(415): buf.seek(0)
> > socket.py(416): bline = buf.readline(size)
> > socket.py(417): if bline.endswith('\n') or len(bline) ==
> size:
> > socket.py(418): self._rbuf = StringIO()
> > socket.py(419): self._rbuf.write(buf.read())
> > socket.py(420): return bline
> > keepalive.py(462): if not line:
> > keepalive.py(466): if line == '\r\n':
> > keepalive.py(467): break
> > keepalive.py(470): self.close()
> >  --- modulename: keepalive, funcname: close
> > keepalive.py(386): if self.fp:
> > keepalive.py(387): self.fp.close()
> >  --- modulename: socket, funcname: close
> > socket.py(281): try:
> > socket.py(282): if self._sock:
> > socket.py(283): self.flush()
> >  --- modulename: socket, funcname: flush
> > socket.py(297): if self._wbuf:
> > socket.py(285): if self._close:
> > socket.py(286): self._sock.close()
> >  --- modulename: ssl, funcname: close
> > ssl.py(815): if self._makefile_refs < 1:
> > ssl.py(819): self._makefile_refs -= 1
> > socket.py(287): self._sock = None
> > keepalive.py(388): self.fp = None
> >  --- modulename: socket, funcname: __del__
> > socket.py(290): try:
> > socket.py(291): self.close()
> >  --- modulename: socket, funcname: close
> > socket.py(281): try:
> > socket.py(282): if self._sock:
> > socket.py(285): if self._close:
> > socket.py(286): self._sock.close()
> > socket.py(292): except:
> > socket.py(294): pass
> > keepalive.py(389): if self._handler:
> > keepalive.py(390): self._handler._request_closed(self,
> > self._host,
> > keepalive.py(391):
> > self._connection)
> >  --- modulename: keepalive, funcname: _request_closed
> > keepalive.py(199): self._cm.set_ready(connection, 1)
> >  --- modulename: keepalive, funcname: set_ready
> > keepalive.py(146): try:
> > keepalive.py(147): self._readymap[connection] = ready
> > keepalive.py(472): return ''.join(parts)
> > keepalive.py(416): self._rbuf = ''
> > keepalive.py(417): return s
> > Segmentation fault (core dumped)
> >
> >
> >
> > On Sat, May 19, 2018 at 7:55 AM, Juan Francisco Cantero Hurtado <
> > i...@juanfra.info> wrote:
> >
> > > Try this:
> > >
> > > python2.7 -c 'import urllib2; web = urllib2.urlopen("https://www.
> > > mercurial-scm.org/repo/hello"); print web.read()'
> > >
> > > Does python crash?
> > >
> > >
> > > On Fri, May 18, 2018 at 02:18:13PM -0700, Nick Owens wrote:
> > > > it looks like that's working. with this test mercurial prints
> (falling
> > > back
> > > > to static-http) whereas in the mercurial 'hello' repo it does not. i
> > > wonder
> > > > if it has something todo with the web server/http protocol.
> > > >
> > > > erl$ pwd
> > > > /home/mischief
> > > > erl$ df -h
> > > > Filesystem SizeUsed   Avail Capacity  Mounted on
> > > > /dev/sd0a 13.9G923M   12.3G 7%/
> > > > erl$ uname -a
> > > > OpenBSD erl.house.lan 6.3 GENERIC#0 octeon
> > > > erl$ hg -v clone http://juanfra684.blinkenshell.org/tmp/hello
> > > > (falling back to static-http)
> > > > destination directory: hello
> > > > requesting all changes
> > > > 2 changesets found
> > > > uncompressed size of bundle content:
> > > >  464 (changelog)
> > > >  335 (manifests)
> > > >  143  Makefile
> > > >  388  hello.c
> > > > adding changesets
> > > > adding manifests
> > > > adding file changes
> > > > added 2 changesets with

Re: hg clone segmentation fault on octeon

2018-05-19 Thread Juan Francisco Cantero Hurtado 
The segfault is in:
httppeer.py(901): resp.close()

(the line number is not the same because I'm using a different version)

Can you run "make test" within /usr/ports/lang/python/2.7 ?

At the end of the long list of tests, it will run a few tests against
the SSL library. You should see some segfaults there.



On Sat, May 19, 2018 at 10:19:17AM -0700, Nick Owens wrote:
> no, that's working fine. it does not crash and i see the HTML content from
> the webserver.
> 
> i've discovered python has a tracing module and tried it out, but it's not
> making the fault any clearer.
> 
> python2.7 -m trace --trace `which hg` clone
> https://www.mercurial-scm.org/repo/hello
> 
> here's the last 40 or so lines.
> 
>  --- modulename: socket, funcname: readline
> socket.py(411): buf = self._rbuf
> socket.py(412): buf.seek(0, 2)  # seek end
> socket.py(413): if buf.tell() > 0:
> socket.py(415): buf.seek(0)
> socket.py(416): bline = buf.readline(size)
> socket.py(417): if bline.endswith('\n') or len(bline) == size:
> socket.py(418): self._rbuf = StringIO()
> socket.py(419): self._rbuf.write(buf.read())
> socket.py(420): return bline
> keepalive.py(462): if not line:
> keepalive.py(466): if line == '\r\n':
> keepalive.py(467): break
> keepalive.py(470): self.close()
>  --- modulename: keepalive, funcname: close
> keepalive.py(386): if self.fp:
> keepalive.py(387): self.fp.close()
>  --- modulename: socket, funcname: close
> socket.py(281): try:
> socket.py(282): if self._sock:
> socket.py(283): self.flush()
>  --- modulename: socket, funcname: flush
> socket.py(297): if self._wbuf:
> socket.py(285): if self._close:
> socket.py(286): self._sock.close()
>  --- modulename: ssl, funcname: close
> ssl.py(815): if self._makefile_refs < 1:
> ssl.py(819): self._makefile_refs -= 1
> socket.py(287): self._sock = None
> keepalive.py(388): self.fp = None
>  --- modulename: socket, funcname: __del__
> socket.py(290): try:
> socket.py(291): self.close()
>  --- modulename: socket, funcname: close
> socket.py(281): try:
> socket.py(282): if self._sock:
> socket.py(285): if self._close:
> socket.py(286): self._sock.close()
> socket.py(292): except:
> socket.py(294): pass
> keepalive.py(389): if self._handler:
> keepalive.py(390): self._handler._request_closed(self,
> self._host,
> keepalive.py(391):
> self._connection)
>  --- modulename: keepalive, funcname: _request_closed
> keepalive.py(199): self._cm.set_ready(connection, 1)
>  --- modulename: keepalive, funcname: set_ready
> keepalive.py(146): try:
> keepalive.py(147): self._readymap[connection] = ready
> keepalive.py(472): return ''.join(parts)
> keepalive.py(416): self._rbuf = ''
> keepalive.py(417): return s
> Segmentation fault (core dumped)
> 
> 
> 
> On Sat, May 19, 2018 at 7:55 AM, Juan Francisco Cantero Hurtado <
> i...@juanfra.info> wrote:
> 
> > Try this:
> >
> > python2.7 -c 'import urllib2; web = urllib2.urlopen("https://www.
> > mercurial-scm.org/repo/hello"); print web.read()'
> >
> > Does python crash?
> >
> >
> > On Fri, May 18, 2018 at 02:18:13PM -0700, Nick Owens wrote:
> > > it looks like that's working. with this test mercurial prints (falling
> > back
> > > to static-http) whereas in the mercurial 'hello' repo it does not. i
> > wonder
> > > if it has something todo with the web server/http protocol.
> > >
> > > erl$ pwd
> > > /home/mischief
> > > erl$ df -h
> > > Filesystem SizeUsed   Avail Capacity  Mounted on
> > > /dev/sd0a 13.9G923M   12.3G 7%/
> > > erl$ uname -a
> > > OpenBSD erl.house.lan 6.3 GENERIC#0 octeon
> > > erl$ hg -v clone http://juanfra684.blinkenshell.org/tmp/hello
> > > (falling back to static-http)
> > > destination directory: hello
> > > requesting all changes
> > > 2 changesets found
> > > uncompressed size of bundle content:
> > >  464 (changelog)
> > >  335 (manifests)
> > >  143  Makefile
> > >  388  hello.c
> > > adding changesets
> > > adding manifests
> > > adding file changes
> > > added 2 changesets with 2 changes to 2 files
> > > new changesets 0a04b987be5a:82e55d328c8c
> > > updating to branch default
> > > resolving manifests
> > > getting Makefile
> > > getting hello.c
> > > 2 files updated, 0 files merged, 0 files removed, 0 files unresolved
> > >
> > > On Fri, May 18, 2018 at 1:49 PM, Juan Francisco Cantero Hurtado <
> > > i...@juanfra.info> wrote:
> > >
> > > > On Fri, May 18, 2018 at 07:50:03AM -0700, misch...@offblast.org wrote:
> > > > > >Synopsis:hg clone segmentation fault on octeon
> > > > > >Category:user mips64
>

Re: Panic in IPSEC

2018-05-19 Thread Peter J. Philipp 
On Sat, May 19, 2018 at 02:46:35PM +0200, Alexander Bluhm wrote:
> On Sat, May 19, 2018 at 02:30:27PM +0200, Peter J. Philipp wrote:
> > I have applied it now, what it was
> > missing was a terminating semicolon on KERNEL_LOCK(), so far my C goes I was
> > able to correct that.
> 
> Ah, I tested a GENERIC non MP kernel in qemu.  There the define is
> a noop and the compiler ignored the missing ; .
> 
> > Do you want me to get back to you tonight after 8PM in case this
> > box hasn't paniced again?
> 
> To trigger the panic, you must send a lot of traffic.  Please report
> tonight whether it is stable now.

Hi,

The box is still up, but I wasn't able to put much traffic on it because
I'm recabling my home.  I exchanged routers and cables to other areas of
the apartment.  Let me know if you want me to upload something and I'll
gladly do it.

Regards,
-peter

> Here is the fixed diff.
> 
> bluhm
> 
> Index: net/pfkeyv2.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/net/pfkeyv2.c,v
> retrieving revision 1.179
> diff -u -p -r1.179 pfkeyv2.c
> --- net/pfkeyv2.c 16 May 2018 13:19:00 -  1.179
> +++ net/pfkeyv2.c 19 May 2018 12:37:11 -
> @@ -381,12 +381,15 @@ pfkey_sendup(struct keycb *kp, struct mb
>   } else
>   m = m0;
>  
> + KERNEL_LOCK();
>   if (!sbappendaddr(so, >so_rcv, _addr, m, NULL)) {
>   m_freem(m);
> + KERNEL_UNLOCK();
>   return (ENOBUFS);
>   }
>  
>   sorwakeup(so);
> + KERNEL_UNLOCK();
>   return (0);
>  }
>

Re: ddb(4): p[rint] man page example vs. result.

2018-05-19 Thread Jason McIntyre 
On Wed, May 16, 2018 at 12:41:01PM +0300, Artturi Alm wrote:
> On Wed, May 09, 2018 at 11:35:42AM +0200, Martin Pieuchot wrote:
> > On 09/05/18(Wed) 12:13, Artturi Alm wrote:
> > > On Wed, May 09, 2018 at 10:23:41AM +0200, Martin Pieuchot wrote:
> > > > On 09/05/18(Wed) 07:48, Artturi Alm wrote:
> > > > > On Tue, May 08, 2018 at 01:44:39AM +0300, Artturi Alm wrote:
> > > > 
> > > > 
> > > > No bug are irrelevant to fix.  But working with you is hard, really
> > > > hard.  You never explain what the problem is.  Reading your email is
> > > > an exercise in frustration because you can do some good work but you
> > > > fail to communicate.
> > > > 
> > > > > > (manual "copypaste"):
> > > > > > nc2k4hp# sysctl ddb.trigger=1
> > > > > > Stopped at  db_enter+0x4:   popl%ebp
> > > > > > ddb{0}> print/x "eax = " $eax "\necx = " $ecx "\n"
> > > > > > 3
> > > > > > ddb{0}> c
> > > > > > ddb.trigger: 0 -> 1
> > > > > > 
> > > > > > so, for reasons yet unknown to me, p[rint] doesn't seem to work at 
> > > > > > all
> > > > > > like described in the man page, tested on i386.
> > > > 
> > > > What do no work?  What does the man page describe?  Do you expect us to
> > > > read the man page, then look at your mail again, then try to understand
> > > > what is not working? 
> > > > 
> > > 
> > > For example,
> > > 
> > >   print/x "eax = " $eax "\necx = " $ecx "\n"
> > > 
> > > will print something like this:
> > > 
> > >   eax = xx
> > >   ecx = yy
> > > 
> > > Now I did install 5.0 into a VM, and there the result for above example
> > > would of have been just "Ambiguous", and I'm guessing now that this
> > > has not been working as in the example since import.
> > > My fix is limited to producing output just like in the example, but
> > > input requires more, as it needs escapes for everything not a-z,A-Z,0-9.
> > > 
> > > > > > Should it work? I hope it would.
> > > > 
> > > > What should work?  Why do you hope?  Maybe the manpage should be fixed?
> > > > 
> > > 
> > > Multiple [addr] arguments to p[rint], including support for strings,
> > > and i hope so because i would find it useful while testing/writing/porting
> > > drivers. Maybe, I do like "show struct", and have more than just
> > > the filtering diff for it, but it doesn't really work for the ad hoc
> > > usecases p[rint] seems so excellent for.
> > > 
> > > > > Does feel like waste of time to go any further fixing this, if this is
> > > > > yet another bug too irrelevant for anyone to ack for, so _any_ input
> > > > > here would be great.
> > > > 
> > > > Like I said, no bug are irrelevant but if the one finding the bug, you
> > > > in that case, is not willing to properly explain the problem, then
> > > > better not send an email at all ;)
> > > 
> > > Will try in the future.
> > 
> > Thanks for the explanation!
> > 
> > > haven't tested the diff below yet, but compared to previous, it should
> > > have working /modifierS.
> > 
> > IMHO we should just amend the man page and keep ddb(4) code simple. 
> 
> Np., initial diff to castrate it to reality below, and jmc@ CC'd.
> 
> Unsure about the wording of the "If no modifier is ..." sentence towards
> end, atleast "the last one specified" when there can be only one specified
> does sound weird to me, maybe replacing 'previous' with 'last'?
> 
> Anyway I'm done with this, due broken english and all:)
> 
> -Artturi
> 
> 
> diff --git share/man/man4/ddb.4 share/man/man4/ddb.4
> index 02ff2fd78a6..69402f0c776 100644
> --- share/man/man4/ddb.4
> +++ share/man/man4/ddb.4
> @@ -278,9 +278,9 @@ plus the size of the data examined.
>  .It Xo
>  .Ic p Ns Op Ic rint
>  .Op Cm /axzodurc
> -.Op Ar addr Op Ar addr ...
> +.Op Ar addr
>  .Xc
> -Print each
> +Print
>  .Ar addr
>  according to the modifier character.
>  The valid modifiers are a subset of those from the
> @@ -290,20 +290,15 @@ If no modifier is specified, the last one specified in a
>  previous use of
>  .Ic print
>  is used.
> -The
> -.Ar addr
> -argument
> -can be a string, and it is printed as a literal.
>  .Pp
>  For example,
>  .Bd -literal -offset indent
> -print/x "eax = " $eax "\enecx = " $ecx "\en"
> +print/x $eax
>  .Ed
>  .Pp
>  will print something like this:
>  .Bd -literal -offset indent
> -eax = xx
> -ecx = yy
> +xx
>  .Ed
>  .\" 
>  .It Xo

fixed, thanks.
jmc

Re: hg clone segmentation fault on octeon

2018-05-19 Thread Nick Owens 
no, that's working fine. it does not crash and i see the HTML content from
the webserver.

i've discovered python has a tracing module and tried it out, but it's not
making the fault any clearer.

python2.7 -m trace --trace `which hg` clone
https://www.mercurial-scm.org/repo/hello

here's the last 40 or so lines.

 --- modulename: socket, funcname: readline
socket.py(411): buf = self._rbuf
socket.py(412): buf.seek(0, 2)  # seek end
socket.py(413): if buf.tell() > 0:
socket.py(415): buf.seek(0)
socket.py(416): bline = buf.readline(size)
socket.py(417): if bline.endswith('\n') or len(bline) == size:
socket.py(418): self._rbuf = StringIO()
socket.py(419): self._rbuf.write(buf.read())
socket.py(420): return bline
keepalive.py(462): if not line:
keepalive.py(466): if line == '\r\n':
keepalive.py(467): break
keepalive.py(470): self.close()
 --- modulename: keepalive, funcname: close
keepalive.py(386): if self.fp:
keepalive.py(387): self.fp.close()
 --- modulename: socket, funcname: close
socket.py(281): try:
socket.py(282): if self._sock:
socket.py(283): self.flush()
 --- modulename: socket, funcname: flush
socket.py(297): if self._wbuf:
socket.py(285): if self._close:
socket.py(286): self._sock.close()
 --- modulename: ssl, funcname: close
ssl.py(815): if self._makefile_refs < 1:
ssl.py(819): self._makefile_refs -= 1
socket.py(287): self._sock = None
keepalive.py(388): self.fp = None
 --- modulename: socket, funcname: __del__
socket.py(290): try:
socket.py(291): self.close()
 --- modulename: socket, funcname: close
socket.py(281): try:
socket.py(282): if self._sock:
socket.py(285): if self._close:
socket.py(286): self._sock.close()
socket.py(292): except:
socket.py(294): pass
keepalive.py(389): if self._handler:
keepalive.py(390): self._handler._request_closed(self,
self._host,
keepalive.py(391):
self._connection)
 --- modulename: keepalive, funcname: _request_closed
keepalive.py(199): self._cm.set_ready(connection, 1)
 --- modulename: keepalive, funcname: set_ready
keepalive.py(146): try:
keepalive.py(147): self._readymap[connection] = ready
keepalive.py(472): return ''.join(parts)
keepalive.py(416): self._rbuf = ''
keepalive.py(417): return s
Segmentation fault (core dumped)



On Sat, May 19, 2018 at 7:55 AM, Juan Francisco Cantero Hurtado <
i...@juanfra.info> wrote:

> Try this:
>
> python2.7 -c 'import urllib2; web = urllib2.urlopen("https://www.
> mercurial-scm.org/repo/hello"); print web.read()'
>
> Does python crash?
>
>
> On Fri, May 18, 2018 at 02:18:13PM -0700, Nick Owens wrote:
> > it looks like that's working. with this test mercurial prints (falling
> back
> > to static-http) whereas in the mercurial 'hello' repo it does not. i
> wonder
> > if it has something todo with the web server/http protocol.
> >
> > erl$ pwd
> > /home/mischief
> > erl$ df -h
> > Filesystem SizeUsed   Avail Capacity  Mounted on
> > /dev/sd0a 13.9G923M   12.3G 7%/
> > erl$ uname -a
> > OpenBSD erl.house.lan 6.3 GENERIC#0 octeon
> > erl$ hg -v clone http://juanfra684.blinkenshell.org/tmp/hello
> > (falling back to static-http)
> > destination directory: hello
> > requesting all changes
> > 2 changesets found
> > uncompressed size of bundle content:
> >  464 (changelog)
> >  335 (manifests)
> >  143  Makefile
> >  388  hello.c
> > adding changesets
> > adding manifests
> > adding file changes
> > added 2 changesets with 2 changes to 2 files
> > new changesets 0a04b987be5a:82e55d328c8c
> > updating to branch default
> > resolving manifests
> > getting Makefile
> > getting hello.c
> > 2 files updated, 0 files merged, 0 files removed, 0 files unresolved
> >
> > On Fri, May 18, 2018 at 1:49 PM, Juan Francisco Cantero Hurtado <
> > i...@juanfra.info> wrote:
> >
> > > On Fri, May 18, 2018 at 07:50:03AM -0700, misch...@offblast.org wrote:
> > > > >Synopsis:hg clone segmentation fault on octeon
> > > > >Category:user mips64
> > > > >Environment:
> > > >   System  : OpenBSD 6.3
> > > >   Details : OpenBSD 6.3 (GENERIC) #0: Sun Mar 25 19:48:22 UTC
> > > 2018
> > > >visa@octeon:/usr/src/sys/arch/
> > > octeon/compile/GENERIC
> > > >
> > > >   Architecture: OpenBSD.octeon
> > > >   Machine : octeon
> > > > >Description:
> > > >   mercurial core dumps when executing clone
> > > > >How-To-Repeat:
> > > >   install openbsd/octeon on edgerouter lite
> > > >   single / partition with wxallowed
> > > >   erl# pkg_add mercurial
> > > >   erl$ hg clone

Re: hg clone segmentation fault on octeon

2018-05-19 Thread Juan Francisco Cantero Hurtado 
Try this:

python2.7 -c 'import urllib2; web = 
urllib2.urlopen("https://www.mercurial-scm.org/repo/hello;); print web.read()'

Does python crash?


On Fri, May 18, 2018 at 02:18:13PM -0700, Nick Owens wrote:
> it looks like that's working. with this test mercurial prints (falling back
> to static-http) whereas in the mercurial 'hello' repo it does not. i wonder
> if it has something todo with the web server/http protocol.
> 
> erl$ pwd
> /home/mischief
> erl$ df -h
> Filesystem SizeUsed   Avail Capacity  Mounted on
> /dev/sd0a 13.9G923M   12.3G 7%/
> erl$ uname -a
> OpenBSD erl.house.lan 6.3 GENERIC#0 octeon
> erl$ hg -v clone http://juanfra684.blinkenshell.org/tmp/hello
> (falling back to static-http)
> destination directory: hello
> requesting all changes
> 2 changesets found
> uncompressed size of bundle content:
>  464 (changelog)
>  335 (manifests)
>  143  Makefile
>  388  hello.c
> adding changesets
> adding manifests
> adding file changes
> added 2 changesets with 2 changes to 2 files
> new changesets 0a04b987be5a:82e55d328c8c
> updating to branch default
> resolving manifests
> getting Makefile
> getting hello.c
> 2 files updated, 0 files merged, 0 files removed, 0 files unresolved
> 
> On Fri, May 18, 2018 at 1:49 PM, Juan Francisco Cantero Hurtado <
> i...@juanfra.info> wrote:
> 
> > On Fri, May 18, 2018 at 07:50:03AM -0700, misch...@offblast.org wrote:
> > > >Synopsis:hg clone segmentation fault on octeon
> > > >Category:user mips64
> > > >Environment:
> > >   System  : OpenBSD 6.3
> > >   Details : OpenBSD 6.3 (GENERIC) #0: Sun Mar 25 19:48:22 UTC
> > 2018
> > >visa@octeon:/usr/src/sys/arch/
> > octeon/compile/GENERIC
> > >
> > >   Architecture: OpenBSD.octeon
> > >   Machine : octeon
> > > >Description:
> > >   mercurial core dumps when executing clone
> > > >How-To-Repeat:
> > >   install openbsd/octeon on edgerouter lite
> > >   single / partition with wxallowed
> > >   erl# pkg_add mercurial
> > >   erl$ hg clone https://www.mercurial-scm.org/repo/hello
> > >   destination directory: hello
> > >   requesting all changes
> > >   Segmentation fault (core dumped)
> > >
> > > >Fix:
> > >   no clue how to fix it. gdb output:
> >
> > Hi, I don't have an Octeon system to test mercurial but it's working
> > fine on mips64el. Can you test this command?
> >
> > hg -v clone http://juanfra684.blinkenshell.org/tmp/hello
> >
> >
> >
> > --
> > Juan Francisco Cantero Hurtado http://juanfra.info
> >

-- 
Juan Francisco Cantero Hurtado http://juanfra.info

ugold(4) fyi

2018-05-19 Thread Artturi Alm 
Hi,


I ran into a thread[0] that somehow did seem to suggest some variants
of uthum(4) might be affected by this also, but i don't use/have these
devices, so i didn't look deeper, just saw on misc@ that these still
have users..

URL[1] to the issue on github containing what i think is the fix you'd
need if you care, was referenced on tech@[2], before the fix was there,
unless i looked at the dates wrong, so i was thinking someone should
revisit there.

Reading [1] should be enough for users/devs familiar with the issue.

-Artturi

[0] https://marc.info/?l=openbsd-misc=136844728930246=2
[1] https://github.com/edorfaus/TEMPered/issues/39
[2] https://marc.info/?l=openbsd-tech=150715036829680=2

Re: Panic in IPSEC

2018-05-19 Thread mabi 
On May 19, 2018 2:52 PM, Alexander Bluhm  wrote:

> This is unrelated, the expire bug was introduced just a few days ago.

sorry for the noise...

Re: Panic in IPSEC

2018-05-19 Thread Alexander Bluhm 
On Sat, May 19, 2018 at 08:45:01AM -0400, mabi wrote:
> If that might help you guys, this seems quite similar to the issue I have 
> encountered and reported on this mailing list back in April:
> https://marc.info/?l=openbsd-bugs=152417193124446=2

This is unrelated, the expire bug was introduced just a few days ago.

https://marc.info/?l=openbsd-cvs=152628324915667=2

bluhm

Re: Panic in IPSEC

2018-05-19 Thread Alexander Bluhm 
On Sat, May 19, 2018 at 02:30:27PM +0200, Peter J. Philipp wrote:
> I have applied it now, what it was
> missing was a terminating semicolon on KERNEL_LOCK(), so far my C goes I was
> able to correct that.

Ah, I tested a GENERIC non MP kernel in qemu.  There the define is
a noop and the compiler ignored the missing ; .

> Do you want me to get back to you tonight after 8PM in case this
> box hasn't paniced again?

To trigger the panic, you must send a lot of traffic.  Please report
tonight whether it is stable now.

Here is the fixed diff.

bluhm

Index: net/pfkeyv2.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/net/pfkeyv2.c,v
retrieving revision 1.179
diff -u -p -r1.179 pfkeyv2.c
--- net/pfkeyv2.c   16 May 2018 13:19:00 -  1.179
+++ net/pfkeyv2.c   19 May 2018 12:37:11 -
@@ -381,12 +381,15 @@ pfkey_sendup(struct keycb *kp, struct mb
} else
m = m0;
 
+   KERNEL_LOCK();
if (!sbappendaddr(so, >so_rcv, _addr, m, NULL)) {
m_freem(m);
+   KERNEL_UNLOCK();
return (ENOBUFS);
}
 
sorwakeup(so);
+   KERNEL_UNLOCK();
return (0);
 }

Re: Panic in IPSEC

2018-05-19 Thread mabi 
On May 19, 2018 2:36 PM, Alexander Bluhm  wrote:

> After a certain amount of traffic, the key is expired. The kernel
> 
> wants to send a message to iked, but it has not acquired the porpper
> 
> lock.
> 
> Default in iked is
> 
> #define IKED_LIFETIME_BYTES 536870912 /* 512 Mb */
> 
> I think you can change it in iked.conf
> 
> lifetime time [bytes bytes]
> 
> bluhm

If that might help you guys, this seems quite similar to the issue I have 
encountered and reported on this mailing list back in April:

https://marc.info/?l=openbsd-bugs=152417193124446=2

Re: Panic in IPSEC

2018-05-19 Thread Alexander Bluhm 
On Sat, May 19, 2018 at 02:08:55PM +0200, Peter J. Philipp wrote:
> > panic: kernel diagnostic assertion "_kernel_lock_held()" failed in file "/us

It is /usr/src/sys/kern/uipc_socket2.c, line 314

   302  void
   303  soassertlocked(struct socket *so)
   304  {
   305  switch (so->so_proto->pr_domain->dom_family) {
   306  case PF_INET:
   307  case PF_INET6:
   308  NET_ASSERT_LOCKED();
   309  break;
   310  case PF_UNIX:
   311  case PF_ROUTE:
   312  case PF_KEY:
   313  default:
*  314  KERNEL_ASSERT_LOCKED();
   315  break;
   316  }
   317  }

> It just panic'ed again 5 min ago.

It is not a matter of time, but of transfered bytes.  It is triggered
in /usr/src/sys/netinet/ip_esp.c, line 436

   433  /* Notify on soft expiration */
   434  if ((tdb->tdb_flags & TDBF_SOFT_BYTES) &&
   435  (tdb->tdb_cur_bytes >= tdb->tdb_soft_bytes)) {
*  436  pfkeyv2_expire(tdb, SADB_EXT_LIFETIME_SOFT);
   437  tdb->tdb_flags &= ~TDBF_SOFT_BYTES;   /* Turn off 
checking */
   438  }

After a certain amount of traffic, the key is expired.  The kernel
wants to send a message to iked, but it has not acquired the porpper
lock.

Default in iked is
#define IKED_LIFETIME_BYTES 536870912 /* 512 Mb */
I think you can change it in iked.conf
 lifetime time [bytes bytes]

bluhm

Re: Panic in IPSEC

2018-05-19 Thread Peter J. Philipp 
On Sat, May 19, 2018 at 02:02:35PM +0200, Alexander Bluhm wrote:
> On Sat, May 19, 2018 at 12:57:19PM +0200, Peter J. Philipp wrote:
> > panic: kernel diagnostic assertion...(cut)
> 
> This is an important line.
> panic: kernel diagnostic assertion "_kernel_lock_held()" failed in file "/us
> Then the photo is cut, but I can guess what is next.
> 
> > soassertlocked(815c8c03) at soassertlocked+0x73
> > sorwakeup(800032d930c8) at sorwakeup+0xf
> > pfkeyv2_sendmessage(b0, 
> > 80137c00,4,8124d700,800032d93128,2aa6da05f83cead1) at 
> > pfkeyv2_sendmessage+0x20b
> 
> I would say as long we have no per socket locking, we must grab
> either net lock or kernel lock when accessing the socket.  For pf
> key sockets it is kernel lock, so just add it there.
> 
> bluhm

Hi Alexander,

Let me say thanks again for the patch.  I have applied it now, what it was
missing was a terminating semicolon on KERNEL_LOCK(), so far my C goes I was
able to correct that.  We'll see fairly soon if this is the right fix I gather.

Given the second photo one can probably make out more, if this patch is indeed
at the right spot.  If this box doesn't panic anymore we'll know it'll have
nailed it.  Do you want me to get back to you tonight after 8PM in case this
box hasn't paniced again?

Best Regards,
-peter


> 
> Index: net/pfkeyv2.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/net/pfkeyv2.c,v
> retrieving revision 1.179
> diff -u -p -r1.179 pfkeyv2.c
> --- net/pfkeyv2.c 16 May 2018 13:19:00 -  1.179
> +++ net/pfkeyv2.c 19 May 2018 11:50:53 -
> @@ -381,12 +381,15 @@ pfkey_sendup(struct keycb *kp, struct mb
>   } else
>   m = m0;
>  
> + KERNEL_LOCK()
>   if (!sbappendaddr(so, >so_rcv, _addr, m, NULL)) {
>   m_freem(m);
> + KERNEL_UNLOCK();
>   return (ENOBUFS);
>   }
>  
>   sorwakeup(so);
> + KERNEL_UNLOCK();
>   return (0);
>  }
>

Re: Panic in IPSEC

2018-05-19 Thread Peter J. Philipp 
On Sat, May 19, 2018 at 02:02:35PM +0200, Alexander Bluhm wrote:
> On Sat, May 19, 2018 at 12:57:19PM +0200, Peter J. Philipp wrote:
> > panic: kernel diagnostic assertion...(cut)
> 
> This is an important line.
> panic: kernel diagnostic assertion "_kernel_lock_held()" failed in file "/us
> Then the photo is cut, but I can guess what is next.

It just panic'ed again 5 min ago.  I took another photo this time made sure 
that the full screen is in the visor.  I can send it hold on, let me extract it 
from my phone... done:

http://centroid.eu/private/p5190002.jpg

hopefully it doesn't panic again while I write this.  I'm going to attempt
testing your patch, given it doesn't panic. 

Thanks!
-peter


> > soassertlocked(815c8c03) at soassertlocked+0x73
> > sorwakeup(800032d930c8) at sorwakeup+0xf
> > pfkeyv2_sendmessage(b0, 
> > 80137c00,4,8124d700,800032d93128,2aa6da05f83cead1) at 
> > pfkeyv2_sendmessage+0x20b
> 
> I would say as long we have no per socket locking, we must grab
> either net lock or kernel lock when accessing the socket.  For pf
> key sockets it is kernel lock, so just add it there.
> 
> bluhm
> 
> Index: net/pfkeyv2.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/net/pfkeyv2.c,v
> retrieving revision 1.179
> diff -u -p -r1.179 pfkeyv2.c
> --- net/pfkeyv2.c 16 May 2018 13:19:00 -  1.179
> +++ net/pfkeyv2.c 19 May 2018 11:50:53 -
> @@ -381,12 +381,15 @@ pfkey_sendup(struct keycb *kp, struct mb
>   } else
>   m = m0;
>  
> + KERNEL_LOCK()
>   if (!sbappendaddr(so, >so_rcv, _addr, m, NULL)) {
>   m_freem(m);
> + KERNEL_UNLOCK();
>   return (ENOBUFS);
>   }
>  
>   sorwakeup(so);
> + KERNEL_UNLOCK();
>   return (0);
>  }
>

Re: Panic in IPSEC

2018-05-19 Thread Alexander Bluhm 
On Sat, May 19, 2018 at 12:57:19PM +0200, Peter J. Philipp wrote:
> panic: kernel diagnostic assertion...(cut)

This is an important line.
panic: kernel diagnostic assertion "_kernel_lock_held()" failed in file "/us
Then the photo is cut, but I can guess what is next.

> soassertlocked(815c8c03) at soassertlocked+0x73
> sorwakeup(800032d930c8) at sorwakeup+0xf
> pfkeyv2_sendmessage(b0, 
> 80137c00,4,8124d700,800032d93128,2aa6da05f83cead1) at 
> pfkeyv2_sendmessage+0x20b

I would say as long we have no per socket locking, we must grab
either net lock or kernel lock when accessing the socket.  For pf
key sockets it is kernel lock, so just add it there.

bluhm

Index: net/pfkeyv2.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/net/pfkeyv2.c,v
retrieving revision 1.179
diff -u -p -r1.179 pfkeyv2.c
--- net/pfkeyv2.c   16 May 2018 13:19:00 -  1.179
+++ net/pfkeyv2.c   19 May 2018 11:50:53 -
@@ -381,12 +381,15 @@ pfkey_sendup(struct keycb *kp, struct mb
} else
m = m0;
 
+   KERNEL_LOCK()
if (!sbappendaddr(so, >so_rcv, _addr, m, NULL)) {
m_freem(m);
+   KERNEL_UNLOCK();
return (ENOBUFS);
}
 
sorwakeup(so);
+   KERNEL_UNLOCK();
return (0);
 }

Panic in IPSEC

2018-05-19 Thread Peter J. Philipp 
>Synopsis:  unexpected panic in IPSEC on -current snapshot from today
>Category:  kernel
>Environment:
System  : OpenBSD 6.3
Details : OpenBSD 6.3-current (GENERIC.MP) #40: Fri May 18 09:57:33 
MDT 2018
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
>Description:
I don't know what happened my box paniced.  I took a photo of the
monitor and tried getting it rebooted with "boot reboot" but it hung.
So I am basing this off the photo.


panic: kernel diagnostic assertion...(cut)
WARNING: SPL NOT LOWERED ON SYSCALL 0 4 EXIT 37a...(cut)
WARNING: SPL NOT LOWERED ON SYSCALL 0 4 EXIT 37a7ba...(cut)
TID PID UID PRFLAGS PFLAGS  CPU COMMAND
... 3   firefox
... 4   pflogd
... 1   crypto
*243695 44474 0 0x14000 0x200   2   softnet
db_enter() at db_enter+0x5
panic() at panic+0x120
__assert(ff81909c94, 800032d93050,f00cbebc100,fff0724a7a638) at 
__assert+0x24
soassertlocked(815c8c03) at soassertlocked+0x73
sorwakeup(800032d930c8) at sorwakeup+0xf
pfkeyv2_sendmessage(b0, 
80137c00,4,8124d700,800032d93128,2aa6da05f83cead1) at 
pfkeyv2_sendmessage+0x20b
pfkeyv2_expire(80137c00,10) at pfkeyv2_expire+0x1eb
esp_input(80137c00,ff00aefafb00,28,32) at esp_input+0x2ad
ipsec_common_input(18,800032d93440,6,800032d9343c,32,2aa6da05f83cead1) 
at ipsec_common_input+0x6a4
esp6_input(18,fff81b0d0c0,18,32) at esp6_input+0x15a
ip_deliver(800032d9344c,800032d9343c,80027040,800032d93440) 
at ip_deliver+0x203
ip6intr() at ip6intr+0x7b
if_netisr(fff8138e830) at if_netisr+0x6c
taskq_thread(0) at taskq_thread+0x6d
end trace frame: 0x0, count: 1
https://www.openbsd.org/ddb.html describes the unreachable info required in bug
reports.  Insufficient ifo makes it difficult to find and fix bugs.
ddb{2}>

I'm putting the photo at http://centroid.eu/private/p5190001.jpg in a 
second it could take a minute to propagate.

Thanks!
>How-To-Repeat:
Unknown.  My setup is weird as it uses IPSEC over freifunk. 
>Fix:
Unknown.


dmesg:
OpenBSD 6.3-current (GENERIC.MP) #40: Fri May 18 09:57:33 MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 34208063488 (32623MB)
avail mem = 33163272192 (31626MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec1f0 (91 entries)
bios0: vendor American Megatrends Inc. version "2004" date 06/05/2014
bios0: ASUS All Series
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT LPIT SSDT SSDT MCFG HPET SSDT SSDT BGRT DMAR
acpi0: wakeup devices PXSX(S4) RP01(S4) PXSX(S4) PXSX(S4) RP03(S4) PXSX(S4) 
PXSX(S4) PXSX(S4) RP06(S4) PXSX(S4) PXSX(S4) RP08(S4) UAR1(S4) PS2K(S4) 
GLAN(S4) EHC1(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E3-1275 v3 @ 3.50GHz, 3498.41 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E3-1275 v3 @ 3.50GHz, 3497.98 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU E3-1275 v3 @ 3.50GHz, 3497.98 MHz
cpu2:

arm64: clock_gettime(CLOCK_MONOTONIC) not monotonic

2018-05-19 Thread Sebastien Marie 
Hi,

Working on lang/rust on arm64, I experiment rustc panic due to not
monotonic timestamp. I tried to reproduce the problem in plain C.

My test program is just a loop of calling
clock_gettime(CLOCK_MONOTONIC), and it checks if the result is monotonic
(by comparing with previous value).

On amd64, it seems to work well, but on arm64 it fails quickly.


$ cat monotonic.c

#include 
#include 
#include 

void
ts_abort(struct timespec *ts0, struct timespec *ts1)
{
printf("ts0=(%llu,%lu)\nts1=(%llu,%lu)\n",
ts0->tv_sec, ts0->tv_nsec,
ts1->tv_sec, ts1->tv_nsec);
abort();
}

int
main(int argc, char *argv[])
{
struct timespec ts0, ts1;

clock_gettime(CLOCK_MONOTONIC, );
for(;;) {
clock_gettime(CLOCK_MONOTONIC, );

if ((ts0.tv_sec < ts1.tv_sec) ||
((ts0.tv_sec == ts1.tv_sec) &&
 (ts0.tv_nsec < ts1.tv_nsec))) {
ts0.tv_sec  = ts1.tv_sec;
ts0.tv_nsec = ts1.tv_nsec;
} else
ts_abort(, );
}
}

$ cc -g -Wall monotonic.c
$ time ./a.out
ts0=(485220,477812476)
ts1=(485220,477728098)
Abort trap (core dumped)

ts0 should be <= ts1 if the result was monotonic.

dmesg below.

Thanks.
-- 
Sebastien Marie


OpenBSD 6.3-current (GENERIC) #281: Sat May 12 13:30:59 MDT 2018
dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC
real mem  = 2021466112 (1927MB)
avail mem = 1927958528 (1838MB)
mainbus0 at root: Pine64+
cpu0 at mainbus0 mpidr 0: ARM Cortex-A53 r0p4
efi0 at mainbus0: UEFI 2.7
efi0: Das U-Boot rev 0x0
psci0 at mainbus0: PSCI 0.2
agtimer0 at mainbus0: tick rate 24000 KHz
simplebus0 at mainbus0: "soc"
sxiccmu0 at simplebus0
sxipio0 at simplebus0: 103 pins
ampintc0 at simplebus0 nirq 224, ncpu 4: "interrupt-controller"
sxiccmu1 at simplebus0
sxipio1 at simplebus0: 13 pins
sximmc0 at simplebus0
sdmmc0 at sximmc0: 4-bit, sd high-speed, mmc high-speed, dma
ehci0 at simplebus0
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Generic EHCI root hub" rev 2.00/1.00 
addr 1
com0 at simplebus0: ns16550, no working fifo
com0: console
sxitwi0 at simplebus0
iic0 at sxitwi0
sxirtc0 at simplebus0
dwxe0 at simplebus0: address 02:ba:b0:1b:de:88
rgephy0 at dwxe0 phy 0: RTL8169S/8110S/8211 PHY, rev. 5
rgephy1 at dwxe0 phy 1: RTL8169S/8110S/8211 PHY, rev. 5
gpio0 at sxipio0: 32 pins
gpio1 at sxipio0: 32 pins
gpio2 at sxipio0: 32 pins
gpio3 at sxipio0: 32 pins
gpio4 at sxipio0: 32 pins
gpio5 at sxipio0: 32 pins
gpio6 at sxipio0: 32 pins
gpio7 at sxipio0: 32 pins
gpio8 at sxipio1: 32 pins
scsibus0 at sdmmc0: 2 targets, initiator 0
sd0 at scsibus0 targ 1 lun 0:  SCSI2 0/direct removable
sd0: 15080MB, 512 bytes/sector, 30883840 sectors
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
bootfile: sd0a:/bsd
boot device: sd0
root on sd0a (058b644e509a3f31.a) swap on sd0b dump on sd0b