Re: Remove manpage references to sparc

2019-11-04 Thread Jason McIntyre
On Sun, Nov 03, 2019 at 03:37:43PM +, Joe Davis wrote: > sparc support hasn't existed for 6 releases, the following diff removes > some remaining references to sun4c and sun4e machines in the manpages. > > Cheers, > Joe > fixed, thanks. jmc > Index: hme.4 >

Re: sysupgrade(8) and http_proxy

2019-11-04 Thread trondd
Steffen Nurpmeso wrote: > trondd wrote in <49f29107642e86c17283b0582a9f09f4.squir...@mail.kagu-tsu\ > chi.com>: > |On Sun, November 3, 2019 12:02 pm, trondd wrote: > |> On Sun, November 3, 2019 6:27 am, Florian Obser wrote: > |>> On Sun, Nov 03, 2019 at 12:21:59PM +0100, Antoine Jacoutot

use designators for array initialiser in src/sys/netinet/in.h CTL_IPPROTO_NAMES

2019-11-04 Thread David Gwynne
this makes it harder to mess up the assignment of a protocol to the right slot in the CTL_IPPROTO_NAMES initialiser. it also shrinks the code a lot, and i think it makes what the array index means a lot more explicit. this gets used in sysctl(8), which still works as expected after this change.

Re: sysupgrade(8) and http_proxy

2019-11-04 Thread Steffen Nurpmeso
trondd wrote in <49f29107642e86c17283b0582a9f09f4.squir...@mail.kagu-tsu\ chi.com>: |On Sun, November 3, 2019 12:02 pm, trondd wrote: |> On Sun, November 3, 2019 6:27 am, Florian Obser wrote: |>> On Sun, Nov 03, 2019 at 12:21:59PM +0100, Antoine Jacoutot wrote: |>>> On Sun, Nov 03, 2019 at

use tasks and a task_list to manage if_detachhooks

2019-11-04 Thread David Gwynne
hook_establish can fail, but drivers are inconsistent about checking for that. apparently there's also a requirement that detach hooks are run in opposite order to the one they were established in, but that is also applied inconsistently by drivers. this replaces if_detachhooks with a task_list,

Re: sysupgrade(8) and http_proxy

2019-11-04 Thread trondd
On Sun, November 3, 2019 12:02 pm, trondd wrote: > On Sun, November 3, 2019 6:27 am, Florian Obser wrote: >> On Sun, Nov 03, 2019 at 12:21:59PM +0100, Antoine Jacoutot wrote: >>> On Sun, Nov 03, 2019 at 12:16:56PM +0100, Florian Obser wrote: >>> > I like it, if someone who is fluent in ksh line

Re: ospfd: type p2p

2019-11-04 Thread Remi Locherer
On Mon, Nov 04, 2019 at 02:01:57PM +0200, Kapetanakis Giannis wrote: > On 25/10/2019 13:57, Remi Locherer wrote: > > Hi tech@, > > > > earlier this year I sent a diff that allowed to change an interface > > from broadcast to point-to-point. > > > >

rwlock(9): xr rwsleep(9)

2019-11-04 Thread Anton Lindqvist
ok? Index: rwlock.9 === RCS file: /cvs/src/share/man/man9/rwlock.9,v retrieving revision 1.24 diff -u -p -r1.24 rwlock.9 --- rwlock.925 Feb 2019 22:03:56 - 1.24 +++ rwlock.94 Nov 2019 14:25:19 - @@ -238,6 +238,7

Re: ix(4) need support for X553

2019-11-04 Thread Joerg Goltermann
Hello, thank you so much, I did some tests with my X553 and the system survived all of my tests. Running tcpbench and unplugging the cables several times, ifconfig down & up. I think, the performance looks good too: cpu0 at mainbus0: apid 4 (boot processor) cpu0: Intel(R) Atom(TM) CPU C3558 @

Re: iwm: support new umac scan API

2019-11-04 Thread Stefan Sperling
On Mon, Nov 04, 2019 at 09:06:03AM -0700, Tracey Emery wrote: > On Mon, Nov 04, 2019 at 04:56:14PM +0100, Stefan Sperling wrote: > > If you want to test -34 you can copy the -34 firmware file on top of > > the -22 file. (Keep a backup!) > > > > Alternatively, you could change the filename the

Re: iwm: support new umac scan API

2019-11-04 Thread Tracey Emery
On Mon, Nov 04, 2019 at 04:56:14PM +0100, Stefan Sperling wrote: > If you want to test -34 you can copy the -34 firmware file on top of > the -22 file. (Keep a backup!) > > Alternatively, you could change the filename the driver will look for. > The lines in if_iwm.c which would need to be

Re: iwm: support new umac scan API

2019-11-04 Thread Stefan Sperling
On Mon, Nov 04, 2019 at 08:31:07AM -0700, Tracey Emery wrote: > Both diffs work fine here. However, it appears I'm still only loading > the -22 firmware: > > iwm0: hw rev 0x230, fw ver 22.391740.0 > > Am I missing something obvious to get it to load the -34 firmware, or do > the two work in

Re: iwm: support new umac scan API

2019-11-04 Thread Tracey Emery
Both diffs work fine here. However, it appears I'm still only loading the -22 firmware: iwm0: hw rev 0x230, fw ver 22.391740.0 Am I missing something obvious to get it to load the -34 firmware, or do the two work in conjunction? I tried moving the -22 firmware out of the way, but that caused a

iwm: support new umac scan API

2019-11-04 Thread Stefan Sperling
This diff adds support for new iwm firmare's umac scan API. It is required to make scanning work on -34 firmware. Combined with the 'new ADD_STA' diff I just sent out, this is the last change we need to get -34 firmware working. This adds a couple of lines under #ifdef notyet for ax200 devices

iwm: support new ADD_STA command

2019-11-04 Thread Stefan Sperling
Add support for the new ADD_STA command API. Required for -34 firmware. The significant changes are that the purpose of each STA in the firmware table is now identified by an 'STA type' flag, and that the Rx block ack window size is now specified in the command. The layout is backwards

Re: ospfd: type p2p

2019-11-04 Thread Kapetanakis Giannis
On 25/10/2019 13:57, Remi Locherer wrote: > Hi tech@, > > earlier this year I sent a diff that allowed to change an interface > from broadcast to point-to-point. > > https://marc.info/?l=openbsd-tech=156132923203704=2 > > It turned out that this was not sufficient. It made the adjacency > come up

Re: [PATCH] remove sysctl net.mpls.maxloop_inkernel

2019-11-04 Thread thomas
(adding claudio as the most recent contributor) As per https://marc.info/?l=openbsd-misc=157191651123338=2 this is no longer used and can be removed. Before: $ sysctl -a | grep mpls net.mpls.ttl=255 net.mpls.maxloop_inkernel=16 net.mpls.mapttl_ip=1 net.mpls.mapttl_ip6=0 After: $ sysctl -a |