Re: fec(4) mii_tick

[Jonathan Gray]

On Wed, Sep 21, 2016 at 02:23:57PM +0200, Mark Kettenis wrote:
> > Date: Wed, 21 Sep 2016 21:42:36 +1000
> > From: Jonathan Gray 
> > 
> > On Wed, Sep 21, 2016 at 01:22:04PM +0200, Mark Kettenis wrote:
> > > Here is the promised diff that makes fec(4) call mii_tick() like all
> > > our other ethernet drivers that use mii do.
> > > 
> > > Does this fix your problem Philip?
> > 
> > Isn't this missing a call to timeout_add_sec() outside of
> > fec_tick()?
> 
> Right.  Updated diff (for real now).

ok jsg@

> 
> Index: sys/arch/armv7/imx/if_fec.c
> ===
> RCS file: /cvs/src/sys/arch/armv7/imx/if_fec.c,v
> retrieving revision 1.17
> diff -u -p -r1.17 if_fec.c
> --- sys/arch/armv7/imx/if_fec.c   21 Sep 2016 10:28:47 -  1.17
> +++ sys/arch/armv7/imx/if_fec.c   21 Sep 2016 12:16:28 -
> @@ -231,6 +231,7 @@ struct fec_softc {
>   struct fec_buffer   *rx_buffer_base;
>   int cur_tx;
>   int cur_rx;
> + struct timeout  sc_tick;
>  };
>  
>  struct fec_softc *fec_sc;
> @@ -249,6 +250,7 @@ void fec_iff(struct fec_softc *);
>  struct mbuf * fec_newbuf(void);
>  int fec_intr(void *);
>  void fec_recv(struct fec_softc *);
> +void fec_tick(void *);
>  int fec_miibus_readreg(struct device *, int, int);
>  void fec_miibus_writereg(struct device *, int, int, int);
>  void fec_miibus_statchg(struct device *);
> @@ -430,6 +432,8 @@ fec_attach(struct device *parent, struct
>   ether_ifattach(ifp);
>   splx(s);
>  
> + timeout_set(>sc_tick, fec_tick, sc);
> +
>   fec_sc = sc;
>   return;
>  
> @@ -672,6 +676,8 @@ fec_init(struct fec_softc *sc)
>   /* program promiscuous mode and multicast filters */
>   fec_iff(sc);
>  
> + timeout_add_sec(>sc_tick, 1);
> +
>   /* Indicate we are up and running. */
>   ifp->if_flags |= IFF_RUNNING;
>   ifq_clr_oactive(>if_snd);
> @@ -694,6 +700,8 @@ fec_stop(struct fec_softc *sc)
>   ifp->if_timer = 0;
>   ifq_clr_oactive(>if_snd);
>  
> + timeout_del(>sc_tick);
> +
>   /* reset the controller */
>   HSET4(sc, ENET_ECR, ENET_ECR_RESET);
>   while(HREAD4(sc, ENET_ECR) & ENET_ECR_RESET);
> @@ -966,6 +974,19 @@ done:
>   HWRITE4(sc, ENET_RDAR, ENET_RDAR_RDAR);
>  
>   if_input(ifp, );
> +}
> +
> +void
> +fec_tick(void *arg)
> +{
> + struct fec_softc *sc = arg;
> + int s;
> +
> + s = splnet();
> + mii_tick(>sc_mii);
> + splx(s);
> +
> + timeout_add_sec(>sc_tick, 1);
>  }
>  
>  /*
> 

steinberg/yamaha ur22 audio device + openbsd 6.0

[Michael W. Bombardieri]

Hi tech,

I had some success using Yamaha/Steinberg UR22 usb audio
interface box on OpenBSD/i386 6.0.
I heard that Linux supports the device but I never tested it under Linux.
I spent AUD $150 on the device last year and wondered if it could ever
be used with OpenBSD aucat(1).

The USB-quirks patch (below) allows UR22 to attach as uaudio device.
Patch was originally built against current kernel checked out a few days ago.
I've re-applied it against uaudio.c r1.115.
Regenerating usbdevs.h/usbdevs_data.h isn't included in patch.

I also own Creative Soundblaster X-Fi usb soundcard;
this worked on OpenBSD for some time but I wouldn't use it for recording.

Configuration:
* Test PC is "bios0: Compaq-Presario KJ335AA-ABG SR5490AN"
* UR22 audio input 1 connected to AKG P120 microphone via XLR cable
* UR22 audio input 2 connected to electric guitar via instrument cable
* Hi-Z toggle is enabled for input 2 on front panel
* +48V "phantom power" toggle is enabled for input 1 on back panel
* UR22 is attached directly to PC via USB cable (no intermediate hubs)
* label on front panel says "24-bit / 192 kHz"
* white "status" LED on front panel is solid (stops flashing when uaudio 
attaches)
* no speakers attached to line output (L/R) on back panel
* i am listening to audio playback via headphone jack on front panel
* headphone jack is also used for monitoring audio inputs 1 & 2

Simple playback:
* "aucat -i stereo48khz.wav" plays file ok

Stereo record (default encoding of s16):
* aucat -r $RATE -o test.wav
...with the following rates: 44100 48000 64000 96000 112000 192000
* all recorded files play back ok

Stereo record (different encoding):
* i'm fairly sure i have recorded in 24-bit mode under M$ Windows 8
* aucat -r 44100 -e s24le3 -o test.wav # caused segmentation fault
* also tried aucat with "-h raw" but it still dies
* audioctl reports encoding=s24le3 so i am confused
* i need to compile non-stripped aucat to see more

Other tests performed:
* Two concurrent instances of aucat; one recording, one playing
* Two concurrent instances of aucat; both playing
* One instance of aucat (record+play): aucat -r 96000 -i in.wav -o out.wav
* One instance of aucat (play+play): aucat -i in.wav -i out.wav

TODO:
* re-test on another PC, and on amd64
* determine why aucat segfaults for 24bit encodings (above)
* test umidi with this device (attaches successfully on unmodified 6.0 kernel)
* phone grandmother with voip/sip software and play guitar down the line?

- Michael


Index: uaudio.c
===
RCS file: /cvs/src/sys/dev/usb/uaudio.c,v
retrieving revision 1.115
diff -u -r1.115 uaudio.c
--- uaudio.c19 Sep 2016 06:46:44 -  1.115
+++ uaudio.c22 Sep 2016 01:13:04 -
@@ -177,6 +177,8 @@
struct usb_devno uv_dev;
int  flags;
 } uaudio_devs[] = {
+   { { USB_VENDOR_YAMAHA, USB_PRODUCT_YAMAHA_UR22 },
+   UAUDIO_FLAG_VENDOR_CLASS },
{ { USB_VENDOR_ALTEC, USB_PRODUCT_ALTEC_ADA70 },
UAUDIO_FLAG_BAD_ADC } ,
{ { USB_VENDOR_ALTEC, USB_PRODUCT_ALTEC_ASC495 },
Index: usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.669
diff -u -r1.669 usbdevs
--- usbdevs 21 Sep 2016 08:55:21 -  1.669
+++ usbdevs 22 Sep 2016 01:13:05 -
@@ -4443,6 +4443,7 @@
 product YEDATA FLASHBUSTERU0x  Flashbuster-U
 
 /* Yamaha products */
+product YAMAHA UR220x1509  UR22
 product YAMAHA UX256   0x1000  UX256 MIDI I/F
 productYAMAHA UX96 0x1008  UX96 MIDI I/F
 product YAMAHA RPU200  0x3104  RP-U200

Minor improvement to socket(2) man page

[Michael McConville]

The current version is somewhat awkward and forgets to mention that
errno is set. I adapted the paragraph found in most other system call
man pages.

Thanks for your time,
Mike


Index: lib/libc/sys/socket.2
===
RCS file: /cvs/src/lib/libc/sys/socket.2,v
retrieving revision 1.41
diff -u -p -u -r1.41 socket.2
--- lib/libc/sys/socket.2   19 Mar 2016 22:10:49 -  1.41
+++ lib/libc/sys/socket.2   22 Sep 2016 01:20:30 -
@@ -219,8 +219,11 @@ and
 .Xr getsockopt 2
 are used to set and get options, respectively.
 .Sh RETURN VALUES
-A \-1 is returned if an error occurs, otherwise the return
-value is a descriptor referencing the socket.
+Upon successful completion, a descriptor referencing the socket is
+returned. Otherwise, the value \-1 is returned and the global
+variable
+.Va errno
+is set to indicate the error.
 .Sh ERRORS
 The
 .Fn socket

syslogd tcp socket buffer size

[Alexander Bluhm]

Hi,

With the new large socket buffer sizes, syslogd could use more mbufs
for TCP or TLS connections than before.  It makes no sense to buffer
messages in kernel, the dynamic limit there makes testing the dropped
message statistics unreliable.  Syslog has no high performance
requirements, so limit all TCP socket buffers to 64 KB.

ok?

bluhm

Index: syslogd.c
===
RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/syslogd/syslogd.c,v
retrieving revision 1.213
diff -u -p -r1.213 syslogd.c
--- syslogd.c   21 Sep 2016 11:54:57 -  1.213
+++ syslogd.c   21 Sep 2016 23:22:08 -
@@ -343,6 +343,7 @@ int socket_bind(const char *, const char
 int *, int *);
 intunix_socket(char *, int, mode_t);
 void   double_sockbuf(int, int);
+void   set_sockbuf(int);
 void   tailify_replytext(char *, int);
 
 int
@@ -886,6 +887,10 @@ socket_bind(const char *proto, const cha
*fdp = -1;
continue;
}
+   if (!shutread && res->ai_protocol == IPPROTO_UDP)
+   double_sockbuf(*fdp, SO_RCVBUF);
+   else if (res->ai_protocol == IPPROTO_TCP)
+   set_sockbuf(*fdp);
reuseaddr = 1;
if (setsockopt(*fdp, SOL_SOCKET, SO_REUSEADDR, ,
sizeof(reuseaddr)) == -1) {
@@ -916,8 +921,6 @@ socket_bind(const char *proto, const cha
*fdp = -1;
continue;
}
-   if (!shutread && res->ai_protocol == IPPROTO_UDP)
-   double_sockbuf(*fdp, SO_RCVBUF);
}
 
freeaddrinfo(res0);
@@ -1257,6 +1260,7 @@ tcp_socket(struct filed *f)
logerror(ebuf);
return (-1);
}
+   set_sockbuf(s);
if (connect(s, (struct sockaddr *)>f_un.f_forw.f_addr,
f->f_un.f_forw.f_addr.ss_len) == -1 && errno != EINPROGRESS) {
snprintf(ebuf, sizeof(ebuf), "connect \"%s\"",
@@ -2909,6 +2913,17 @@ double_sockbuf(int fd, int optname)
if (setsockopt(fd, SOL_SOCKET, optname, , len) == -1)
logerror("setsockopt bufsize");
}
+}
+
+void
+set_sockbuf(int fd)
+{
+   int size = 65536;
+
+   if (setsockopt(fd, SOL_SOCKET, SO_SNDBUF, , sizeof(size)) == -1)
+   logerror("setsockopt sndbufsize");
+   if (setsockopt(fd, SOL_SOCKET, SO_RCVBUF, , sizeof(size)) == -1)
+   logerror("setsockopt rcvbufsize");
 }
 
 void

Re: rtadvd: no need for float defines

[Jeremie Courreges-Anglas]

Florian Obser  writes:

> OK?

ok jca@, I don't think that the opposite direction (fully handling those
values as floats) is worth the trouble.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: rtadvd: consistently use MAX_ prefix

[Jeremie Courreges-Anglas]

Florian Obser  writes:

> OK?

Looks better, but are still discrepancies (eg MAX_ROUTERLIFETIME vs.
MAX_ROUTER_LIFETIME).  I don't think we care much, though... ok jca@

$ grep -e MIN -e MAX rtadvd.h
#define DEF_MAXRTRADVINTERVAL 600
#define MAX_ROUTERLIFETIME 9000
#define MIN_MAXINTERVAL 4
#define MAX_MAXINTERVAL 1800
#define MIN_MININTERVAL 3
#define MAX_REACHABLETIME 360
#define MAX_INITIAL_RTR_ADVERT_INTERVAL  16
#define MAX_INITIAL_RTR_ADVERTISEMENTS3
#define MAX_FINAL_RTR_ADVERTISEMENTS  3
#define MIN_DELAY_BETWEEN_RAS 3
#define MAX_RA_DELAY_TIME 50 /* usec */

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: alignment error rtadvd/armv7

[Jeremie Courreges-Anglas]

Martin Brandenburg  writes:

> On Sun, 18 Sep 2016, Jeremie Courreges-Anglas wrote:
>
>> Martin Brandenburg  writes:
>> 
>> > On a PandaBoard (armv7) running -current, when I run rtadvd, it crashes
>> > with a bus error shortly after printing (received a routing message). I
>> > can reproduce by sending SIGHUP to a dhclient running on the same
>> > interface.
>> >
>> > I have traced this down to the following block of code in rtadvd.c.
>> >
>> >static void
>> >rtmsg_input(void)
>> >{
>> >int n, type, ifindex = 0, plen;
>> >size_t len;
>> >char msg[2048], *next, *lim;
>> >u_char ifname[IF_NAMESIZE];
>> >struct prefix *prefix;
>> >struct rainfo *rai;
>> >struct in6_addr *addr;
>> >char addrbuf[INET6_ADDRSTRLEN];
>> >
>> > So msg is not 32-bit aligned, presumably because INET6_ADDRSTRLEN is 46.
>> > I can fix the bus error by hardcoding 48, but of course that's not
>> > right.
>> >
>> > Then msg is passed to get_next_msg (as next) where the expression
>> > rtm->rtm_hdrlen (rtm is the not-aligned msg) is the first dereference
>> > and thus the point where it crashes.
>> >
>> > I'm at the point now where I think I've found the root of the problem
>> > but don't know enough to fix it.
>> >
>> > Any thoughts?
>> 
>> Thanks for the report.
>> 
>> I guess that we could fix the rtm_* functions to work on an unaligned
>> input buffer, but an easier fix would be to just ask for a suitably
>> aligned input buffer, with malloc(3).  Does the diff below fix your
>> problem?
>
> This fixes the problem. I let it sit in debug mode for 30 minutes (which
> is far longer than it ever lasted before) through plenty of routing
> messages, and it never crashed. I will keep monitoring, but I think it's
> good.

Committed, thanks.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: LKMDIR in bsd.own.mk

[Theo Buehler]

On Wed, Sep 21, 2016 at 08:10:15PM +0200, Martin Natano wrote:
> Loadable kernel modules are gone. Ok?

i think so :)
https://marc.info/?l=openbsd-tech=141320636821630=2

> 
> natano
> 
> 
> Index: share/mk/bsd.own.mk
> ===
> RCS file: /cvs/src/share/mk/bsd.own.mk,v
> retrieving revision 1.178
> diff -u -p -r1.178 bsd.own.mk
> --- share/mk/bsd.own.mk   8 Sep 2016 18:59:49 -   1.178
> +++ share/mk/bsd.own.mk   21 Sep 2016 17:49:40 -
> @@ -73,11 +73,6 @@ DOCGRP?=   bin
>  DOCOWN?= root
>  DOCMODE?=${NONBINMODE}
>  
> -LKMDIR?= /usr/lkm
> -LKMGRP?= ${BINGRP}
> -LKMOWN?= ${BINOWN}
> -LKMMODE?=${NONBINMODE}
> -
>  LOCALEDIR?=  /usr/share/locale
>  LOCALEGRP?=  wheel
>  LOCALEOWN?=  root
> 

LKMDIR in bsd.own.mk

[Martin Natano]

Loadable kernel modules are gone. Ok?

natano


Index: share/mk/bsd.own.mk
===
RCS file: /cvs/src/share/mk/bsd.own.mk,v
retrieving revision 1.178
diff -u -p -r1.178 bsd.own.mk
--- share/mk/bsd.own.mk 8 Sep 2016 18:59:49 -   1.178
+++ share/mk/bsd.own.mk 21 Sep 2016 17:49:40 -
@@ -73,11 +73,6 @@ DOCGRP?= bin
 DOCOWN?=   root
 DOCMODE?=  ${NONBINMODE}
 
-LKMDIR?=   /usr/lkm
-LKMGRP?=   ${BINGRP}
-LKMOWN?=   ${BINOWN}
-LKMMODE?=  ${NONBINMODE}
-
 LOCALEDIR?=/usr/share/locale
 LOCALEGRP?=wheel
 LOCALEOWN?=root

Re: W^X -wxneeded backported to 6.0-stable?

[Jack J. Woehr]

Theo de Raadt wrote:

You have clients and work, so instead your spam this mailing list?

I thought it might be a known problem. OpenBSD is your whole world. It's a very 
important part
of mine, but I really can't keep up on everything that flies by on the list as 
I did 18 years ago.

And it's not spam. It's just a question. You're a very silly person, sometimes, 
Mr. de Raadt.

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

Re: bluhm's splsoftassert

[David Hill]

On Wed, Sep 21, 2016 at 12:32:50PM -0400, David Hill wrote:
> Hit another.
> 
> splassert: sorwakeup: want 5 have 0
> Starting stack trace...
> splassert_check() at splassert_check+0x78
> sorwakeup() at sorwakeup+0x27
> route_input() at route_input+0x284
> ifioctl() at ifioctl+0x765
> sys_ioctl() at sys_ioctl+0x196
> syscall() at syscall+0x27b
> --- syscall (number 54) ---
> end of kernel
> end trace frame: 0x7f7e72f0, count: 251
> 0x10044651af1a:
> End of stack trace.
>

Index: if.c
===
RCS file: /cvs/src/sys/net/if.c,v
retrieving revision 1.449
diff -u -p -r1.449 if.c
--- if.c20 Sep 2016 16:14:43 -  1.449
+++ if.c21 Sep 2016 16:51:39 -
@@ -1898,7 +1898,9 @@ ifioctl(struct socket *so, u_long cmd, c
 
ifp->if_xflags = (ifp->if_xflags & IFXF_CANTCHANGE) |
(ifr->ifr_flags & ~IFXF_CANTCHANGE);
+   s = splsoftnet();
rt_ifmsg(ifp);
+   splx(s);
break;
 
case SIOCSIFMETRIC:

Re: bluhm's splsoftassert

[David Hill]

Hit another.

splassert: sorwakeup: want 5 have 0
Starting stack trace...
splassert_check() at splassert_check+0x78
sorwakeup() at sorwakeup+0x27
route_input() at route_input+0x284
ifioctl() at ifioctl+0x765
sys_ioctl() at sys_ioctl+0x196
syscall() at syscall+0x27b
--- syscall (number 54) ---
end of kernel
end trace frame: 0x7f7e72f0, count: 251
0x10044651af1a:
End of stack trace.

Re: W^X -wxneeded backported to 6.0-stable?

[Theo de Raadt]

>Theo de Raadt wrote:
>> In other words, it is pretty simple -- reinstall, and prove reproducibility. 
>
>I have clients and work to do. Did this all on a Sunday night.

You have clients and work, so instead your spam this mailing list?

That is the problem: Selfishness.

Re: W^X -wxneeded backported to 6.0-stable?

[Theo de Raadt]

>Theo de Raadt wrote:
>> In other words, it is pretty simple -- reinstall, and prove reproducibility. 
>
>I have clients and work to do. Did this all on a Sunday night.
>
>> And frankly, doing your entire system as /, should almost be an unsupported 
>> option. It is a ridiculous configuration 
>> for about 20 reasons. 
>
>Mais oui, m'sieu. Was my first try at whole-disk encryption. Next time I build 
>a new machine, I'll do it right.

That has nothing to do with having one / partition, via many partitions.

And secondly when it is the first try, and flaws become evident, why
keep digging a deeper hole.

Even the sorries become noise.

Re: W^X -wxneeded backported to 6.0-stable?

[Jack J. Woehr]

Theo de Raadt wrote:
In other words, it is pretty simple -- reinstall, and prove reproducibility. 


I have clients and work to do. Did this all on a Sunday night.

And frankly, doing your entire system as /, should almost be an unsupported option. It is a ridiculous configuration 
for about 20 reasons. 


Mais oui, m'sieu. Was my first try at whole-disk encryption. Next time I build 
a new machine, I'll do it right.

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

Re: W^X -wxneeded backported to 6.0-stable?

[Jack J. Woehr]

Stuart Henderson wrote:

In 6.0 the packages for these did not have WXNEEDED annotations so
they would trigger the log, however the kernel did not enforce it on
wxallowed fs. So it expected to see this in dmesg but it is not expected
for them to die for this reason


Thanks, Stuart. Some Java stuff certainly seems to behave oddly. TN5250J hangs 
on exit sometimes.
Some NetBeans windows behave differently than they did on 5.9. But I'm getting 
work done, so I'm
reasonably happy. ("What? Did you want him to be *unreasonably* happy?" - 
George Carlin)

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

Re: W^X -wxneeded backported to 6.0-stable?

[Stuart Henderson]

On 2016/09/21 09:49, Jack J. Woehr wrote:
> As noted on the ports mailing list, after 6.0 upgrade/cvs source/build 
> kernel/build world/pkg_add -u I am experiencing
> wx violations on a single whole-disk label mounted as / wxallowed.

I see no changes between 6.0 and 6.0-stable in this area.


> Solène Rapenne  posted:
> 
> > On -current binaries now needs both wxallowed on their mountpoint AND have 
> > to be compiled with -wxneeded flag.
> > 
> > Maybe this has been backported to 6.0-stable ? I don't know where to
> > look to check that. Maybe someone have a clue ?
> 
> Any tips?
> 
> Example errors from dmesg:
> 
> seamonkey(89184): mmap W^X violation
> java(79321): mprotect W^X violation

In 6.0 the packages for these did not have WXNEEDED annotations so
they would trigger the log, however the kernel did not enforce it on
wxallowed fs. So it expected to see this in dmesg but it is not expected
for them to die for this reason.

In -current after 6.0 the kernel enforced it strictly for non-WXNEEDED
executables for a while and killed the process if it made any W|X map
requests.

In ports-land after this, many ports gained WXNEEDED annotations so
they would run normally and not print a message.

After that (and still present) this changed to failing W|X map
requests and logging, but not killing the process. In some cases they
will accept the failure and handle it gracefully; in most cases they
won't. Again those executables with WXNEEDED annotations work
normally if they are on a "wxallowed" filesystem..


> Output of mount command:
> 
> /dev/sd1a on / type ffs (local, wxallowed)
> 
> Output of dmesg command:
> 
> OpenBSD 6.0-stable (GENERIC.MP) #0: Sun Sep 18 20:37:21 MDT 2016
> jax@varian.jaxrcfb:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8553762816 (8157MB)
> avail mem = 8290054144 (7906MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xeb040 (17 entries)
> bios0: vendor American Megatrends Inc. version "R0200V3" date 02/10/2011
> bios0: Sony Corporation VPCF215FX
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC HPET SLIC MCFG SSDT SSDT ECDT SSDT
> acpi0: wakeup devices PEG0(S4) B0D4(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3)
> USB5(S3) USB6(S3) USB7(S3) HDEF(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4)
> PXSX(S4) RP03(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) Core(TM) i7-2630QM CPU @ 2.00GHz, 1995.76 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
> 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.1.2, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz, 1995.47 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
> 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) Core(TM) i7-2630QM CPU @ 2.00GHz, 1995.47 MHz
> cpu2: 
> 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 6 (application processor)
> cpu3: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz, 1995.47 MHz
> cpu3: 
> 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
> cpu3: 256KB 64b/line 8-way L2 cache
> cpu3: smt 0, core 3, package 0
> cpu4 at mainbus0: apid 1 (application processor)
> cpu4: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz, 1995.47 MHz
> cpu4: 
> 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
> cpu4: 256KB 64b/line 8-way L2 cache
> cpu4: smt 1, core 0, package 0
> cpu5 at 

Re: W^X -wxneeded backported to 6.0-stable?

[Theo de Raadt]

> On 2016/09/21 09:49, Jack J. Woehr wrote:
> > As noted on the ports mailing list, after 6.0 upgrade/cvs source/build =
> kernel/build world/pkg_add -u I am experiencing
> > wx violations on a single whole-disk label mounted as / wxallowed.
> 
> I see no changes between 6.0 and 6.0-stable in this area.
> 
> 
> > Sol=E8ne Rapenne  posted:
> >=20
> > > On -current binaries now needs both wxallowed on their mountpoint AND=
>  have to be compiled with -wxneeded flag.
> > >=20
> > > Maybe this has been backported to 6.0-stable ? I don't know where to
> > > look to check that. Maybe someone have a clue ?
> >=20
> > Any tips?
> >=20
> > Example errors from dmesg:
> >=20
> > seamonkey(89184): mmap W^X violation
> > java(79321): mprotect W^X violation
> 
> In 6.0 the packages for these did not have WXNEEDED annotations so
> they would trigger the log, however the kernel did not enforce it on
> wxallowed fs. So it expected to see this in dmesg but it is not expected
> for them to die for this reason.
> 
> In -current after 6.0 the kernel enforced it strictly for non-WXNEEDED
> executables for a while and killed the process if it made any W|X map
> requests.
> 
> In ports-land after this, many ports gained WXNEEDED annotations so
> they would run normally and not print a message.
> 
> After that (and still present) this changed to failing W|X map
> requests and logging, but not killing the process. In some cases they
> will accept the failure and handle it gracefully; in most cases they
> won't. Again those executables with WXNEEDED annotations work
> normally if they are on a "wxallowed" filesystem..
> 
> 
> > Output of mount command:
> >=20
> > /dev/sd1a on / type ffs (local, wxallowed)
> >=20
> > Output of dmesg command:
> >=20
> > OpenBSD 6.0-stable (GENERIC.MP) #0: Sun Sep 18 20:37:21 MDT 2016
> > jax@varian.jaxrcfb:/usr/src/sys/arch/amd64/compile/GENERIC.MP

In other words, it is pretty simple -- reinstall, and prove reproducibility.

And frankly, doing your entire system as /, should almost be an
unsupported option.  It is a ridiculous configuration for about 20
reasons.

W^X -wxneeded backported to 6.0-stable?

[Jack J. Woehr]

As noted on the ports mailing list, after 6.0 upgrade/cvs source/build 
kernel/build world/pkg_add -u I am experiencing
wx violations on a single whole-disk label mounted as / wxallowed.

Solène Rapenne  posted:


On -current binaries now needs both wxallowed on their mountpoint AND have to 
be compiled with -wxneeded flag.

Maybe this has been backported to 6.0-stable ? I don't know where to look to check that. Maybe someone have a clue ? 


Any tips?

Example errors from dmesg:

seamonkey(89184): mmap W^X violation
java(79321): mprotect W^X violation

Output of mount command:

/dev/sd1a on / type ffs (local, wxallowed)

Output of dmesg command:

OpenBSD 6.0-stable (GENERIC.MP) #0: Sun Sep 18 20:37:21 MDT 2016
jax@varian.jaxrcfb:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8553762816 (8157MB)
avail mem = 8290054144 (7906MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xeb040 (17 entries)
bios0: vendor American Megatrends Inc. version "R0200V3" date 02/10/2011
bios0: Sony Corporation VPCF215FX
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC HPET SLIC MCFG SSDT SSDT ECDT SSDT
acpi0: wakeup devices PEG0(S4) B0D4(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) USB6(S3) USB7(S3) HDEF(S4) PXSX(S4) 
RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(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) Core(TM) i7-2630QM CPU @ 2.00GHz, 1995.76 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT

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.1.2, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz, 1995.47 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT

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) Core(TM) i7-2630QM CPU @ 2.00GHz, 1995.47 MHz
cpu2: 
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT

cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz, 1995.47 MHz
cpu3: 
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT

cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
cpu4 at mainbus0: apid 1 (application processor)
cpu4: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz, 1995.47 MHz
cpu4: 
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT

cpu4: 256KB 64b/line 8-way L2 cache
cpu4: smt 1, core 0, package 0
cpu5 at mainbus0: apid 3 (application processor)
cpu5: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz, 1995.47 MHz
cpu5: 
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT

cpu5: 256KB 64b/line 8-way L2 cache
cpu5: smt 1, core 1, package 0
cpu6 at mainbus0: apid 5 (application processor)
cpu6: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz, 1995.47 MHz
cpu6: 
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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT

cpu6: 256KB 64b/line 8-way L2 cache
cpu6: smt 1, core 2, package 0
cpu7 at mainbus0: apid 7 (application processor)
cpu7: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz, 1995.47 MHz
cpu7: 

Remove reference to zaurus

[Frederic Cambus]

Hi tech@,

This seems to be a leftover from the zaurus port removal.

OK?

Index: sbin/disklabel/Makefile
===
RCS file: /cvs/src/sbin/disklabel/Makefile,v
retrieving revision 1.63
diff -u -p -r1.63 Makefile
--- sbin/disklabel/Makefile 1 Sep 2016 09:46:42 -   1.63
+++ sbin/disklabel/Makefile 21 Sep 2016 14:51:08 -
@@ -49,10 +49,6 @@ CFLAGS+= -DSEEALSO="\"fdisk(8), pdisk(8)
 CFLAGS+= -DSEEALSO="\"installboot(8)\"" -DSUN_CYLCHECK -DSUN_AAT0
 .endif
 
-.if (${MACHINE} == "zaurus")
-CFLAGS+= -DSEEALSO="\"fdisk(8)\""
-.endif
-
 .ifdef NOPIC
 CFLAGS+= -DSTATICLINKING
 .endif

Re: work-in-progress iwm performance fix

[Stefan Sperling]

On Wed, Sep 21, 2016 at 12:04:18PM +0200, Stefan Sperling wrote:
> Here's another update which fixes the data rates ACKs are sent at.
> This helps block ack with multiple associated clients.
> 
> There still seems to be an occasional problem during the initial association.
> It seems that sometimes parameters aren't applied correctly the first time.
> If you see bad performance, try 'ifconfig iwm0 scan' while associated.
> As a side effect this reconfigures the device.
> Not sure where that bug is yet. Perhaps the code somehow works better
> if we already have some AP info cached from a previous association?

These changes have now been committed.

Except I didn't commit the change which adds an iwm_updateedca() handler.
It is not ready to go in because the net80211 stack does not call this
handler yet so I'll need to investigate how to make this work.
It's not a very important change anyway and can wait.

Re: patch: USB quirk to support extra buttons on Kensington Slimblade

[Sven M. Hallberg]

Martin Pieuchot  on Wed, Sep 21 2016:
> Can you do that without adding a new quirk?

Yes, but I guess then there would have to be a check for this particular
product in the generic driver path?

> Is this way of reporting extra buttons standard or is it a vendor-only
> feature?

It's certainly not standard in the sense of the USB HID spec being the
standard. Whether it is a de-facto standard by any measure is a good
question that I don't know a definitive answer to. A cursory search of
Linux's HID driver directory turned up no other matches.

https://github.com/torvalds/linux/search?utf8=%E2%9C%93=MSVENDOR

> Where did you get the documentation from?

This was "reverse engineered", if you can call it that. I looked at the
output of usbhidctl -r, augmented the tool to dump the raw descriptor,
and verified with the HID spec that it parsed everything correctly. Put
it in the kernel and it worked.

I then cross-checked how Linux handles things and it does essentially
the same: treat these extra inputs in the "Microsoft" page as buttons.

Cf:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fdf93aa33268889e126aa677f2072238bd76adb0
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/hid/hid-kensington.c

>>--pesco
>> (sending from off-list)


PS: This is the report descriptor with my manual analysis, for reference:

report ID=0
Report descriptor:
Collection page=Generic_Desktop usage=Mouse (1:0x2)
Collection page=Generic_Desktop usage=Pointer (1:0x1)
Input   size=1 count=1 page=Button usage=Button_1 (9:0x1), logical range 0..1
Input   size=1 count=1 page=Button usage=Button_2 (9:0x2), logical range 0..1
Input   size=6 count=1 Const page=0x usage=0x (0:0x0), logical range 
0..1
Input   size=8 count=1 page=Generic_Desktop usage=X (1:0x30), logical range 
-127..127
Input   size=8 count=1 page=Generic_Desktop usage=Y (1:0x31), logical range 
-127..127
Input   size=8 count=1 page=Generic_Desktop usage=Wheel (1:0x38), logical range 
-127..127
Input   size=1 count=1 page=Microsoft usage=0x0001 (65280:0x1), logical range 
0..1
Input   size=1 count=1 page=Microsoft usage=0x0002 (65280:0x2), logical range 
0..1
Input   size=6 count=1 Const page=0x usage=0x (0:0x0), logical range 
0..1
End collection
End collection
Total   input size 5 bytes
Total  output size 0 bytes
Total feature size 0 bytes


-
raw descriptor:

// small item format:
// 4 bit tag
// 2 bit type (main, global, local, ?)
// 2 bit size (0, 1, 2, 4)
// data

05 01
  type 1 (global), tag 0: set usage page to 1 (generic desktop)
09 02
  type 2 (local), tag 0: add usage 2 (mouse)
a1 01
  type 0 (main), tag 10: open collection 1 (application)
09 01
  type 2 (local), tag 0: add usage 1 (pointer)
a1 00
  type 0 (main), tag 10: open collection 0 (physical)
05 09
  type 1 (global), tag 0: set usage page to 9 (button)
19 01
  type 2 (local), tag 1: set usage minimum to 1
29 02
  type 2 (local), tag 2: set usage maximum to 2, adds usages 1-2
15 00
  type 1 (global), tag 1: set logical minimum to 0
25 01
  type 1 (global), tag 2: set logical maximum to 1
95 02
  type 1 (global), tag 9: set loc_count to 2
75 01
  type 1 (global), tag 7: set loc_size to 1
81 02
  type 0 (main), tag 8: input, flags=2 (VARIABLE)
95 01
  type 1 (global), tag 9: set loc_count to 1
75 06
  type 1 (global), tag 7: set loc_size to 6
81 03
  type 0 (main), tag 8: input, flags=2+1 (VARIABLE,CONST)
05 01
  type 1 (global), tag 0: set usage page to 1 (generic desktop)
09 30
  type 2 (local), tag 0: add usage 48 (X)
09 31
  type 2 (local), tag 0: add usage 49 (Y)
09 38
  type 2 (local), tag 0: add usage 56 (wheel)
15 81
  type 1 (global), tag 1: set logical minimum to -127
25 7f
  type 1 (global), tag 2: set logical maximum to 127
75 08
  type 1 (global), tag 7: set loc_size to 8
95 03
  type 1 (global), tag 9: set loc_count to 3
81 06
  type 0 (main), tag 8: add as inputs, flags=4+2 (RELATIVE,VARIABLE)
06 00 ff
  type 1 (global), tag 0: set usage page to 65280 (microsoft)
19 01
  type 2 (local), tag 1: set usage minimum to 1
29 02
  type 2 (local), tag 2: set usage maximum to 2, adds usages 1-2
15 00
  type 1 (global), tag 1: set logical minimum to 0
25 01
  type 1 (global), tag 2: set logical maximum to 1
95 02
  type 1 (global), tag 9: set loc_count to 2
75 01
  type 1 (global), tag 7: set loc_size to 1
81 02
  type 0 (main), tag 8: add as inputs, flags=2 (VARIABLE)
95 01
  type 1 (global), tag 9: set loc_count to 1
75 06
  type 1 (global), tag 7: set loc_size to 6
81 03
  type 0 (main), tag 8: add as inputs, flags=2+1 (VARIABLE,CONST)
c0
  type 0 (main), tag 12: end collection (0)
c0
  type 0 (main), tag 12: end collection (1)

Re: fec(4) mii_tick

[Mark Kettenis]

> Date: Wed, 21 Sep 2016 21:42:36 +1000
> From: Jonathan Gray 
> 
> On Wed, Sep 21, 2016 at 01:22:04PM +0200, Mark Kettenis wrote:
> > Here is the promised diff that makes fec(4) call mii_tick() like all
> > our other ethernet drivers that use mii do.
> > 
> > Does this fix your problem Philip?
> 
> Isn't this missing a call to timeout_add_sec() outside of
> fec_tick()?

Right.  Updated diff (for real now).

Index: sys/arch/armv7/imx/if_fec.c
===
RCS file: /cvs/src/sys/arch/armv7/imx/if_fec.c,v
retrieving revision 1.17
diff -u -p -r1.17 if_fec.c
--- sys/arch/armv7/imx/if_fec.c 21 Sep 2016 10:28:47 -  1.17
+++ sys/arch/armv7/imx/if_fec.c 21 Sep 2016 12:16:28 -
@@ -231,6 +231,7 @@ struct fec_softc {
struct fec_buffer   *rx_buffer_base;
int cur_tx;
int cur_rx;
+   struct timeout  sc_tick;
 };
 
 struct fec_softc *fec_sc;
@@ -249,6 +250,7 @@ void fec_iff(struct fec_softc *);
 struct mbuf * fec_newbuf(void);
 int fec_intr(void *);
 void fec_recv(struct fec_softc *);
+void fec_tick(void *);
 int fec_miibus_readreg(struct device *, int, int);
 void fec_miibus_writereg(struct device *, int, int, int);
 void fec_miibus_statchg(struct device *);
@@ -430,6 +432,8 @@ fec_attach(struct device *parent, struct
ether_ifattach(ifp);
splx(s);
 
+   timeout_set(>sc_tick, fec_tick, sc);
+
fec_sc = sc;
return;
 
@@ -672,6 +676,8 @@ fec_init(struct fec_softc *sc)
/* program promiscuous mode and multicast filters */
fec_iff(sc);
 
+   timeout_add_sec(>sc_tick, 1);
+
/* Indicate we are up and running. */
ifp->if_flags |= IFF_RUNNING;
ifq_clr_oactive(>if_snd);
@@ -694,6 +700,8 @@ fec_stop(struct fec_softc *sc)
ifp->if_timer = 0;
ifq_clr_oactive(>if_snd);
 
+   timeout_del(>sc_tick);
+
/* reset the controller */
HSET4(sc, ENET_ECR, ENET_ECR_RESET);
while(HREAD4(sc, ENET_ECR) & ENET_ECR_RESET);
@@ -966,6 +974,19 @@ done:
HWRITE4(sc, ENET_RDAR, ENET_RDAR_RDAR);
 
if_input(ifp, );
+}
+
+void
+fec_tick(void *arg)
+{
+   struct fec_softc *sc = arg;
+   int s;
+
+   s = splnet();
+   mii_tick(>sc_mii);
+   splx(s);
+
+   timeout_add_sec(>sc_tick, 1);
 }
 
 /*

Re: send fewer router solicitations

[Stuart Henderson]

On 2016/09/02 10:37, Florian Obser wrote:
> Our kernel based rtsol code is like this little child.  We bring up
> the interface, send our first solicitation and get an advertisment
> back with a pltime of a week or so.
> 
> We lean back, quite happy that we can do v6 now, but after 60 seconds
> we wake up, oh shit, better check if that prefix is still valid. and
> so on and on.
> 
> This is particularly annoying if you try to debug ICMPv6 with tcpdump
> in a network with a lot of openbsd machines.
> 
> To stop naddy from pestering me about this at every hackathon (rightly
> so!), let's base the timeout on the prefixes pltime. ;)

There's a problem with this: we lose the exponential backoff for the
quick timer. Say you have v6 at home and enable autoconf on your laptop
then move to a network without v6 - this results in you spamming the
network with a multicast frame every second, which does not make you
a good network citizen especially if that's on a wireless lan.

 310 void
 311 nd6_rs_output_timo(void *ignored_arg)
 312 {
 313 struct ifnet *ifp;
 314 struct in6_ifaddr *ia6;
 315 u_int32_t pltime_expire = ND6_INFINITE_LIFETIME, t;
 316 int timeout = ND6_RS_OUTPUT_INTERVAL;
 318 if (nd6_rs_timeout_count == 0)
 319 return;
 320 
 321 if (nd6_rs_output_timeout < ND6_RS_OUTPUT_INTERVAL)
 322 /* exponential backoff if running quick timeouts */
 323 timeout = nd6_rs_output_timeout * 2;

I've tried a few things along the lines of these here instead

 if (nd6_rs_output_timeout < ND6_RS_OUTPUT_INTERVAL) {
nd6_rs_output_timeout *= 2;
timeout = nd6_rs_output_timeout;
 }

but haven't hit on a working combination yet.

I think the current state is quite a lot worse than the previous one
(even though it's better on networks that *do* have v6), so I'm wondering
if it might be better to revert if it's complicated to fix here (there
was a different plan for sending RS in the future anyway wasn't there?)

 324 
 325 TAILQ_FOREACH(ifp, , if_list) {
 326 if (ISSET(ifp->if_flags, IFF_RUNNING) &&
 327 ISSET(ifp->if_xflags, IFXF_AUTOCONF6)) {
 328 t = nd6_rs_next_pltime_timo(ifp);
 329 if (t == ND6_INFINITE_LIFETIME || t <
 330 ND6_RS_OUTPUT_INTERVAL) {
 331 timeout = ND6_RS_OUTPUT_QUICK_INTERVAL;
 332 ia6 = in6ifa_ifpforlinklocal(ifp,
 333 IN6_IFF_TENTATIVE);
 334 if (ia6 != NULL)
 335 nd6_rs_output(ifp, ia6);
 336 }   
 337 
 338 pltime_expire = MIN(pltime_expire, t);
 339 }   
 340 }   
 341 if (pltime_expire != ND6_INFINITE_LIFETIME)
 342 timeout = MAX(timeout, pltime_expire / 2);
 343 
 344 nd6_rs_output_set_timo(timeout);
 345 }  

Re: Modernize arm assembly in the kernel

[Mark Kettenis]

> Date: Wed, 21 Sep 2016 11:00:49 +0200
> From: Joerg Sonnenberger 
> 
> On Wed, Sep 21, 2016 at 10:10:43AM +0200, Mark Kettenis wrote:
> > 1. In GNU as, .align 0 is equivalent to .align 2, but with clang's
> >internal assembler .align 0 means "no alignment".
> 
> It might be even better to use .balign or .p2align.

Perhaps.  It's annoying how .align is ambiguous and different between
systems.  Don't feel like polishing that turd at this moment though.

> > 2. Using "ldr" to load a constant into a register is strange.  It
> >works with GNU as, but not with clang.
> 
> It should? See llvm/test/MC/ARM/ldr-pseudo.s. For small constants that
> fit into an immediate, the mov version is certainly smaller than going
> via the constant island, but the syntax should be correct.

Heh, I think I know what's going on here.  GNU as defenitely optimizes
the ldr from the constant pool into a mov.  Clang doesn't do this, but
the code looks correct.  But the code in question lives in the sigcode
page, and some time ago Theo added code there to fill the non-code
bits of the sigcode page with an instruction that generates SIGILL.
The code that does this is overwriting the constant pool!  So in the
end, using mov is the right solution.

OpenOspfd - Network type

[SGopinath]

Hi,

I would like to configure ospf with my Cisco router using Ethernet point to
point 
cable and would like to treat this as point to point link.

Is there any option for this ?. Like network type p2p ?.

Secondly, Is there option for ospf authentication using SHA1 or SHA2 message
digest ?.

Thridly, could I encrypt the message digest keys instead of clear text in
the ospfd.conf ?.

Thanks,
S.Gopinath



--
View this message in context: 
http://openbsd-archive.7691.n7.nabble.com/OpenOspfd-Network-type-tp304938.html
Sent from the openbsd dev - tech mailing list archive at Nabble.com.

Re: fec(4) mii_tick

[Mike Belopuhov]

On 21 September 2016 at 13:22, Mark Kettenis  wrote:
> Here is the promised diff that makes fec(4) call mii_tick() like all
> our other ethernet drivers that use mii do.
>
> Does this fix your problem Philip?
>
>

Looks good to me.  OK mikeb if this works for Philip.

fec(4) mii_tick

[Mark Kettenis]

Here is the promised diff that makes fec(4) call mii_tick() like all
our other ethernet drivers that use mii do.

Does this fix your problem Philip?


Index: sys/arch/armv7/imx/if_fec.c
===
RCS file: /cvs/src/sys/arch/armv7/imx/if_fec.c,v
retrieving revision 1.17
diff -u -p -r1.17 if_fec.c
--- sys/arch/armv7/imx/if_fec.c 21 Sep 2016 10:28:47 -  1.17
+++ sys/arch/armv7/imx/if_fec.c 21 Sep 2016 11:19:21 -
@@ -231,6 +231,7 @@ struct fec_softc {
struct fec_buffer   *rx_buffer_base;
int cur_tx;
int cur_rx;
+   struct timeout  sc_tick;
 };
 
 struct fec_softc *fec_sc;
@@ -249,6 +250,7 @@ void fec_iff(struct fec_softc *);
 struct mbuf * fec_newbuf(void);
 int fec_intr(void *);
 void fec_recv(struct fec_softc *);
+void fec_tick(void *);
 int fec_miibus_readreg(struct device *, int, int);
 void fec_miibus_writereg(struct device *, int, int, int);
 void fec_miibus_statchg(struct device *);
@@ -430,6 +432,8 @@ fec_attach(struct device *parent, struct
ether_ifattach(ifp);
splx(s);
 
+   timeout_set(>sc_tick, fec_tick, sc);
+
fec_sc = sc;
return;
 
@@ -966,6 +970,19 @@ done:
HWRITE4(sc, ENET_RDAR, ENET_RDAR_RDAR);
 
if_input(ifp, );
+}
+
+void
+fec_tick(void *arg)
+{
+   struct fec_softc *sc = arg;
+   int s;
+
+   s = splnet();
+   mii_tick(>sc_mii);
+   splx(s);
+
+   timeout_add_sec(>sc_tick, 1);
 }
 
 /*

Re: timeout_set_proc(9)

[Martin Pieuchot]

On 21/09/16(Wed) 16:29, David Gwynne wrote:
> [...] 
> the point i was trying to make was that the existing stuff (tasks, timeouts) 
> can be used together to get the effect we want. my point was very poorly made 
> though.
>
> i think your point is that you can make a clever change to timeouts and not 
> have to do a ton of flow on code changes to take advantage of it.

I'm trying to fix one problem at a time.

> [...]
> if timeouts are the way to schedule stuff to run in the future, then we're 
> going to get head-of-line blocking problems. pending timeouts will end up 
> stuck behind work that is waiting on an arbitrary lock, because there's an 
> implicit single thread that will run them all. right now that is mitigated by 
> timeouts being an interrupt context, we just dont put a lot of work like that 
> in there right now. 

Really?  Is it worth than it is now with the KERNEL_LOCK()?

> the benefit of taskqs is that you explicitly steer work to threads that can 
> sleep independently of each other. they lack being able to schedule work to 
> run in the future though.
> 
> it turns out it isnt that hard to make taskqs use a priority queue internally 
> instead of a tailq. this allows you to specify that tasks get executed in the 
> future (or right now, like the current behaviour) in an explicit thread (or 
> pool of threads). it does mean a lot of changes to code thats using timeouts 
> now though.

I agree with you, but these thoughts are IMHO too far ahead.  Everything
is still serialized in our kernel.

rtadvd: consistently use MAX_ prefix

[Florian Obser]

OK?

diff --git config.c config.c
index 842f9af..3118e93 100644
--- config.c
+++ config.c
@@ -176,11 +176,11 @@ getconfig(char *intface)
}
 
MAYHAVE(val, "rltime", tmp->maxinterval * 3);
-   if (val && (val < tmp->maxinterval || val > MAXROUTERLIFETIME)) {
+   if (val && (val < tmp->maxinterval || val > MAX_ROUTERLIFETIME)) {
log_warnx("router lifetime (%ld) on %s is invalid "
"(must be 0 or between %d and %d)",
val, intface,
-   tmp->maxinterval, MAXROUTERLIFETIME);
+   tmp->maxinterval, MAX_ROUTERLIFETIME);
exit(1);
}
/*
@@ -201,10 +201,10 @@ getconfig(char *intface)
tmp->lifetime = val & 0x;
 
MAYHAVE(val, "rtime", DEF_ADVREACHABLETIME);
-   if (val < 0 || val > MAXREACHABLETIME) {
+   if (val < 0 || val > MAX_REACHABLETIME) {
log_warnx("reachable time (%ld) on %s is invalid"
" (must be no greater than %d)",
-   val, intface, MAXREACHABLETIME);
+   val, intface, MAX_REACHABLETIME);
exit(1);
}
tmp->reachabletime = (u_int32_t)val;
diff --git rtadvd.h rtadvd.h
index fea0fd8..cbefb73 100644
--- rtadvd.h
+++ rtadvd.h
@@ -44,11 +44,11 @@
 #define DEF_ADVVALIDLIFETIME 2592000
 #define DEF_ADVPREFERREDLIFETIME 604800
 
-#define MAXROUTERLIFETIME 9000
+#define MAX_ROUTERLIFETIME 9000
 #define MIN_MAXINTERVAL 4
 #define MAX_MAXINTERVAL 1800
 #define MIN_MININTERVAL3
-#define MAXREACHABLETIME 360
+#define MAX_REACHABLETIME 360
 
 #define MAX_INITIAL_RTR_ADVERT_INTERVAL  16
 #define MAX_INITIAL_RTR_ADVERTISEMENTS3


-- 
I'm not entirely sure you are real.

rtadvd: no need for float defines

[Florian Obser]

OK?

diff --git config.c config.c
index 4f94632..842f9af 100644
--- config.c
+++ config.c
@@ -148,7 +148,7 @@ getconfig(char *intface)
MAYHAVE(val, "maxinterval", DEF_MAXRTRADVINTERVAL);
if (val < MIN_MAXINTERVAL || val > MAX_MAXINTERVAL) {
log_warnx("maxinterval (%ld) on %s is invalid "
-   "(must be between %e and %u)", val,
+   "(must be between %u and %u)", val,
intface, MIN_MAXINTERVAL, MAX_MAXINTERVAL);
exit(1);
}
@@ -156,7 +156,7 @@ getconfig(char *intface)
MAYHAVE(val, "mininterval", tmp->maxinterval/3);
if (val < MIN_MININTERVAL || val > (tmp->maxinterval * 3) / 4) {
log_warnx("mininterval (%ld) on %s is invalid "
-   "(must be between %e and %d)",
+   "(must be between %u and %u)",
val, intface, MIN_MININTERVAL, (tmp->maxinterval * 3) / 4);
exit(1);
}
diff --git rtadvd.h rtadvd.h
index 3dcd89e..fea0fd8 100644
--- rtadvd.h
+++ rtadvd.h
@@ -44,11 +44,10 @@
 #define DEF_ADVVALIDLIFETIME 2592000
 #define DEF_ADVPREFERREDLIFETIME 604800
 
-/* XXX int-to-double comparison for INTERVAL items */
 #define MAXROUTERLIFETIME 9000
-#define MIN_MAXINTERVAL 4.0
+#define MIN_MAXINTERVAL 4
 #define MAX_MAXINTERVAL 1800
-#define MIN_MININTERVAL3.0
+#define MIN_MININTERVAL3
 #define MAXREACHABLETIME 360
 
 #define MAX_INITIAL_RTR_ADVERT_INTERVAL  16

-- 
I'm not entirely sure you are real.

Re: work-in-progress iwm performance fix

[Stefan Sperling]

On Wed, Sep 21, 2016 at 12:04:45AM +0200, Stefan Sperling wrote:
> On Tue, Sep 20, 2016 at 02:35:18AM +0200, Stefan Sperling wrote:
> > I'd like to know if this diff helps with iwm(4) performance issues
> > some people have been reporting.
> > 
> > This is not done yet and some details don't really make sense, especially
> > the #if 0 hiding of what should be correct code -- yet, enabling that code
> > makes the problem come back.
> > 
> > But hopefully this is generally going in the right direction.
> > 
> > Thank you, Edward Wandasiewicz, for pointing out that reverting if_iwm.c
> > r1.85 restores performance. That was the door to this rabbit hole :-)
> 
> Here's a new version. Requires bleeding edge -current and also this
> uncommitted patch I posted earlier today:
> http://marc.info/?l=openbsd-tech=147440006608035=raw
> 
> It already seems to behave better. But the problem seems to be
> load dependent and I can't trigger it very reliably.
> 
> Thanks to all who provided feedback for the previous version.

Here's another update which fixes the data rates ACKs are sent at.
This helps block ack with multiple associated clients.

There still seems to be an occasional problem during the initial association.
It seems that sometimes parameters aren't applied correctly the first time.
If you see bad performance, try 'ifconfig iwm0 scan' while associated.
As a side effect this reconfigures the device.
Not sure where that bug is yet. Perhaps the code somehow works better
if we already have some AP info cached from a previous association?

Index: if_iwm.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v
retrieving revision 1.132
diff -u -p -r1.132 if_iwm.c
--- if_iwm.c12 Sep 2016 10:18:26 -  1.132
+++ if_iwm.c21 Sep 2016 09:37:02 -
@@ -301,6 +301,7 @@ voidiwm_init_channel_map(struct iwm_sof
 void   iwm_setup_ht_rates(struct iwm_softc *);
 void   iwm_htprot_task(void *);
 void   iwm_update_htprot(struct ieee80211com *, struct ieee80211_node *);
+void   iwm_updateedca(struct ieee80211com *);
 intiwm_ampdu_rx_start(struct ieee80211com *, struct ieee80211_node *,
uint8_t);
 void   iwm_ampdu_rx_stop(struct ieee80211com *, struct ieee80211_node *,
@@ -402,10 +403,10 @@ int   iwm_config_umac_scan(struct iwm_soft
 intiwm_umac_scan(struct iwm_softc *);
 void   iwm_ack_rates(struct iwm_softc *, struct iwm_node *, int *, int *);
 void   iwm_mac_ctxt_cmd_common(struct iwm_softc *, struct iwm_node *,
-   struct iwm_mac_ctx_cmd *, uint32_t);
+   struct iwm_mac_ctx_cmd *, uint32_t, int);
 void   iwm_mac_ctxt_cmd_fill_sta(struct iwm_softc *, struct iwm_node *,
struct iwm_mac_data_sta *, int);
-intiwm_mac_ctxt_cmd(struct iwm_softc *, struct iwm_node *, uint32_t);
+intiwm_mac_ctxt_cmd(struct iwm_softc *, struct iwm_node *, uint32_t, int);
 intiwm_update_quotas(struct iwm_softc *, struct iwm_node *);
 intiwm_auth(struct iwm_softc *);
 intiwm_assoc(struct iwm_softc *);
@@ -2379,13 +2380,16 @@ void
 iwm_sta_rx_agg(struct iwm_softc *sc, struct ieee80211_node *ni, uint8_t tid,
 uint16_t ssn, int start)
 {
+   struct ieee80211com *ic = >sc_ic;
struct iwm_add_sta_cmd_v7 cmd;
struct iwm_node *in = (void *)ni;
int err, s;
uint32_t status;
 
-   if (start && sc->sc_rx_ba_sessions >= IWM_MAX_RX_BA_SESSIONS)
+   if (start && sc->sc_rx_ba_sessions >= IWM_MAX_RX_BA_SESSIONS) {
+   ieee80211_addba_req_refuse(ic, ni, tid);
return;
+   }
 
memset(, 0, sizeof(cmd));
 
@@ -2406,17 +2410,18 @@ iwm_sta_rx_agg(struct iwm_softc *sc, str
status = IWM_ADD_STA_SUCCESS;
err = iwm_send_cmd_pdu_status(sc, IWM_ADD_STA, sizeof(cmd), ,
);
-   if (err)
-   return;
 
-   if (status == IWM_ADD_STA_SUCCESS) {
-   s = splnet();
-   if (start)
+   s = splnet();
+   if (err == 0 && status == IWM_ADD_STA_SUCCESS) {
+   if (start) {
sc->sc_rx_ba_sessions++;
-   else if (sc->sc_rx_ba_sessions > 0)
+   ieee80211_addba_req_accept(ic, ni, tid);
+   } else if (sc->sc_rx_ba_sessions > 0)
sc->sc_rx_ba_sessions--;
-   splx(s);
-   }
+   } else if (start)
+   ieee80211_addba_req_refuse(ic, ni, tid);
+
+   splx(s);
 }
 
 void
@@ -2428,13 +2433,29 @@ iwm_htprot_task(void *arg)
int err;
 
/* This call updates HT protection based on in->in_ni.ni_htop1. */
-   err = iwm_mac_ctxt_cmd(sc, in, IWM_FW_CTXT_ACTION_MODIFY);
+   err = iwm_mac_ctxt_cmd(sc, in, IWM_FW_CTXT_ACTION_MODIFY, 1);
if (err)
printf("%s: could not change HT protection: error %d\n",
DEVNAME(sc), err);
 }
 
 /*
+ * This function is called by upper layer when EDCA settings in
+ * beacons have 

Re: fec(4) cleanup

[Mike Belopuhov]

On 21 September 2016 at 10:15, Mark Kettenis  wrote:
> Diff below removes nused code from the driver and makes sure we only
> enable the tx and rx interrupts.  This seems to work fine for me.
> Next step will be to add the missing PHY tick stuff.
>
> ok?
>

OK mikeb.  I was going to send a diff like this yesterday
but realised that I didn't know which interrupt mask bit to
toggle.  This "unmask everything" hack looks like a good
candidate, indeed.

Re: patch: USB quirk to support extra buttons on Kensington Slimblade

[Martin Pieuchot]

On 20/09/16(Tue) 22:29, Sven M. Hallberg wrote:
> Ahoi OpenBSD,
> 
> My trackball reports two out of its four buttons in a non-standard way.
> I've patched my kernel with a new USB quirk for this situation. [*]
> 
> I'd like to contribute this if you want it; please let me know if this
> is the way to do it or if you'd like any changes.

Can you do that without adding a new quirk?  Is this way of reporting
extra buttons standard or is it a vendor-only feature?  Where did you
get the documentation from?

> 
> --pesco
> (sending from off-list)
> 
> 
> [*] The buttons appear in the HID descriptor like normal, except with
> their "usage" set to a vendor-reserved page. The quirk makes the driver
> treat this page like the standard button page.
> 

> Index: sys/dev/usb/ums.c
> ===
> RCS file: /cvs/src/sys/dev/usb/ums.c,v
> retrieving revision 1.43
> diff -u -p -r1.43 ums.c
> --- sys/dev/usb/ums.c 12 Jan 2016 19:16:21 -  1.43
> +++ sys/dev/usb/ums.c 20 Sep 2016 19:21:54 -
> @@ -143,6 +143,8 @@ ums_attach(struct device *parent, struct
>   qflags |= HIDMS_MS_BAD_CLASS;
>   if (quirks & UQ_MS_LEADING_BYTE)
>   qflags |= HIDMS_LEADINGBYTE;
> + if (quirks & UQ_MS_VENDOR_BUTTONS)
> + qflags |= HIDMS_VENDOR_BUTTONS;
>  
>   if (hidms_setup(self, ms, qflags, uha->reportid, desc, size) != 0)
>   return;
> Index: sys/dev/usb/usb_quirks.c
> ===
> RCS file: /cvs/src/sys/dev/usb/usb_quirks.c,v
> retrieving revision 1.74
> diff -u -p -r1.74 usb_quirks.c
> --- sys/dev/usb/usb_quirks.c  27 Nov 2015 10:59:32 -  1.74
> +++ sys/dev/usb/usb_quirks.c  20 Sep 2016 19:21:54 -
> @@ -150,6 +150,9 @@ const struct usbd_quirk_entry {
>   { USB_VENDOR_MICROSOFT, USB_PRODUCT_MICROSOFT_WLNOTEBOOK2,
>   ANY, { UQ_MS_BAD_CLASS | UQ_MS_LEADING_BYTE }},
>  
> + { USB_VENDOR_KENSINGTON, USB_PRODUCT_KENSINGTON_SLIMBLADE,
> + ANY, { UQ_MS_VENDOR_BUTTONS }},
> +
>   { 0, 0, 0, { 0 } }
>  };
>  
> Index: sys/dev/usb/usb_quirks.h
> ===
> RCS file: /cvs/src/sys/dev/usb/usb_quirks.h,v
> retrieving revision 1.16
> diff -u -p -r1.16 usb_quirks.h
> --- sys/dev/usb/usb_quirks.h  19 Jul 2010 05:08:37 -  1.16
> +++ sys/dev/usb/usb_quirks.h  20 Sep 2016 19:21:55 -
> @@ -49,6 +49,8 @@ struct usbd_quirks {
>  #define UQ_MS_LEADING_BYTE   0x0001 /* mouse sends unknown leading byte 
> */
>  #define UQ_EHCI_NEEDTO_DISOWN0x0002 /* must hand device over to 
> USB 1.1
>   if attached to EHCI */
> +#define UQ_MS_VENDOR_BUTTONS 0x0004 /* mouse reports extra buttons in
> + vendor page */
>  };
>  
>  extern const struct usbd_quirks usbd_no_quirk;
> Index: sys/dev/usb/usbdevs
> ===
> RCS file: /cvs/src/sys/dev/usb/usbdevs,v
> retrieving revision 1.668
> diff -u -p -r1.668 usbdevs
> --- sys/dev/usb/usbdevs   12 Sep 2016 07:55:33 -  1.668
> +++ sys/dev/usb/usbdevs   20 Sep 2016 19:21:55 -
> @@ -2397,6 +2397,7 @@ product KENSINGTON TURBOBALL0x1005  Turb
>  product KENSINGTON ORBIT_MAC 0x1009  Orbit trackball for Mac
>  product KENSINGTON BT_EDR0x105e  Bluetooth
>  product KENSINGTON VIDEOCAM_VGA  0x5002  VideoCAM VGA
> +product KENSINGTON SLIMBLADE 0x2041  Slimblade Trackball
>  
>  /* Keyspan products */
>  product KEYSPAN USA28_NF 0x0101  USA-28 serial
> Index: sys/dev/usb/usbdevs.h
> ===
> RCS file: /cvs/src/sys/dev/usb/usbdevs.h,v
> retrieving revision 1.680
> diff -u -p -r1.680 usbdevs.h
> --- sys/dev/usb/usbdevs.h 12 Sep 2016 07:56:29 -  1.680
> +++ sys/dev/usb/usbdevs.h 20 Sep 2016 19:21:56 -
> @@ -2404,6 +2404,7 @@
>  #define  USB_PRODUCT_KENSINGTON_ORBIT_MAC0x1009  /* 
> Orbit trackball for Mac */
>  #define  USB_PRODUCT_KENSINGTON_BT_EDR   0x105e  /* Bluetooth */
>  #define  USB_PRODUCT_KENSINGTON_VIDEOCAM_VGA 0x5002  /* 
> VideoCAM VGA */
> +#define  USB_PRODUCT_KENSINGTON_SLIMBLADE0x2041  /* 
> Slimblade Trackball */
>  
>  /* Keyspan products */
>  #define  USB_PRODUCT_KEYSPAN_USA28_NF0x0101  /* USA-28 
> serial */
> Index: sys/dev/usb/usbdevs_data.h
> ===
> RCS file: /cvs/src/sys/dev/usb/usbdevs_data.h,v
> retrieving revision 1.674
> diff -u -p -r1.674 usbdevs_data.h
> --- sys/dev/usb/usbdevs_data.h12 Sep 2016 07:56:29 -  1.674
> +++ sys/dev/usb/usbdevs_data.h20 Sep 2016 19:21:58 -
> @@ -5166,6 +5166,10 @@ const struct usb_known_product usb_known
>   "VideoCAM VGA",
>   },
>   {
> + 

patch: USB quirk to support extra buttons on Kensington Slimblade

[Sven M. Hallberg]

Ahoi OpenBSD,

My trackball reports two out of its four buttons in a non-standard way.
I've patched my kernel with a new USB quirk for this situation. [*]

I'd like to contribute this if you want it; please let me know if this
is the way to do it or if you'd like any changes.

--pesco
(sending from off-list)


[*] The buttons appear in the HID descriptor like normal, except with
their "usage" set to a vendor-reserved page. The quirk makes the driver
treat this page like the standard button page.

Index: sys/dev/usb/ums.c
===
RCS file: /cvs/src/sys/dev/usb/ums.c,v
retrieving revision 1.43
diff -u -p -r1.43 ums.c
--- sys/dev/usb/ums.c	12 Jan 2016 19:16:21 -	1.43
+++ sys/dev/usb/ums.c	20 Sep 2016 19:21:54 -
@@ -143,6 +143,8 @@ ums_attach(struct device *parent, struct
 		qflags |= HIDMS_MS_BAD_CLASS;
 	if (quirks & UQ_MS_LEADING_BYTE)
 		qflags |= HIDMS_LEADINGBYTE;
+	if (quirks & UQ_MS_VENDOR_BUTTONS)
+		qflags |= HIDMS_VENDOR_BUTTONS;
 
 	if (hidms_setup(self, ms, qflags, uha->reportid, desc, size) != 0)
 		return;
Index: sys/dev/usb/usb_quirks.c
===
RCS file: /cvs/src/sys/dev/usb/usb_quirks.c,v
retrieving revision 1.74
diff -u -p -r1.74 usb_quirks.c
--- sys/dev/usb/usb_quirks.c	27 Nov 2015 10:59:32 -	1.74
+++ sys/dev/usb/usb_quirks.c	20 Sep 2016 19:21:54 -
@@ -150,6 +150,9 @@ const struct usbd_quirk_entry {
  { USB_VENDOR_MICROSOFT, USB_PRODUCT_MICROSOFT_WLNOTEBOOK2,
 	ANY, { UQ_MS_BAD_CLASS | UQ_MS_LEADING_BYTE }},
 
+ { USB_VENDOR_KENSINGTON, USB_PRODUCT_KENSINGTON_SLIMBLADE,
+	ANY, { UQ_MS_VENDOR_BUTTONS }},
+
  { 0, 0, 0, { 0 } }
 };
 
Index: sys/dev/usb/usb_quirks.h
===
RCS file: /cvs/src/sys/dev/usb/usb_quirks.h,v
retrieving revision 1.16
diff -u -p -r1.16 usb_quirks.h
--- sys/dev/usb/usb_quirks.h	19 Jul 2010 05:08:37 -	1.16
+++ sys/dev/usb/usb_quirks.h	20 Sep 2016 19:21:55 -
@@ -49,6 +49,8 @@ struct usbd_quirks {
 #define UQ_MS_LEADING_BYTE	0x0001 /* mouse sends unknown leading byte */
 #define UQ_EHCI_NEEDTO_DISOWN	0x0002 /* must hand device over to USB 1.1
 		if attached to EHCI */
+#define UQ_MS_VENDOR_BUTTONS	0x0004 /* mouse reports extra buttons in
+		vendor page */
 };
 
 extern const struct usbd_quirks usbd_no_quirk;
Index: sys/dev/usb/usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.668
diff -u -p -r1.668 usbdevs
--- sys/dev/usb/usbdevs	12 Sep 2016 07:55:33 -	1.668
+++ sys/dev/usb/usbdevs	20 Sep 2016 19:21:55 -
@@ -2397,6 +2397,7 @@ product KENSINGTON TURBOBALL	0x1005	Turb
 product KENSINGTON ORBIT_MAC	0x1009	Orbit trackball for Mac
 product KENSINGTON BT_EDR	0x105e	Bluetooth
 product KENSINGTON VIDEOCAM_VGA	0x5002	VideoCAM VGA
+product KENSINGTON SLIMBLADE	0x2041	Slimblade Trackball
 
 /* Keyspan products */
 product KEYSPAN USA28_NF	0x0101	USA-28 serial
Index: sys/dev/usb/usbdevs.h
===
RCS file: /cvs/src/sys/dev/usb/usbdevs.h,v
retrieving revision 1.680
diff -u -p -r1.680 usbdevs.h
--- sys/dev/usb/usbdevs.h	12 Sep 2016 07:56:29 -	1.680
+++ sys/dev/usb/usbdevs.h	20 Sep 2016 19:21:56 -
@@ -2404,6 +2404,7 @@
 #define	USB_PRODUCT_KENSINGTON_ORBIT_MAC	0x1009		/* Orbit trackball for Mac */
 #define	USB_PRODUCT_KENSINGTON_BT_EDR	0x105e		/* Bluetooth */
 #define	USB_PRODUCT_KENSINGTON_VIDEOCAM_VGA	0x5002		/* VideoCAM VGA */
+#define	USB_PRODUCT_KENSINGTON_SLIMBLADE	0x2041		/* Slimblade Trackball */
 
 /* Keyspan products */
 #define	USB_PRODUCT_KEYSPAN_USA28_NF	0x0101		/* USA-28 serial */
Index: sys/dev/usb/usbdevs_data.h
===
RCS file: /cvs/src/sys/dev/usb/usbdevs_data.h,v
retrieving revision 1.674
diff -u -p -r1.674 usbdevs_data.h
--- sys/dev/usb/usbdevs_data.h	12 Sep 2016 07:56:29 -	1.674
+++ sys/dev/usb/usbdevs_data.h	20 Sep 2016 19:21:58 -
@@ -5166,6 +5166,10 @@ const struct usb_known_product usb_known
 	"VideoCAM VGA",
 	},
 	{
+	USB_VENDOR_KENSINGTON, USB_PRODUCT_KENSINGTON_SLIMBLADE,
+	"Slimblade Trackball",
+	},
+	{
 	USB_VENDOR_KEYSPAN, USB_PRODUCT_KEYSPAN_USA28_NF,
 	"USA-28 serial",
 	},
Index: sys/dev/hid/hidms.c
===
RCS file: /cvs/src/sys/dev/hid/hidms.c,v
retrieving revision 1.3
diff -u -p -r1.3 hidms.c
--- sys/dev/hid/hidms.c	22 May 2016 22:06:11 -	1.3
+++ sys/dev/hid/hidms.c	20 Sep 2016 19:22:44 -
@@ -191,6 +191,21 @@ hidms_setup(struct device *self, struct 
 			break;
 	ms->sc_num_buttons = i - 1;
 
+	/* 
+	 * The Kensington Slimblade reports some of its buttons as binary
+	 * inputs in the first vendor usage page (0xff00). Add such inputs
+	 * as buttons if the device has this quirk.
+	 */
+	if (ms->sc_flags & 

Re: Modernize arm assembly in the kernel

[Joerg Sonnenberger]

On Wed, Sep 21, 2016 at 10:10:43AM +0200, Mark Kettenis wrote:
> 1. In GNU as, .align 0 is equivalent to .align 2, but with clang's
>internal assembler .align 0 means "no alignment".

It might be even better to use .balign or .p2align.

> 2. Using "ldr" to load a constant into a register is strange.  It
>works with GNU as, but not with clang.

It should? See llvm/test/MC/ARM/ldr-pseudo.s. For small constants that
fit into an immediate, the mov version is certainly smaller than going
via the constant island, but the syntax should be correct.

Joerg

Re: hashfree: sizes for free(9) when using hashinit.

[Mathieu -]

Ted Unangst wrote:
> Mathieu - wrote:
> > Hello list,
> > 
> > I'm introducing hashfree, a counterpart to hashinit in order to pass the
> > size to free(9) while hiding the implementation details.
> > Most of the api users are converted in the patch below, those not
> > included just simply do not free the memory (pid hash table etc). All,
> > except for one case, the input hashtbl in in_pcb, because at free time
> > the size is really not known, so it needs more moving of things around
> > and is out the scope of this patch.
> > 
> > Manpage diff courtesy of natano@ on an old version of the diff!
> 
> looks good

Anyone ?

Re: OSPFD

[Gregory Edigarov]

On 21.09.16 09:19, Claudio Jeker wrote:

On Wed, Sep 21, 2016 at 08:32:01AM +0530, S.Gopinath SundaraRajan wrote:

Hi,

I just started using OpenBSD's ospfd.

1. I would like to have a direct Ethernet link
between OpenBSD box and Cisco/Juniper router.

I would like to specify the link type as point to point.

Which configuration directive I have to use ?.

Currently not supported. I looked at this once but it was trickier than
expected (couldn't shake out the last bugs).
There is a workaround though, setup a tunnel (gif(4) or gre(4)) between 
your Cisco  and OpenBSD

and make ospfd listen on this tunnel.
  

2. I would like to use SHA1/SHA2 Message digest
authentication. Whether ospfd supports this ?.


No. We don't support those but we accept patches.


3. I would like to crypt the authentication keys in the
ospfd.conf file instead of plain text keys. Is it possible ?.


There is no way you can store a shared secret in a config file in an
encrypted form. This is why the config file is only readable by root.
Scrambling it does not increase security so it is not worth the effort.

fec(4) cleanup

[Mark Kettenis]

Diff below removes nused code from the driver and makes sure we only
enable the tx and rx interrupts.  This seems to work fine for me.
Next step will be to add the missing PHY tick stuff.

ok?


Index: sys/arch/armv7/imx/if_fec.c
===
RCS file: /cvs/src/sys/arch/armv7/imx/if_fec.c,v
retrieving revision 1.16
diff -u -p -r1.16 if_fec.c
--- sys/arch/armv7/imx/if_fec.c 19 Aug 2016 18:25:53 -  1.16
+++ sys/arch/armv7/imx/if_fec.c 21 Sep 2016 08:11:53 -
@@ -221,7 +221,6 @@ struct fec_softc {
bus_space_handle_t  sc_ioh;
void*sc_ih; /* Interrupt handler */
bus_dma_tag_t   sc_dma_tag;
-   uint32_tintr_status;/* soft interrupt status */
struct fec_dma_alloctxdma;  /* bus_dma glue for tx desc */
struct fec_buf_desc *tx_desc_base;
struct fec_dma_allocrxdma;  /* bus_dma glue for rx desc */
@@ -250,7 +249,6 @@ void fec_iff(struct fec_softc *);
 struct mbuf * fec_newbuf(void);
 int fec_intr(void *);
 void fec_recv(struct fec_softc *);
-int fec_wait_intr(struct fec_softc *, int, int);
 int fec_miibus_readreg(struct device *, int, int);
 void fec_miibus_writereg(struct device *, int, int, int);
 void fec_miibus_statchg(struct device *);
@@ -680,7 +678,6 @@ fec_init(struct fec_softc *sc)
 
/* enable interrupts for tx/rx */
HWRITE4(sc, ENET_EIMR, ENET_EIR_TXF | ENET_EIR_RXF);
-   HWRITE4(sc, ENET_EIMR, 0x);
 
fec_start(ifp);
 }
@@ -900,15 +897,6 @@ fec_intr(void *arg)
HWRITE4(sc, ENET_EIR, status);
 
/*
-* Wake up the blocking process to service command
-* related interrupt(s).
-*/
-   if (ISSET(status, ENET_EIR_MII)) {
-   sc->intr_status |= status;
-   wakeup(>intr_status);
-   }
-
-   /*
 * Handle incoming packets.
 */
if (ISSET(status, ENET_EIR_RXF)) {
@@ -978,28 +966,6 @@ done:
HWRITE4(sc, ENET_RDAR, ENET_RDAR_RDAR);
 
if_input(ifp, );
-}
-
-int
-fec_wait_intr(struct fec_softc *sc, int mask, int timo)
-{
-   int status;
-   int s;
-
-   s = splnet();
-
-   status = sc->intr_status;
-   while (status == 0) {
-   if (tsleep(>intr_status, PWAIT, "hcintr", timo)
-   == EWOULDBLOCK) {
-   break;
-   }
-   status = sc->intr_status;
-   }
-   sc->intr_status &= ~status;
-
-   splx(s);
-   return status;
 }
 
 /*

Modernize arm assembly in the kernel

[Mark Kettenis]

This fixes two isses.

1. In GNU as, .align 0 is equivalent to .align 2, but with clang's
   internal assembler .align 0 means "no alignment".

2. Using "ldr" to load a constant into a register is strange.  It
   works with GNU as, but not with clang.

No binary change in a kernel compiled with gcc.

ok?


Index: arch/arm/arm/bcopyinout.S
===
RCS file: /cvs/src/sys/arch/arm/arm/bcopyinout.S,v
retrieving revision 1.5
diff -u -p -r1.5 bcopyinout.S
--- arch/arm/arm/bcopyinout.S   25 Apr 2016 04:46:56 -  1.5
+++ arch/arm/arm/bcopyinout.S   21 Sep 2016 08:06:23 -
@@ -46,7 +46,7 @@
 #else
 
.text
-   .align  0
+   .align  2
 
 #ifdef MULTIPROCESSOR
 .Lcpu_info:
Index: arch/arm/arm/bus_space_notimpl.S
===
RCS file: /cvs/src/sys/arch/arm/arm/bus_space_notimpl.S,v
retrieving revision 1.2
diff -u -p -r1.2 bus_space_notimpl.S
--- arch/arm/arm/bus_space_notimpl.S27 May 2007 16:10:39 -  1.2
+++ arch/arm/arm/bus_space_notimpl.S21 Sep 2016 08:06:23 -
@@ -65,7 +65,7 @@ LLABEL(__C(func,_text))   
;   \
.align  0   ;
 
 bs_notimpl_message:
-.asciz  __S(BUS_SPACE) "_%s: args at %p"
+.asciz  __S(BUS_SPACE), "_%s: args at %p"
 
.align  2
 bs_notimpl_panic:
Index: arch/arm/arm/copystr.S
===
RCS file: /cvs/src/sys/arch/arm/arm/copystr.S,v
retrieving revision 1.6
diff -u -p -r1.6 copystr.S
--- arch/arm/arm/copystr.S  25 Apr 2016 04:46:56 -  1.6
+++ arch/arm/arm/copystr.S  21 Sep 2016 08:06:23 -
@@ -45,7 +45,7 @@
 #include 
 
.text
-   .align  0
+   .align  2
 #ifdef MULTIPROCESSOR
 .Lcpu_info:
.word   _C_LABEL(cpu_info)
@@ -210,5 +210,5 @@ ENTRY(copyoutstr)
 
 Lcopystrpcbfaulttext:
.asciz  "No valid PCB during copyinoutstr() addr1=%08x addr2=%08x\n"
-   .align  0
+   .align  2
 #endif
Index: arch/arm/arm/cpufunc_asm.S
===
RCS file: /cvs/src/sys/arch/arm/arm/cpufunc_asm.S,v
retrieving revision 1.4
diff -u -p -r1.4 cpufunc_asm.S
--- arch/arm/arm/cpufunc_asm.S  25 Apr 2016 04:46:56 -  1.4
+++ arch/arm/arm/cpufunc_asm.S  21 Sep 2016 08:06:23 -
@@ -47,7 +47,7 @@
 #include 
 
.text
-   .align  0
+   .align  2
 
 ENTRY(cpufunc_nullop)
mov pc, lr
Index: arch/arm/arm/exception.S
===
RCS file: /cvs/src/sys/arch/arm/arm/exception.S,v
retrieving revision 1.5
diff -u -p -r1.5 exception.S
--- arch/arm/arm/exception.S18 Jan 2015 12:03:11 -  1.5
+++ arch/arm/arm/exception.S21 Sep 2016 08:06:23 -
@@ -52,7 +52,7 @@
 #include "assym.h"
 
.text   
-   .align  0
+   .align  2
 
 AST_LOCALS
 
@@ -120,7 +120,7 @@ abortprefetch:
 
 abortprefetchmsg:
 .asciz  "abortprefetch"
-.align  0
+.align  2
 
 /*
  * data_abort_entry:
@@ -157,7 +157,7 @@ abortdata:
 
 abortdatamsg:
 .asciz  "abortdata"
-.align  0
+.align  2
 
 /*
  * address_exception_entry:
@@ -231,7 +231,7 @@ ENTRY_NP(undefinedinstruction_bounce)
b   _C_LABEL(undefinedinstruction)
 
.data
-   .align  0
+   .align  2
 
 /*
  * Indirection data
Index: arch/arm/arm/irq_dispatch.S
===
RCS file: /cvs/src/sys/arch/arm/arm/irq_dispatch.S,v
retrieving revision 1.11
diff -u -p -r1.11 irq_dispatch.S
--- arch/arm/arm/irq_dispatch.S 25 Apr 2016 04:46:56 -  1.11
+++ arch/arm/arm/irq_dispatch.S 21 Sep 2016 08:06:23 -
@@ -86,7 +86,7 @@
  * which can be used by different platforms.
  */
.text
-   .align  0
+   .align  2
 .Lcpu_info_primary:
.word   _C_LABEL(cpu_info_primary)
 
@@ -129,7 +129,7 @@ ASENTRY_NP(irq_entry)
movspc, lr  /* Exit */
 
.bss
-   .align  0
+   .align  2
 
.global _C_LABEL(astpending)
 _C_LABEL(astpending):
Index: arch/arm/arm/locore.S
===
RCS file: /cvs/src/sys/arch/arm/arm/locore.S,v
retrieving revision 1.10
diff -u -p -r1.10 locore.S
--- arch/arm/arm/locore.S   25 Apr 2016 04:46:56 -  1.10
+++ arch/arm/arm/locore.S   21 Sep 2016 08:06:23 -
@@ -49,7 +49,7 @@
  */
 
.text
-   .align  0
+   .align  2
 
 ENTRY_NP(kernel_text)
 
@@ -98,14 +98,14 @@ ASENTRY_NP(start)
 
 .Lmainreturned:
.asciz  "main() returned"
-   .align  0
+   .align  2
 
.bss
 svcstk:
.space  INIT_ARM_STACK_SIZE
 
.text
-   .align  0
+   .align  2
 
 #ifndef OFW
/* OFW based systems will use OF_boot() */
Index: 

Re: _KERNEL in rwlock.h

[David Gwynne]

> On 21 Sep 2016, at 17:15, Martin Pieuchot  wrote:
> 
> Do not export kernel prototypes to userland, structure definitions is 
> what we need... or do we need love?

if you can #define love, let me know.

> 
> ok?

ok.

> 
> Index: sys/rwlock.h
> ===
> RCS file: /cvs/src/sys/sys/rwlock.h,v
> retrieving revision 1.18
> diff -u -p -r1.18 rwlock.h
> --- sys/rwlock.h  11 Feb 2015 00:14:11 -  1.18
> +++ sys/rwlock.h  21 Sep 2016 07:11:33 -
> @@ -51,8 +51,8 @@
>  *  set, call rw_exit_waiters with the old contents of the lock.
>  */
> 
> -#ifndef SYS_RWLOCK_H
> -#define SYS_RWLOCK_H
> +#ifndef _SYS_RWLOCK_H
> +#define _SYS_RWLOCK_H
> 
> struct proc;
> 
> @@ -73,27 +73,6 @@ struct rwlock {
> #define RWLOCK_READER_SHIFT   3UL
> #define RWLOCK_READ_INCR  (1UL << RWLOCK_READER_SHIFT)
> 
> -void rw_init(struct rwlock *, const char *);
> -
> -void rw_enter_read(struct rwlock *);
> -void rw_enter_write(struct rwlock *);
> -void rw_exit_read(struct rwlock *);
> -void rw_exit_write(struct rwlock *);
> -
> -#ifdef DIAGNOSTIC
> -void rw_assert_wrlock(struct rwlock *);
> -void rw_assert_rdlock(struct rwlock *);
> -void rw_assert_unlocked(struct rwlock *);
> -#else
> -#define rw_assert_wrlock(rwl) ((void)0)
> -#define rw_assert_rdlock(rwl) ((void)0)
> -#define rw_assert_unlocked(rwl) ((void)0)
> -#endif
> -
> -int rw_enter(struct rwlock *, int);
> -void rw_exit(struct rwlock *);
> -int rw_status(struct rwlock *);
> -
> #define RW_WRITE  0x0001UL/* exclusive lock */
> #define RW_READ   0x0002UL/* shared lock */
> #define RW_DOWNGRADE  0x0004UL/* downgrade exclusive to shared */
> @@ -116,9 +95,34 @@ struct rrwlock {
>   uint32_trrwl_wcnt;  /* # writers. */
> };
> 
> +#ifdef _KERNEL
> +
> +void rw_init(struct rwlock *, const char *);
> +
> +void rw_enter_read(struct rwlock *);
> +void rw_enter_write(struct rwlock *);
> +void rw_exit_read(struct rwlock *);
> +void rw_exit_write(struct rwlock *);
> +
> +#ifdef DIAGNOSTIC
> +void rw_assert_wrlock(struct rwlock *);
> +void rw_assert_rdlock(struct rwlock *);
> +void rw_assert_unlocked(struct rwlock *);
> +#else
> +#define rw_assert_wrlock(rwl) ((void)0)
> +#define rw_assert_rdlock(rwl) ((void)0)
> +#define rw_assert_unlocked(rwl) ((void)0)
> +#endif
> +
> +int rw_enter(struct rwlock *, int);
> +void rw_exit(struct rwlock *);
> +int rw_status(struct rwlock *);
> +
> void  rrw_init(struct rrwlock *, char *);
> int   rrw_enter(struct rrwlock *, int);
> void  rrw_exit(struct rrwlock *);
> int   rrw_status(struct rrwlock *);
> 
> -#endif
> +#endif /* _KERNEL */
> +
> +#endif /* _SYS_RWLOCK_H */
> 

Re: timeout_set_proc(9)

[David Gwynne]

> On 19 Sep 2016, at 20:28, Mike Belopuhov  wrote:
> 
> On 19 September 2016 at 11:06, Martin Pieuchot  wrote:
>> On 19/09/16(Mon) 13:47, David Gwynne wrote:
>>> [...]
>>> id rather not grow the timeout (or task for that matter) apis just
>>> yet. theyre nice and straightforward to read and understand so far.
>> 
>> So better introduce a new API, right?

i guess.

the point i was trying to make was that the existing stuff (tasks, timeouts) 
can be used together to get the effect we want. my point was very poorly made 
though.

i think your point is that you can make a clever change to timeouts and not 
have to do a ton of flow on code changes to take advantage of it.

>> 
>>> for this specific problem can we do a specific fix for it? the diff
>>> below is equiv to the timeout_set_proc change, but implements it
>>> by using explicit tasks that are called by the timeouts from a
>>> common trampoline in the network stack.
>> 
>> Is it really a specific problem?  We already encounter this for the
>> linkstate and the watchdog.
>> 
>> I'm not convinced by this approach.  I don't understand why:
>>  - adding a task in every data structure is worth it
>>  - introducing a new if_nettmo_* make things simpler
>> 
>> So there's something which isn't explain in this email.
>> 
>> And I'll bet that in the upcoming years we're going to stop using soft
>> interrupts.  Meaning that timeout handlers will always have a stack
>> available.  If/when this happens, it will be easier to do:
>> 
>>s/timeout_set_proc/timeout_set/
>> 
> 
> FWIW, I agree with mpi on this.  As a temporary change his
> approach is sound.

if its temporary, then fine.

> I would also like to know what prevents us from executing all
> timeouts in a thread context now? serial drivers with softtty
> line discipline entanglement?

theres some stuff in wi(4) and ipsec that would need to be fixed first. apart 
from that i have concerns a about having everything go through a single 
execution context.

if timeouts are the way to schedule stuff to run in the future, then we're 
going to get head-of-line blocking problems. pending timeouts will end up stuck 
behind work that is waiting on an arbitrary lock, because there's an implicit 
single thread that will run them all. right now that is mitigated by timeouts 
being an interrupt context, we just dont put a lot of work like that in there 
right now. 

the benefit of taskqs is that you explicitly steer work to threads that can 
sleep independently of each other. they lack being able to schedule work to run 
in the future though.

it turns out it isnt that hard to make taskqs use a priority queue internally 
instead of a tailq. this allows you to specify that tasks get executed in the 
future (or right now, like the current behaviour) in an explicit thread (or 
pool of threads). it does mean a lot of changes to code thats using timeouts 
now though.

anyway. if this is temporary, then fine.

dlg

Re: OSPFD

[S.Gopinath SundaraRajan]

Thanks Sir.



On Wed, Sep 21, 2016 at 11:49 AM, Claudio Jeker 
wrote:

> On Wed, Sep 21, 2016 at 08:32:01AM +0530, S.Gopinath SundaraRajan wrote:
> > Hi,
> >
> > I just started using OpenBSD's ospfd.
> >
> > 1. I would like to have a direct Ethernet link
> > between OpenBSD box and Cisco/Juniper router.
> >
> > I would like to specify the link type as point to point.
> >
> > Which configuration directive I have to use ?.
>
> Currently not supported. I looked at this once but it was trickier than
> expected (couldn't shake out the last bugs).
>
> > 2. I would like to use SHA1/SHA2 Message digest
> > authentication. Whether ospfd supports this ?.
> >
>
> No. We don't support those but we accept patches.
>
> >
> > 3. I would like to crypt the authentication keys in the
> > ospfd.conf file instead of plain text keys. Is it possible ?.
> >
>
> There is no way you can store a shared secret in a config file in an
> encrypted form. This is why the config file is only readable by root.
> Scrambling it does not increase security so it is not worth the effort.
>
> --
> :wq Claudio
>

Re: OSPFD

[Claudio Jeker]

On Wed, Sep 21, 2016 at 08:32:01AM +0530, S.Gopinath SundaraRajan wrote:
> Hi,
> 
> I just started using OpenBSD's ospfd.
> 
> 1. I would like to have a direct Ethernet link
> between OpenBSD box and Cisco/Juniper router.
> 
> I would like to specify the link type as point to point.
> 
> Which configuration directive I have to use ?.

Currently not supported. I looked at this once but it was trickier than
expected (couldn't shake out the last bugs).
 
> 2. I would like to use SHA1/SHA2 Message digest
> authentication. Whether ospfd supports this ?.
> 

No. We don't support those but we accept patches.

> 
> 3. I would like to crypt the authentication keys in the
> ospfd.conf file instead of plain text keys. Is it possible ?.
> 

There is no way you can store a shared secret in a config file in an
encrypted form. This is why the config file is only readable by root.
Scrambling it does not increase security so it is not worth the effort.

-- 
:wq Claudio