Re: Thinkpad display brightness control

[Mike Larkin]

On Wed, Dec 16, 2015 at 07:48:23PM +0100, Mark Kettenis wrote:
> Most, if not all, somewhat recent Thinkpads have some subtle issues
> with display brightness control.  For example,if you change the
> display brightness using wsconsctl(8) or cbacklight(1), and later use
> the brightness control buttons on the keyboard, you're likely to see a
> big jump in brightness.  or if you plug or unplug the power, the
> display brightness will suddenly change.  The problem here is that on
> these machines we us the display brightness interface provided by
> inteldrm(4), which doesn't coordinate changes with the firmware.
> 
> In principle these machines support the standard acpi brightness
> control interface.  However that interface is quite badly broken if
> the OS claims to be Windows 8.  Unfortunately that is what we do on
> OpenBSD because otherwise some other machines don't work properly.
> 
> Fortunately Thinkpads provide an alternative acpi interface through
> the "hotkey" device that is handled by acpithinkpad(4).  The diff
> below implements that interface.
> 
> The downside of this diff is that number of levels is limited to 16
> whereas we currently have much finer granularity.  But I think that is
> acceptable.  The levels are probably better calibrated and we now have
> proper coordination between the OS and the firmware when it comes to
> brightness changes.  On top of that, this diff will almost certainly
> result in working brightness control on machines that don't have Intel
> graphics.
> 
> ok?
> 

I'm ok with this. Didn't test it but I don't have objections to moving
in this direction. Diff looks ok too.

-ml

> 
> Index: acpithinkpad.c
> ===
> RCS file: /home/cvs/src/sys/dev/acpi/acpithinkpad.c,v
> retrieving revision 1.49
> diff -u -p -r1.49 acpithinkpad.c
> --- acpithinkpad.c16 Dec 2015 15:43:14 -  1.49
> +++ acpithinkpad.c16 Dec 2015 18:00:03 -
> @@ -122,6 +122,8 @@ struct acpithinkpad_softc {
>   uint64_t sc_thinklight;
>   const char  *sc_thinklight_get;
>   const char  *sc_thinklight_set;
> +
> + uint64_t sc_brightness;
>  };
>  
>  extern void acpiec_read(struct acpiec_softc *, u_int8_t, int, u_int8_t *);
> @@ -141,13 +143,19 @@ int thinkpad_brightness_down(struct acpi
>  int  thinkpad_adaptive_change(struct acpithinkpad_softc *);
>  int  thinkpad_activate(struct device *, int);
>  
> -/* wskbd hook functions */
> +/* wscons hook functions */
>  void thinkpad_get_thinklight(struct acpithinkpad_softc *);
>  void thinkpad_set_thinklight(void *, int);
>  int  thinkpad_get_backlight(struct wskbd_backlight *);
>  int  thinkpad_set_backlight(struct wskbd_backlight *);
>  extern int (*wskbd_get_backlight)(struct wskbd_backlight *);
>  extern int (*wskbd_set_backlight)(struct wskbd_backlight *);
> +void thinkpad_get_brightness(struct acpithinkpad_softc *);
> +void thinkpad_set_brightness(void *, int);
> +int  thinkpad_get_param(struct wsdisplay_param *);
> +int  thinkpad_set_param(struct wsdisplay_param *);
> +extern int (*ws_get_param)(struct wsdisplay_param *);
> +extern int (*ws_set_param)(struct wsdisplay_param *);
>  
>  voidthinkpad_sensor_attach(struct acpithinkpad_softc *sc);
>  voidthinkpad_sensor_refresh(void *);
> @@ -267,6 +275,12 @@ thinkpad_attach(struct device *parent, s
>   wskbd_set_backlight = thinkpad_set_backlight;
>   }
>  
> + if (aml_evalinteger(sc->sc_acpi, sc->sc_devnode, "PBLG",
> + 0, NULL, >sc_brightness) == 0) {
> + ws_get_param = thinkpad_get_param;
> + ws_set_param = thinkpad_set_param;
> + }
> +
>   /* Run thinkpad_hotkey on button presses */
>   aml_register_notify(sc->sc_devnode, aa->aaa_dev,
>   thinkpad_hotkey, sc, ACPIDEV_POLL);
> @@ -391,6 +405,9 @@ thinkpad_hotkey(struct aml_node *node, i
>   thinkpad_adaptive_change(sc);
>   handled = 1;
>   break;
> + case THINKPAD_BACKLIGHT_CHANGED:
> + thinkpad_get_brightness(sc);
> + break;
>   case THINKPAD_ADAPTIVE_BACK:
>   case THINKPAD_ADAPTIVE_GESTURES:
>   case THINKPAD_ADAPTIVE_REFRESH:
> @@ -398,7 +415,6 @@ thinkpad_hotkey(struct aml_node *node, i
>   case THINKPAD_ADAPTIVE_SNIP:
>   case THINKPAD_ADAPTIVE_TAB:
>   case THINKPAD_ADAPTIVE_VOICE:
> - case THINKPAD_BACKLIGHT_CHANGED:
>   case THINKPAD_KEYLIGHT_CHANGED:
>   case THINKPAD_BRIGHTNESS_CHANGED:
>   case THINKPAD_BUTTON_BATTERY_INFO:
> @@ -630,4 +646,63 @@ thinkpad_set_backlight(struct wskbd_back
>   acpi_addtask(sc->sc_acpi, thinkpad_set_thinklight, sc, 0);
>   acpi_wakeup(sc->sc_acpi);
>   return 0;
> +}
> +
> +void
> +thinkpad_get_brightness(struct acpithinkpad_softc *sc)
> 

Re: preparing multitouch support - request for tests

[Mike Larkin]

On Wed, Dec 16, 2015 at 12:59:00PM -0500, Ted Unangst wrote:
> Tati Chevron wrote:
> > But I don't see that touch-based devices are ever going to become the most 
> > common devices to run OpenBSD, that's not realistic.  Even ignoring servers 
> > and headless devices, and only counting devices that are used interactively 
> > in some way, I just don't see tablet devices becoming the most widely used.
> 
> Progress is not made by people saying they don't like progress.
> 

+1 what Ted said here.

Re: preparing multitouch support - request for tests

[Matthieu Herrb]

On Wed, Dec 16, 2015 at 04:11:21PM +, Tati Chevron wrote:
> 
> The touchscreen interfaces I have to use, principally on mobile phones,
> are cumbersome and irritate me no end.

Multitouch support is not only about touchscreens. There are also
modern touchpads (and not only the Apple one) which recognise
multi-touch events can be used to generate gestures like pinch, zoom,
swipe... Those are useful with many applications.

OTOH, I agree that Pure touchscreen interfaces need more work to be
useable, even under Linux.
-- 
Matthieu Herrb


signature.asc
Description: PGP signature

Re: rtdeletemsg & KASSERT

[Alexander Bluhm]

Now I got a panic with this diff.

login: panic: kernel diagnostic assertion "!ISSET(rt->rt_flags, RTF_UP)" 
failed: file "../../../../net/route.c", line 444
Stopped at  Debugger+0x9:   leave
   TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
Debugger() at Debugger+0x9
panic() at panic+0xfe
__assert() at __assert+0x25
rtfree() at rtfree+0x11e
rtable_delete() at rtable_delete+0x5d
rt_delete() at rt_delete+0x6e
rtdeletemsg() at rtdeletemsg+0x2d
arptfree() at arptfree+0x4f
arptimer() at arptimer+0x63
softclock() at softclock+0x315
softintr_dispatch() at softintr_dispatch+0x72
Xsoftclock() at Xsoftclock+0x1f
--- interrupt ---
end of kernel
end trace frame: 0x2710, count: 3
0x8:
http://www.openbsd.org/ddb.html describes the minimum info required in bug
reports.  Insufficient info makes it difficult to find and fix bugs.

It happened after running the ARP regression test.  I cannot reproduce
it by running the test.  Perhaps I have to wait for the arp timer.
The kernel is running on a single CPU qemu.

bluhm

On Wed, Dec 16, 2015 at 07:59:40PM +0100, Alexander Bluhm wrote:
> I have merged the diff to -current before reviewing.  There it looks
> like this.
> 
> Index: net/route.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/net/route.c,v
> retrieving revision 1.292
> diff -u -p -r1.292 route.c
> --- net/route.c   11 Dec 2015 08:58:23 -  1.292
> +++ net/route.c   16 Dec 2015 18:40:16 -
> @@ -159,8 +159,7 @@ struct sockaddr *rt_plentosa(sa_family_t
>  
>  struct   ifaddr *ifa_ifwithroute(int, struct sockaddr *, struct sockaddr 
> *,
>   u_int);
> -int  rtrequest_delete(struct rt_addrinfo *, u_int8_t, struct ifnet *,
> - struct rtentry **, u_int);
> +int  rt_delete(struct rtentry *, struct ifnet *, unsigned int);
>  
>  #ifdef DDB
>  void db_print_sa(struct sockaddr *);
> @@ -613,34 +612,20 @@ out:
>  }
>  
>  /*
> - * Delete a route and generate a message
> + * Delete a route and generate a message.  The caller must hold a reference
> + * on ``rt''.
>   */
>  int
> -rtdeletemsg(struct rtentry *rt, struct ifnet *ifp, u_int tableid)
> +rtdeletemsg(struct rtentry *rt, struct ifnet *ifp, unsigned int rtableid)
>  {
>   int error;
> - struct rt_addrinfo  info;
> - unsigned intifidx;
> - struct sockaddr_in6 sa_mask;
>  
>   KASSERT(rt->rt_ifidx == ifp->if_index);
>  
> - /*
> -  * Request the new route so that the entry is not actually
> -  * deleted.  That will allow the information being reported to
> -  * be accurate (and consistent with route_output()).
> -  */
> - bzero((caddr_t), sizeof(info));
> - info.rti_info[RTAX_DST] = rt_key(rt);
> - if (!ISSET(rt->rt_flags, RTF_HOST))
> - info.rti_info[RTAX_NETMASK] = rt_plen2mask(rt, _mask);
> - info.rti_info[RTAX_GATEWAY] = rt->rt_gateway;
> - info.rti_flags = rt->rt_flags;
> - ifidx = rt->rt_ifidx;
> - error = rtrequest_delete(, rt->rt_priority, ifp, , tableid);
> - rt_missmsg(RTM_DELETE, , info.rti_flags, ifidx, error, tableid);
> + error = rt_delete(rt, ifp, rtableid);
>   if (error == 0)
> - rtfree(rt);
> + rt_sendmsg(rt, RTM_DELETE, rtableid);
> +
>   return (error);
>  }
>  
> @@ -671,10 +656,13 @@ rtflushclone1(struct rtentry *rt, void *
>* the routes are being purged by rt_if_remove().
>*/
>   if (ifp == NULL)
> - return 0;
> + return 0;
>  
> - if (ISSET(rt->rt_flags, RTF_CLONED) && rtequal(rt->rt_parent, parent))
> - rtdeletemsg(rt, ifp, id);
> + if (ISSET(rt->rt_flags, RTF_CLONED) && rtequal(rt->rt_parent, parent)) {
> + rtref(rt);
> + rtdeletemsg(rt, ifp, id);
> + rtfree(rt);
> + }
>  
>   if_put(ifp);
>   return 0;
> @@ -818,60 +806,20 @@ rt_getifa(struct rt_addrinfo *info, u_in
>  }
>  
>  int
> -rtrequest_delete(struct rt_addrinfo *info, u_int8_t prio, struct ifnet *ifp,
> -struct rtentry **ret_nrt, u_int tableid)
> +rt_delete(struct rtentry *rt, struct ifnet *ifp, unsigned int rtableid)
>  {
> - struct rtentry  *rt;
> - int  error;
> -
> - splsoftassert(IPL_SOFTNET);
> + struct sockaddr_in6  sa_mask;
>  
> - if (!rtable_exists(tableid))
> - return (EAFNOSUPPORT);
> - rt = rtable_lookup(tableid, info->rti_info[RTAX_DST],
> - info->rti_info[RTAX_NETMASK], info->rti_info[RTAX_GATEWAY], prio);
> - if (rt == NULL)
> - return (ESRCH);
> + KASSERT(ifp->if_index == rt->rt_ifidx);
>  
> - /* Make sure that's the route the caller want to delete. */
> - if (ifp != NULL && ifp->if_index != rt->rt_ifidx) {
> - rtfree(rt);
> - return (ESRCH);
> - }
> -
> -#ifndef SMALL_KERNEL
> - /*
> -  * If we got multipath routes, we require users to specify
> - 

Re: rtdeletemsg & KASSERT

[Alexander Bluhm]

On Wed, Dec 16, 2015 at 08:47:02PM +0100, Alexander Bluhm wrote:
> It happened after running the ARP regression test.  I cannot reproduce
> it by running the test.  Perhaps I have to wait for the arp timer.

Reproduceable by waiting for the arp timeout, then it crashes.
I will investigate.

bluhm

root@q70:.../~# netstat -nrf inet
Routing tables

Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
10.188.70/24   10.188.70.70   UC 01 - 4 vio0 
10.188.70.17   fe:e1:ba:d0:d5:6d  UHLS   03 - 8 vio0 
10.188.70.70   70:5f:ca:21:8d:70  UHLl   0   14 - 1 vio0 
10.188.70.255  10.188.70.70   UHb00 - 1 vio0 
10.188.211/24  10.188.211.70  UC 00 - 4 vio1 
10.188.211.70  70:5f:ca:21:8d:80  UHLl   01 - 1 vio1 
10.188.211.255 10.188.211.70  UHb00 - 1 vio1 
10.188.212/24  10.188.211.71  UGS00 - 8 vio1 
10.188.213/24  10.188.211.71  UGS00 - 8 vio1 
10.188.217/24  127.0.0.1  UGRS   00 32768 8 lo0  
10.188.218/24  127.0.0.1  UGRS   00 32768 8 lo0  
127/8  127.0.0.1  UGRS   00 32768 8 lo0  
127.0.0.1  127.0.0.1  UHl00 32768 1 lo0  
224/4  127.0.0.1  URS00 32768 8 lo0  
root@q70:.../~# panic: kernel diagnostic assertion "!ISSET(rt->rt_flags, 
RTF_UP)" failed: file "../../../../net/route.c", line 444
Stopped at  Debugger+0x9:   leave
   TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
Debugger() at Debugger+0x9
panic() at panic+0xfe
__assert() at __assert+0x25
rtfree() at rtfree+0x11e
rtable_delete() at rtable_delete+0x5d
rt_delete() at rt_delete+0x6e
rtdeletemsg() at rtdeletemsg+0x2d
arptfree() at arptfree+0x4f
arptimer() at arptimer+0x63
softclock() at softclock+0x315
softintr_dispatch() at softintr_dispatch+0x72
Xsoftclock() at Xsoftclock+0x1f
--- interrupt ---
end of kernel
end trace frame: 0x2710, count: 3
0x8:
http://www.openbsd.org/ddb.html describes the minimum info required in bug
reports.  Insufficient info makes it difficult to find and fix bugs.
ddb> 

Re: initial 11n support for iwn (n, not m)

[Stefan Sperling]

On Wed, Dec 16, 2015 at 03:35:22PM +0100, Stefan Sperling wrote:
> This diff adds 11n MCS 0-7 with A-MPDU and A-MSDU Rx to the iwn(4) driver.

I went through my pile of wlan cards and found a few more iwn
devices in there.

Current test stats are:

Tested by myself, working:
iwn0 at pci3 dev 0 function 0 "Intel Centrino Advanced-N 6200" rev 0x35: msi, 
MIMO 2T2R, MoW
iwn0 at pci6 dev 0 function 0 "Intel WiFi Link 5300" rev 0x00: msi, MIMO 3T3R, 
MoW, 
iwn0 at pci6 dev 0 function 0 "Intel Centrino Ultimate-N 6300" rev 0x3e: msi, 
MIMO 3T3R, MoW
iwn0 at pci6 dev 0 function 0 "Intel WiFi Link 1000" rev 0x00: msi, MIMO 1T2R, 
BGS

Tested by others, working:
iwn0 at pci2 dev 0 function 0 "Intel Centrino Advanced-N 6205" rev 0x34: msi, 
MIMO 2T2R, MoW
iwn0 at pci2 dev 0 function 0 "Intel Centrino Ultimate-N 6300" rev 0x3e: msi, 
MIMO 3T3R, MoW

Tested by others, not working:
firmware SYSASSERT: iwn0 at pci2 dev 0 function 0 "Intel Centrino Ultimate-N 
6300" rev 0x35: msi, MIMO 3T3R, MoW

Re: preparing multitouch support - request for tests

[Tati Chevron]

On Wed, Dec 16, 2015 at 02:47:10PM -0500, Ted Unangst wrote:

Tati Chevron wrote:

On Wed, Dec 16, 2015 at 11:13:36AM -0700, Theo de Raadt wrote:
>Your emails only contain opinions.

"Questions, comments, suggestions and any kind of help would also be
welcome".

Sorry if I mis-understood the purpose of a mailing list.


Your suggestions aren't helpful. Quoting the mailling list rules isn't making
them more helpful.


I was quoting Ulf's original post!

--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com

Re: preparing multitouch support - request for tests

[Joerg Jung]

On Wed, Dec 16, 2015 at 02:32:44AM +0100, Ulf Brosziewski wrote:
> Ping? No further thoughts on this, no tests? Do I have to conclude that
> most people are happy with wsmouse as it is?

Yes and no.  As I told you earlier, I think your diffs contain some very
good work and are required for further improvements and progress.  The
question is how to get them integrated.  Further isolated work is
probably the wrong way.  You should try to get things (in small pieces)
into the tree, though likely to late in current cycle. 
 
> I'm aware that the diff isn't small, but anything smaller would make
> some of the remaining parts void and possibly blur the concept.

It depends, for example you can commit the new file additions separately
without hooking them, giving people a chance to view and play with them
in tree.  

> ... 
> 
> There is a second point concerning compat mode that I would like to
> change: it could be made useful. Because of the arbitrary scaling and
> the unpredictable pointer movement, I cannot use it with wsmoused at the
> console. Do touchpads exist where it works?  Recently Thierry Deval
> posted a diff here which proved that we could easily do something about
> that, but that is a different story. In my diff, wsmouseinput hooks its
> "touchpad extension" (wstpad) into the compat-mode conversion function,
> which works well with ws for all touchpads that are available to me.

I tend to agree that this is probably the right direction.

Re: vmx(4) incorrect m_pulldown usage

[mxb]

No regression so far.

//mxb

> On 15 dec. 2015, at 14:18, Mike Belopuhov  wrote:
> 
> Hi,
> 
> This has been in my tree for a while and I believe Yasuoka-san has
> tested it in the scenario where it was crashing.
> 
> m_pulldown is done here with a zero offset which means that if
> there's been no space reserved for the Ethernet header in the mbuf
> or the cluster it will allocate a new chunk of memory and return a
> new pointer that the vmx code ignores.  This can realistically
> happen only during the bpf injection.
> 
> The diff below makes sure to keep the modified chain pointer around
> and passes it back to the calling code so that it will get properly
> accounted for.  m_pulldown with a zero offset is equivalent to a
> m_pullup.
> 
> OK?
> 
> 
> diff --git sys/dev/pci/if_vmx.c sys/dev/pci/if_vmx.c
> index 055cfe1..50edb0b 100644
> --- sys/dev/pci/if_vmx.c
> +++ sys/dev/pci/if_vmx.c
> @@ -164,11 +164,11 @@ void vmxnet3_stop(struct ifnet *);
> void vmxnet3_reset(struct vmxnet3_softc *);
> int vmxnet3_init(struct vmxnet3_softc *);
> int vmxnet3_ioctl(struct ifnet *, u_long, caddr_t);
> void vmxnet3_start(struct ifnet *);
> int vmxnet3_load_mbuf(struct vmxnet3_softc *, struct vmxnet3_txring *,
> -struct mbuf *);
> +struct mbuf **);
> void vmxnet3_watchdog(struct ifnet *);
> void vmxnet3_media_status(struct ifnet *, struct ifmediareq *);
> int vmxnet3_media_change(struct ifnet *);
> void *vmxnet3_dma_allocmem(struct vmxnet3_softc *, u_int, u_int, bus_addr_t 
> *);
> 
> @@ -1063,11 +1063,11 @@ vmxnet3_start(struct ifnet *ifp)
> 
>   IFQ_DEQUEUE(>if_snd, m);
>   if (m == NULL)
>   break;
> 
> - n = vmxnet3_load_mbuf(sc, ring, m);
> + n = vmxnet3_load_mbuf(sc, ring, );
>   if (n == -1) {
>   ifp->if_oerrors++;
>   continue;
>   }
> 
> @@ -1087,13 +1087,14 @@ vmxnet3_start(struct ifnet *ifp)
>   }
> }
> 
> int
> vmxnet3_load_mbuf(struct vmxnet3_softc *sc, struct vmxnet3_txring *ring,
> -struct mbuf *m)
> +struct mbuf **mp)
> {
>   struct vmxnet3_txdesc *txd, *sop;
> + struct mbuf *n, *m = *mp;
>   bus_dmamap_t map;
>   u_int hlen = ETHER_HDR_LEN, csum_off;
>   u_int prod;
>   int gen, i;
> 
> @@ -1105,29 +1106,29 @@ vmxnet3_load_mbuf(struct vmxnet3_softc *sc, struct 
> vmxnet3_txring *ring,
>   sc->sc_dev.dv_xname);
>   return -1;
>   }
> #endif
>   if (m->m_pkthdr.csum_flags & (M_TCP_CSUM_OUT|M_UDP_CSUM_OUT)) {
> - struct mbuf *mp;
>   struct ip *ip;
>   int offp;
> 
>   if (m->m_pkthdr.csum_flags & M_TCP_CSUM_OUT)
>   csum_off = offsetof(struct tcphdr, th_sum);
>   else
>   csum_off = offsetof(struct udphdr, uh_sum);
> 
> - mp = m_pulldown(m, hlen, sizeof(*ip), );
> - if (mp == NULL)
> + n = m_pulldown(m, hlen, sizeof(*ip), );
> + if (n == NULL)
>   return (-1);
> 
> - ip = (struct ip *)(mp->m_data + offp);
> + ip = (struct ip *)(n->m_data + offp);
>   hlen += ip->ip_hl << 2;
> 
> - mp = m_pulldown(m, 0, hlen + csum_off + 2, );
> - if (mp == NULL)
> + *mp = m_pullup(m, hlen + csum_off + 2);
> + if (*mp == NULL)
>   return (-1);
> + m = *mp;
>   }
> 
>   switch (bus_dmamap_load_mbuf(sc->sc_dmat, map, m, BUS_DMA_NOWAIT)) {
>   case 0:
>   break;
> 

Thinkpad display brightness control

[Mark Kettenis]

Most, if not all, somewhat recent Thinkpads have some subtle issues
with display brightness control.  For example,if you change the
display brightness using wsconsctl(8) or cbacklight(1), and later use
the brightness control buttons on the keyboard, you're likely to see a
big jump in brightness.  or if you plug or unplug the power, the
display brightness will suddenly change.  The problem here is that on
these machines we us the display brightness interface provided by
inteldrm(4), which doesn't coordinate changes with the firmware.

In principle these machines support the standard acpi brightness
control interface.  However that interface is quite badly broken if
the OS claims to be Windows 8.  Unfortunately that is what we do on
OpenBSD because otherwise some other machines don't work properly.

Fortunately Thinkpads provide an alternative acpi interface through
the "hotkey" device that is handled by acpithinkpad(4).  The diff
below implements that interface.

The downside of this diff is that number of levels is limited to 16
whereas we currently have much finer granularity.  But I think that is
acceptable.  The levels are probably better calibrated and we now have
proper coordination between the OS and the firmware when it comes to
brightness changes.  On top of that, this diff will almost certainly
result in working brightness control on machines that don't have Intel
graphics.

ok?


Index: acpithinkpad.c
===
RCS file: /home/cvs/src/sys/dev/acpi/acpithinkpad.c,v
retrieving revision 1.49
diff -u -p -r1.49 acpithinkpad.c
--- acpithinkpad.c  16 Dec 2015 15:43:14 -  1.49
+++ acpithinkpad.c  16 Dec 2015 18:00:03 -
@@ -122,6 +122,8 @@ struct acpithinkpad_softc {
uint64_t sc_thinklight;
const char  *sc_thinklight_get;
const char  *sc_thinklight_set;
+
+   uint64_t sc_brightness;
 };
 
 extern void acpiec_read(struct acpiec_softc *, u_int8_t, int, u_int8_t *);
@@ -141,13 +143,19 @@ int   thinkpad_brightness_down(struct acpi
 intthinkpad_adaptive_change(struct acpithinkpad_softc *);
 intthinkpad_activate(struct device *, int);
 
-/* wskbd hook functions */
+/* wscons hook functions */
 void   thinkpad_get_thinklight(struct acpithinkpad_softc *);
 void   thinkpad_set_thinklight(void *, int);
 intthinkpad_get_backlight(struct wskbd_backlight *);
 intthinkpad_set_backlight(struct wskbd_backlight *);
 extern int (*wskbd_get_backlight)(struct wskbd_backlight *);
 extern int (*wskbd_set_backlight)(struct wskbd_backlight *);
+void   thinkpad_get_brightness(struct acpithinkpad_softc *);
+void   thinkpad_set_brightness(void *, int);
+intthinkpad_get_param(struct wsdisplay_param *);
+intthinkpad_set_param(struct wsdisplay_param *);
+extern int (*ws_get_param)(struct wsdisplay_param *);
+extern int (*ws_set_param)(struct wsdisplay_param *);
 
 voidthinkpad_sensor_attach(struct acpithinkpad_softc *sc);
 voidthinkpad_sensor_refresh(void *);
@@ -267,6 +275,12 @@ thinkpad_attach(struct device *parent, s
wskbd_set_backlight = thinkpad_set_backlight;
}
 
+   if (aml_evalinteger(sc->sc_acpi, sc->sc_devnode, "PBLG",
+   0, NULL, >sc_brightness) == 0) {
+   ws_get_param = thinkpad_get_param;
+   ws_set_param = thinkpad_set_param;
+   }
+
/* Run thinkpad_hotkey on button presses */
aml_register_notify(sc->sc_devnode, aa->aaa_dev,
thinkpad_hotkey, sc, ACPIDEV_POLL);
@@ -391,6 +405,9 @@ thinkpad_hotkey(struct aml_node *node, i
thinkpad_adaptive_change(sc);
handled = 1;
break;
+   case THINKPAD_BACKLIGHT_CHANGED:
+   thinkpad_get_brightness(sc);
+   break;
case THINKPAD_ADAPTIVE_BACK:
case THINKPAD_ADAPTIVE_GESTURES:
case THINKPAD_ADAPTIVE_REFRESH:
@@ -398,7 +415,6 @@ thinkpad_hotkey(struct aml_node *node, i
case THINKPAD_ADAPTIVE_SNIP:
case THINKPAD_ADAPTIVE_TAB:
case THINKPAD_ADAPTIVE_VOICE:
-   case THINKPAD_BACKLIGHT_CHANGED:
case THINKPAD_KEYLIGHT_CHANGED:
case THINKPAD_BRIGHTNESS_CHANGED:
case THINKPAD_BUTTON_BATTERY_INFO:
@@ -630,4 +646,63 @@ thinkpad_set_backlight(struct wskbd_back
acpi_addtask(sc->sc_acpi, thinkpad_set_thinklight, sc, 0);
acpi_wakeup(sc->sc_acpi);
return 0;
+}
+
+void
+thinkpad_get_brightness(struct acpithinkpad_softc *sc)
+{
+   aml_evalinteger(sc->sc_acpi, sc->sc_devnode,
+   "PBLG", 0, NULL, >sc_brightness);
+}
+
+void
+thinkpad_set_brightness(void *arg0, int arg1)
+{
+   struct acpithinkpad_softc *sc = arg0;
+   struct aml_value arg;
+
+   memset(, 0, sizeof(arg));
+   arg.type = 

Re: preparing multitouch support - request for tests

[Tati Chevron]

On Wed, Dec 16, 2015 at 06:29:23PM +0100, Stefan Sperling wrote:

On Wed, Dec 16, 2015 at 05:10:45PM +, Tati Chevron wrote:

why does it have to be integrated into the same mouse driver that everybody 
else uses?


Since you seem to care about this topic enough to actually contend
with what Ulf has been working on for months, let's phrase it this way:

Ulf's mails have diffs attached, and yours don't. Easy choice.


I don't see the connection.  I don't agree with the idea, nor see any
real-world use or benefit to this change.  Response of any kind on the
list has been very limited too.  Even Ulf has commented that maybe
people are happy with things the way they are.  What diffs would you
expect to see from anyone who wanted no change?

I've had several input layer diffs in my own personal tree for over
four years that were rejected by Miod as not having a general use case.
No problem.  I maintain them, because I use them.  If you and Ulf have
a use for these changes, but nobody else is interested enough to even
test and comment, why are you so worried?


As much as we'd like to keep things stable, we need to make progress, too.


But it has to be progress in a useful direction, surely?  And why can't
this all be done in a separate driver that doesn't touch wsmouse?


And of course the community is not going to accept diffs (from anyone)
which cause major regressions. So I don't see why you're so worried.


To me, the extra and unnecessary code running on every machine that
just has a PS/2 mouse, is a regression.  If we did this with everything,
we'd be Linux.  The good thing about OpenBSD for me is that it supports
a few things very well, rather than trying to support every possible use
case regardless of it's state of readiness or if it has a real value.

--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com

Re: remove language catalogs from vi

[Martijn van Duren]

ping

On 12/02/15 20:36, Martijn van Duren wrote:

Hello tech@,

I've had a discussion with bentley@ about some patches for vi. Some of
which I've send to Zhihao from the nvi2 project to keep the projects
somewhat in sync. I'm still awaiting his response on those before
sending them here.

nvi2 switched with catalog support to using the cat{open,gets,close}.
Since OpenBSD moved away from translations in general and catopen is
limited in it's usability since the default NL_CAT_LOCALE is removed I
think we should remove catalog support. bentley@ agrees with me on this
point.

Attached are four diffs, for easier reviewing, to incrementally remove
support. After the last diff the catalog directory can be removed entirely.

Martijn van Duren
diff --git common/gs.h common/gs.h
index 8d64493..8859ba7 100644
--- common/gs.h
+++ common/gs.h
@@ -74,7 +74,6 @@ struct _gs {
 #define	GO_TERM		3		/* Global options: terminal type. */
 	OPTION	 opts[GO_TERM + 1];
 
-	DB	*msg;			/* Message catalog DB. */
 	MSGH	 msgq;			/* User message list. */
 #define	DEFAULT_NOPRINT	'\1'		/* Emergency non-printable character. */
 	CHAR_T	 noprint;		/* Cached, unprintable character. */
diff --git common/main.c common/main.c
index 4669fd3..7d0fc5c 100644
--- common/main.c
+++ common/main.c
@@ -493,9 +493,6 @@ v_end(GS *gp)
 
 	/* Free default buffer storage. */
 	(void)text_lfree(>dcb_store.textq);
-
-	/* Close message catalogs. */
-	msg_close(gp);
 #endif
 
 	/* Ring the bell if scheduled. */
diff --git common/msg.c common/msg.c
index 8e0a653..f10cc91 100644
--- common/msg.c
+++ common/msg.c
@@ -497,88 +497,6 @@ alloc_err:
 }
 
 /*
- * msg_open --
- *	Open the message catalogs.
- *
- * PUBLIC: int msg_open(SCR *, char *);
- */
-int
-msg_open(SCR *sp, char *file)
-{
-	/*
-	 * !!!
-	 * Assume that the first file opened is the system default, and that
-	 * all subsequent ones user defined.  Only display error messages
-	 * if we can't open the user defined ones -- it's useful to know if
-	 * the system one wasn't there, but if nvi is being shipped with an
-	 * installed system, the file will be there, if it's not, then the
-	 * message will be repeated every time nvi is started up.
-	 */
-	static int first = 1;
-	DB *db;
-	DBT data, key;
-	recno_t msgno;
-	char *p, *t, buf[PATH_MAX];
-
-	if ((p = strrchr(file, '/')) != NULL && p[1] == '\0' &&
-	(((t = getenv("LC_MESSAGES")) != NULL && t[0] != '\0') ||
-	((t = getenv("LANG")) != NULL && t[0] != '\0'))) {
-		(void)snprintf(buf, sizeof(buf), "%s%s", file, t);
-		p = buf;
-	} else
-		p = file;
-	if ((db = dbopen(p,
-	O_NONBLOCK | O_RDONLY, 0, DB_RECNO, NULL)) == NULL) {
-		if (first) {
-			first = 0;
-			return (1);
-		}
-		msgq_str(sp, M_SYSERR, p, "%s");
-		return (1);
-	}
-
-	/*
-	 * Test record 1 for the magic string.  The msgq call is here so
-	 * the message catalog build finds it.
-	 */
-#define	VMC	"VI_MESSAGE_CATALOG"
-	key.data = 
-	key.size = sizeof(recno_t);
-	msgno = 1;
-	if (db->get(db, , , 0) != 0 ||
-	data.size != sizeof(VMC) - 1 ||
-	memcmp(data.data, VMC, sizeof(VMC) - 1)) {
-		(void)db->close(db);
-		if (first) {
-			first = 0;
-			return (1);
-		}
-		msgq_str(sp, M_ERR, p,
-		"030|The file %s is not a message catalog");
-		return (1);
-	}
-	first = 0;
-
-	if (sp->gp->msg != NULL)
-		(void)sp->gp->msg->close(sp->gp->msg);
-	sp->gp->msg = db;
-	return (0);
-}
-
-/*
- * msg_close --
- *	Close the message catalogs.
- *
- * PUBLIC: void msg_close(GS *);
- */
-void
-msg_close(GS *gp)
-{
-	if (gp->msg != NULL)
-		(void)gp->msg->close(gp->msg);
-}
-
-/*
  * msg_cont --
  *	Return common continuation messages.
  *
@@ -613,10 +531,6 @@ msg_cmsg(SCR *sp, cmsg_t which, size_t *lenp)
  * msg_cat --
  *	Return a single message from the catalog, plus its length.
  *
- * !!!
- * Only a single catalog message can be accessed at a time, if multiple
- * ones are needed, they must be copied into local memory.
- *
  * PUBLIC: const char *msg_cat(SCR *, const char *, size_t *);
  */
 const char *
@@ -631,30 +545,8 @@ msg_cat(SCR *sp, const char *str, size_t *lenp)
 	 * number and '|' symbol, we're done.
 	 */
 	if (isdigit(str[0]) &&
-	isdigit(str[1]) && isdigit(str[2]) && str[3] == '|') {
-		key.data = 
-		key.size = sizeof(recno_t);
-		msgno = atoi(str);
-
-		/*
-		 * XXX
-		 * Really sleazy hack -- we put an extra character on the
-		 * end of the format string, and then we change it to be
-		 * the nul termination of the string.  There ought to be
-		 * a better way.  Once we can allocate multiple temporary
-		 * memory buffers, maybe we can use one of them instead.
-		 */
-		gp = sp == NULL ? NULL : sp->gp;
-		if (gp != NULL && gp->msg != NULL &&
-		gp->msg->get(gp->msg, , , 0) == 0 &&
-		data.size != 0) {
-			if (lenp != NULL)
-*lenp = data.size - 1;
-			((char *)data.data)[data.size - 1] = '\0';
-			return (data.data);
-		}
+	isdigit(str[1]) && isdigit(str[2]) && str[3] == '|')
 		str = [4];
-	}
 	if (lenp != NULL)
 		*lenp = strlen(str);
 	

Re: initial 11n support for iwn (n, not m)

[Stefan Sperling]

On Wed, Dec 16, 2015 at 04:46:19PM +0100, Gregor Best wrote:
> I have done some speed testing,  but with inconclusive results. I used a
> Macbook Pro with  OS X as the  other side, testing was  done with iperf,
> both machines connected to the same WiFi:
> 
> $ iperf -i 2 -c 192.168.178.54
> 
> Client connecting to 192.168.178.54, TCP port 5001
> TCP window size: 17.0 KByte (default)
> 
> [  3] local 192.168.178.49 port 30131 connected with 192.168.178.54 port 5001
> [ ID] Interval   Transfer Bandwidth
> [  3]  0.0- 2.0 sec   768 KBytes  3.15 Mbits/sec
> [  3]  2.0- 4.0 sec   640 KBytes  2.62 Mbits/sec
> [  3]  4.0- 6.0 sec   640 KBytes  2.62 Mbits/sec
> [  3]  6.0- 8.0 sec   512 KBytes  2.10 Mbits/sec
> [  3]  8.0-10.0 sec   640 KBytes  2.62 Mbits/sec
> [  3]  0.0-10.3 sec  3.25 MBytes  2.64 Mbits/sec
> 
> I assume the low  bandwidth is due to the two  thick walls separating my
> laptops and the  access point. Everything else seems to  be fine though.
> I'll  retry the  speed  measurement in  a  few days  when  I'm home  for
> christmas.

Traffic bursts lasting less than 10s are probably too short to trigger
AMRR into raising the data rate all the way up. The initial rate is the
lowest one. The bandwidth values look about right to me, though, at least
for 2Ghz (assuming your AP is not alone somewhere on a remote island).

On 5Ghz you might see more, depending on whether the AP sends aggregated
frames for not. Run 'ifconfig iwn0 debug' and look for lines in dmesg
saying 'received action...' -- these frames are ADDBA and DELBA requests
used to negotiate use of A-MPDUs.

Re: preparing multitouch support - request for tests

[Tati Chevron]

On Wed, Dec 16, 2015 at 12:59:00PM -0500, Ted Unangst wrote:

Tati Chevron wrote:

But I don't see that touch-based devices are ever going to become the most 
common devices to run OpenBSD, that's not realistic.  Even ignoring servers and 
headless devices, and only counting devices that are used interactively in some 
way, I just don't see tablet devices becoming the most widely used.


Progress is not made by people saying they don't like progress.


I'm all for progress, but I don't see any being made, here, or in the
world of touch devices in general.

--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com

Re: preparing multitouch support - request for tests

[Theo de Raadt]

> >Ulf's mails have diffs attached, and yours don't. Easy choice.
> 
> I don't see the connection.

I definately see a connection.

Your emails only contain opinions.

Re: preparing multitouch support - request for tests

[Tati Chevron]

On Wed, Dec 16, 2015 at 11:13:36AM -0700, Theo de Raadt wrote:

Your emails only contain opinions.


"Questions, comments, suggestions and any kind of help would also be
welcome".

Sorry if I mis-understood the purpose of a mailing list.

--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com

Re: preparing multitouch support - request for tests

[Ted Unangst]

Tati Chevron wrote:
> But I don't see that touch-based devices are ever going to become the most 
> common devices to run OpenBSD, that's not realistic.  Even ignoring servers 
> and headless devices, and only counting devices that are used interactively 
> in some way, I just don't see tablet devices becoming the most widely used.

Progress is not made by people saying they don't like progress.

Re: preparing multitouch support - request for tests

[Theo de Raadt]

> >Tati Chevron wrote:
> >> But I don't see that touch-based devices are ever going to become the most 
> >> common devices to run OpenBSD, that's not realistic.  Even ignoring 
> >> servers and headless devices, and only counting devices that are used 
> >> interactively in some way, I just don't see tablet devices becoming the 
> >> most widely used.
> >
> >Progress is not made by people saying they don't like progress.
> 
> I'm all for progress, but I don't see any being made, here, or in the
> world of touch devices in general.

words words words words

Are you done?

Re: [patch] sys_execve: clean up code that prepares args and env

[Maxim Pugachev]

Ping?

On Sat, Dec 12, 2015 at 8:38 PM, Maxim Pugachev  wrote:
> Hi,
>
> This patch removes copypasted code that prepares args and env in exec
> system call.
>
>
> Index: sys/kern/kern_exec.c
> ===
> RCS file: /cvs/src/sys/kern/kern_exec.c,v
> retrieving revision 1.173
> diff -u -p -r1.173 kern_exec.c
> --- sys/kern/kern_exec.c5 Dec 2015 10:11:53 -   1.173
> +++ sys/kern/kern_exec.c12 Dec 2015 17:34:43 -
> @@ -77,6 +77,12 @@ const struct kmem_va_mode kv_exec = {
> .kv_map = _map
>  };
>
> +struct argcontext
> +{
> +   char *buffer;
> +   char *bptr;
> +};
> +
>  /*
>   * Map the shared signal code.
>   */
> @@ -231,6 +237,58 @@ bad1:
> return (error);
>  }
>
> +void
> +copy_fake_args(struct exec_package *pack, struct argcontext *argctx,
> +long *count)
> +{
> +   char **fake_args_vec = pack->ep_fa;
> +
> +   while (*fake_args_vec != NULL) {
> +   char *arg = *fake_args_vec;
> +
> +   while (*arg)
> +   *argctx->bptr++ = *arg++;
> +
> +   *argctx->bptr++ = '\0';
> +
> +   free(*fake_args_vec, M_EXEC, 0);
> +
> +   fake_args_vec++;
> +   (*count)++;
> +   }
> +
> +   free(pack->ep_fa, M_EXEC, 0);
> +   pack->ep_flags &= ~EXEC_HASARGL;
> +}
> +
> +int
> +copy_strings(char * const *src, struct argcontext *argctx, long *count)
> +{
> +   int error;
> +   size_t len;
> +   size_t maxlen = argctx->buffer + ARG_MAX - argctx->bptr;
> +   char *sp;
> +
> +   while (1) {
> +   if ((error = copyin(src, , sizeof(sp))) != 0)
> +   return error;
> +   if (!sp)
> +   break;
> +   if ((error = copyinstr(sp, argctx->bptr, maxlen, )) != 0) 
> {
> +   if (error == ENAMETOOLONG)
> +   error = E2BIG;
> +   return error;
> +   }
> +
> +   maxlen -= len;
> +   argctx->bptr += len;
> +   src++;
> +   (*count)++;
> +   }
> +
> +   return 0;
> +}
> +
>  /*
>   * exec system call
>   */
> @@ -242,13 +300,13 @@ sys_execve(struct proc *p, void *v, regi
> syscallarg(char *const *) argp;
> syscallarg(char *const *) envp;
> } */ *uap = v;
> +   struct argcontext argctx;
> int error;
> struct exec_package pack;
> struct nameidata nid;
> struct vattr attr;
> struct ucred *cred = p->p_ucred;
> -   char *argp;
> -   char * const *cpp, *dp, *sp;
> +   char * const *cpp;
>  #ifdef KTRACE
> char *env_start;
>  #endif
> @@ -261,7 +319,6 @@ sys_execve(struct proc *p, void *v, regi
> char *stack;
> struct ps_strings arginfo;
> struct vmspace *vm = pr->ps_vmspace;
> -   char **tmpfap;
> extern struct emul emul_native;
>  #if NSYSTRACE > 0
> int wassugid = ISSET(pr->ps_flags, PS_SUGID | PS_SUGIDEXEC);
> @@ -317,38 +374,23 @@ sys_execve(struct proc *p, void *v, regi
> pack.ep_flags = 0;
>
> /* see if we can run it. */
> -   if ((error = check_exec(p, )) != 0) {
> +   if ((error = check_exec(p, )) != 0)
> goto freehdr;
> -   }
>
> /* XXX -- THE FOLLOWING SECTION NEEDS MAJOR CLEANUP */
> -
> +
> /* allocate an argument buffer */
> -   argp = km_alloc(NCARGS, _exec, _pageable, _waitok);
> +   argctx.buffer = km_alloc(NCARGS, _exec, _pageable, _waitok);
>  #ifdef DIAGNOSTIC
> -   if (argp == NULL)
> -   panic("execve: argp == NULL");
> +   if (argctx.buffer == NULL)
> +   panic("execve: argctx.buffer == NULL");
>  #endif
> -   dp = argp;
> +   argctx.bptr = argctx.buffer;
> argc = 0;
>
> /* copy the fake args list, if there's one, freeing it as we go */
> -   if (pack.ep_flags & EXEC_HASARGL) {
> -   tmpfap = pack.ep_fa;
> -   while (*tmpfap != NULL) {
> -   char *cp;
> -
> -   cp = *tmpfap;
> -   while (*cp)
> -   *dp++ = *cp++;
> -   *dp++ = '\0';
> -
> -   free(*tmpfap, M_EXEC, 0);
> -   tmpfap++; argc++;
> -   }
> -   free(pack.ep_fa, M_EXEC, 0);
> -   pack.ep_flags &= ~EXEC_HASARGL;
> -   }
> +   if (pack.ep_flags & EXEC_HASARGL)
> +   copy_fake_args(, , );
>
> /* Now get argv & environment */
> if (!(cpp = SCARG(uap, argp))) {
> @@ -359,21 +401,9 @@ sys_execve(struct proc *p, void *v, regi
> if (pack.ep_flags & EXEC_SKIPARG)
> cpp++;
>
> -   while (1) {
> -   len = argp + ARG_MAX - dp;
> -   if ((error = 

Re: rtdeletemsg & KASSERT

[Alexander Bluhm]

On Mon, Dec 07, 2015 at 04:36:17PM +0100, Martin Pieuchot wrote:
> The rtrequest_delete() refactoring exposed an existing bug and
> introduced a regression, both triggered by the same KASSERT().
> 
> The regression has been reported there:
>   https://marc.info/?l=openbsd-bugs=144943901304713=2
> 
> The problem is that rt_if_remove() will triggers a rtflushclone1() if a
> RTF_CLONING route is attached to an interface.  In this case
> rtdeletemsg() tries to get the interface pointer from rt_ifidx and the
> KASSERT() fires.
> 
> The bug exposed by the same KASSERT() can be triggered by a call to
> rt_ifa_del() when dhclient(8) tries to add an address already configured
> on the system.  In this case the kernel calls rtrequest_delete() with
> a wrong ifp.
> 
> Diff below fixes these two bugs.  It's big because I don't want to put
> two customs checks in a generic function.  This diff is built upon my
> previous rtdeletemsg() one.
> 
> It introduces rt_delete() which deletes a route *without* doing a
> lookup.  There's various good reasons for that.
>   - First of all I don't want to take the risk of matching a similar
> multipath route.  The rt_ifa_del() bug is an example. 
>   - Secondly I'd like to avoid a recursive rtable_* call when routes
> are deleted from rtable_walk().
>   - Then I'd rather keep userland-specific checks inside rtrequest()
> which will ends up in rtsock.c one day.
>   - Finally it cleans one use of "struct rt_addrinfo" which should be
> limited to userland in order to get rid of RTA_NETMASK in kernel.
> 
> Note that it introduces a behavior change.  If rtdeletemsg() fails to
> delete a route no message is reported to userland.  I believe this was
> only used for debugging.

OK bluhm@

I have merged the diff to -current before reviewing.  There it looks
like this.

Index: net/route.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/net/route.c,v
retrieving revision 1.292
diff -u -p -r1.292 route.c
--- net/route.c 11 Dec 2015 08:58:23 -  1.292
+++ net/route.c 16 Dec 2015 18:40:16 -
@@ -159,8 +159,7 @@ struct sockaddr *rt_plentosa(sa_family_t
 
 struct ifaddr *ifa_ifwithroute(int, struct sockaddr *, struct sockaddr *,
u_int);
-intrtrequest_delete(struct rt_addrinfo *, u_int8_t, struct ifnet *,
-   struct rtentry **, u_int);
+intrt_delete(struct rtentry *, struct ifnet *, unsigned int);
 
 #ifdef DDB
 void   db_print_sa(struct sockaddr *);
@@ -613,34 +612,20 @@ out:
 }
 
 /*
- * Delete a route and generate a message
+ * Delete a route and generate a message.  The caller must hold a reference
+ * on ``rt''.
  */
 int
-rtdeletemsg(struct rtentry *rt, struct ifnet *ifp, u_int tableid)
+rtdeletemsg(struct rtentry *rt, struct ifnet *ifp, unsigned int rtableid)
 {
int error;
-   struct rt_addrinfo  info;
-   unsigned intifidx;
-   struct sockaddr_in6 sa_mask;
 
KASSERT(rt->rt_ifidx == ifp->if_index);
 
-   /*
-* Request the new route so that the entry is not actually
-* deleted.  That will allow the information being reported to
-* be accurate (and consistent with route_output()).
-*/
-   bzero((caddr_t), sizeof(info));
-   info.rti_info[RTAX_DST] = rt_key(rt);
-   if (!ISSET(rt->rt_flags, RTF_HOST))
-   info.rti_info[RTAX_NETMASK] = rt_plen2mask(rt, _mask);
-   info.rti_info[RTAX_GATEWAY] = rt->rt_gateway;
-   info.rti_flags = rt->rt_flags;
-   ifidx = rt->rt_ifidx;
-   error = rtrequest_delete(, rt->rt_priority, ifp, , tableid);
-   rt_missmsg(RTM_DELETE, , info.rti_flags, ifidx, error, tableid);
+   error = rt_delete(rt, ifp, rtableid);
if (error == 0)
-   rtfree(rt);
+   rt_sendmsg(rt, RTM_DELETE, rtableid);
+
return (error);
 }
 
@@ -671,10 +656,13 @@ rtflushclone1(struct rtentry *rt, void *
 * the routes are being purged by rt_if_remove().
 */
if (ifp == NULL)
-   return 0;
+   return 0;
 
-   if (ISSET(rt->rt_flags, RTF_CLONED) && rtequal(rt->rt_parent, parent))
-   rtdeletemsg(rt, ifp, id);
+   if (ISSET(rt->rt_flags, RTF_CLONED) && rtequal(rt->rt_parent, parent)) {
+   rtref(rt);
+   rtdeletemsg(rt, ifp, id);
+   rtfree(rt);
+   }
 
if_put(ifp);
return 0;
@@ -818,60 +806,20 @@ rt_getifa(struct rt_addrinfo *info, u_in
 }
 
 int
-rtrequest_delete(struct rt_addrinfo *info, u_int8_t prio, struct ifnet *ifp,
-struct rtentry **ret_nrt, u_int tableid)
+rt_delete(struct rtentry *rt, struct ifnet *ifp, unsigned int rtableid)
 {
-   struct rtentry  *rt;
-   int  error;
-
-   splsoftassert(IPL_SOFTNET);
+   struct sockaddr_in6  sa_mask;
 
-   if (!rtable_exists(tableid))
-   return (EAFNOSUPPORT);
-   rt = 

Re: rtdeletemsg & KASSERT

[Alexander Bluhm]

On Wed, Dec 16, 2015 at 09:46:26PM +0100, Alexander Bluhm wrote:
> 10.188.70.17   fe:e1:ba:d0:d5:6d  UHLS   03 - 8 vio0 

This is this route that crashed the machine when the arp entry expired.

When I move the rtref()/rtfree() calls into rtdeletemsg() it also
protects the calls from arptfree().

> __assert() at __assert+0x25
> rtfree() at rtfree+0x11e
> rtable_delete() at rtable_delete+0x5d
> rt_delete() at rt_delete+0x6e
> rtdeletemsg() at rtdeletemsg+0x2d
> arptfree() at arptfree+0x4f
> arptimer() at arptimer+0x63

After rt_delete() has called rtable_delete(), the route is still
used and should not be destroyed.

bluhm

Index: net/route.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/net/route.c,v
retrieving revision 1.292
diff -u -p -r1.292 route.c
--- net/route.c 11 Dec 2015 08:58:23 -  1.292
+++ net/route.c 16 Dec 2015 22:42:34 -
@@ -159,8 +159,7 @@ struct sockaddr *rt_plentosa(sa_family_t
 
 struct ifaddr *ifa_ifwithroute(int, struct sockaddr *, struct sockaddr *,
u_int);
-intrtrequest_delete(struct rt_addrinfo *, u_int8_t, struct ifnet *,
-   struct rtentry **, u_int);
+intrt_delete(struct rtentry *, struct ifnet *, unsigned int);
 
 #ifdef DDB
 void   db_print_sa(struct sockaddr *);
@@ -613,34 +612,22 @@ out:
 }
 
 /*
- * Delete a route and generate a message
+ * Delete a route and generate a message.  The caller must hold a reference
+ * on ``rt''.
  */
 int
-rtdeletemsg(struct rtentry *rt, struct ifnet *ifp, u_int tableid)
+rtdeletemsg(struct rtentry *rt, struct ifnet *ifp, unsigned int rtableid)
 {
int error;
-   struct rt_addrinfo  info;
-   unsigned intifidx;
-   struct sockaddr_in6 sa_mask;
 
KASSERT(rt->rt_ifidx == ifp->if_index);
 
-   /*
-* Request the new route so that the entry is not actually
-* deleted.  That will allow the information being reported to
-* be accurate (and consistent with route_output()).
-*/
-   bzero((caddr_t), sizeof(info));
-   info.rti_info[RTAX_DST] = rt_key(rt);
-   if (!ISSET(rt->rt_flags, RTF_HOST))
-   info.rti_info[RTAX_NETMASK] = rt_plen2mask(rt, _mask);
-   info.rti_info[RTAX_GATEWAY] = rt->rt_gateway;
-   info.rti_flags = rt->rt_flags;
-   ifidx = rt->rt_ifidx;
-   error = rtrequest_delete(, rt->rt_priority, ifp, , tableid);
-   rt_missmsg(RTM_DELETE, , info.rti_flags, ifidx, error, tableid);
+   rtref(rt);
+   error = rt_delete(rt, ifp, rtableid);
if (error == 0)
-   rtfree(rt);
+   rt_sendmsg(rt, RTM_DELETE, rtableid);
+   rtfree(rt);
+
return (error);
 }
 
@@ -671,10 +658,10 @@ rtflushclone1(struct rtentry *rt, void *
 * the routes are being purged by rt_if_remove().
 */
if (ifp == NULL)
-   return 0;
+   return 0;
 
if (ISSET(rt->rt_flags, RTF_CLONED) && rtequal(rt->rt_parent, parent))
-   rtdeletemsg(rt, ifp, id);
+   rtdeletemsg(rt, ifp, id);
 
if_put(ifp);
return 0;
@@ -818,60 +805,20 @@ rt_getifa(struct rt_addrinfo *info, u_in
 }
 
 int
-rtrequest_delete(struct rt_addrinfo *info, u_int8_t prio, struct ifnet *ifp,
-struct rtentry **ret_nrt, u_int tableid)
+rt_delete(struct rtentry *rt, struct ifnet *ifp, unsigned int rtableid)
 {
-   struct rtentry  *rt;
-   int  error;
-
-   splsoftassert(IPL_SOFTNET);
-
-   if (!rtable_exists(tableid))
-   return (EAFNOSUPPORT);
-   rt = rtable_lookup(tableid, info->rti_info[RTAX_DST],
-   info->rti_info[RTAX_NETMASK], info->rti_info[RTAX_GATEWAY], prio);
-   if (rt == NULL)
-   return (ESRCH);
-
-   /* Make sure that's the route the caller want to delete. */
-   if (ifp != NULL && ifp->if_index != rt->rt_ifidx) {
-   rtfree(rt);
-   return (ESRCH);
-   }
+   struct sockaddr_in6  sa_mask;
 
-#ifndef SMALL_KERNEL
-   /*
-* If we got multipath routes, we require users to specify
-* a matching gateway.
-*/
-   if ((rt->rt_flags & RTF_MPATH) &&
-   info->rti_info[RTAX_GATEWAY] == NULL) {
-   rtfree(rt);
-   return (ESRCH);
-   }
-#endif
+   KASSERT(ifp->if_index == rt->rt_ifidx);
 
-   /*
-* Since RTP_LOCAL cannot be set by userland, make
-* sure that local routes are only modified by the
-* kernel.
-*/
-   if ((rt->rt_flags & (RTF_LOCAL|RTF_BROADCAST)) &&
-   prio != RTP_LOCAL) {
-   rtfree(rt);
-   return (EINVAL);
-   }
+   splsoftassert(IPL_SOFTNET);
 
-   error = rtable_delete(tableid, info->rti_info[RTAX_DST],
-   info->rti_info[RTAX_NETMASK], rt);
-   if (error != 0) {
-   rtfree(rt);
+   

Re: ntpd setting date incorrectly

[Ian Mcwilliam]

Patch works.

hw.sensors.vmt0.timedelta0=0.000109 secs, OK, Thu Dec 17 09:29:31.932


Dec 17 09:29:19 ianm-openbsd ntpd[882]: ntp engine ready
Dec 17 09:29:20 ianm-openbsd ntpd[5528]: set local clock to Thu Dec 17 09:29:20 
AEDT 2015 (offset 0.937695s)
Dec 17 09:29:20 ianm-openbsd savecore: no core dump
Dec 17 09:29:21 ianm-openbsd apmd: battery status: absent. external power 
status: connected. estimated battery life 0%
Dec 17 09:29:22 ianm-openbsd ntpd[882]: constraint reply from 216.58.220.132: 
offset -0.635569
Dec 17 09:29:42 ianm-openbsd ntpd[882]: peer 129.250.35.251 now valid
Dec 17 09:29:43 ianm-openbsd ntpd[882]: peer 121.0.0.42 now valid
Dec 17 09:29:43 ianm-openbsd ntpd[882]: peer 121.0.0.41 now valid
Dec 17 09:29:48 ianm-openbsd ntpd[882]: peer 202.127.210.36 now valid
Dec 17 09:30:47 ianm-openbsd ntpd[12574]: adjusting local clock by 0.054113s

I'll keep an eye out for any further issues.

Thanks.

Ian McWilliam


From: Martin Pieuchot [m...@openbsd.org]
Sent: Thursday, 17 December 2015 1:31 AM
To: Mike Belopuhov
Cc: Ian Mcwilliam; tech@openbsd.org
Subject: Re: ntpd setting date incorrectly

On 16/12/15(Wed) 14:56, Mike Belopuhov wrote:
> On Wed, Dec 16, 2015 at 03:53 +, Ian Mcwilliam wrote:
> >
> > Disable sensors * in ntpd.conf and time is good again.
> >
> > I see this on boot up when things go strange.
> >
> > hw.sensors.vmt0.timedelta0=1450237689.498077 secs, OK, Tue Nov 29 
> > 18:36:38.371
> >
> > I wonder if it's related to this change? Thoughts?
> >
>
> Bah, I've noticed that, but forgot to mention this to mpi@.
> Martin, what has prompted you to change the behaviour here?
> It's the only spot in that commit that has changed the
> mountroot to a startup hook.

Because this driver is using the same function for a hook and a timer,
both taking (void *) pointer.

I don't understand for which reason this driver is using a hook, but
tell me if this works.

Index: dev/pv/vmt.c
===
RCS file: /cvs/src/sys/dev/pv/vmt.c,v
retrieving revision 1.6
diff -u -p -r1.6 vmt.c
--- dev/pv/vmt.c11 Dec 2015 16:07:01 -  1.6
+++ dev/pv/vmt.c16 Dec 2015 14:29:54 -
@@ -208,6 +208,7 @@ void vmt_shutdown(void *);
 voidvmt_update_guest_info(struct vmt_softc *);
 voidvmt_update_guest_uptime(struct vmt_softc *);

+voidvmt_tick_hook(struct device *self);
 voidvmt_tick(void *);
 voidvmt_resume(void);

@@ -364,9 +365,7 @@ vmt_attach(struct device *parent, struct
sensor_attach(>sc_sensordev, >sc_sensor);
sensordev_install(>sc_sensordev);

-   timeout_set(>sc_tick, vmt_tick, sc);
-   if (startuphook_establish(vmt_tick, sc) == NULL)
-   DPRINTF("%s: unable to establish tick\n", DEVNAME(sc));
+   config_mountroot(self, vmt_tick_hook);

timeout_set(>sc_tclo_tick, vmt_tclo_tick, sc);
timeout_add_sec(>sc_tclo_tick, 1);
@@ -467,6 +466,15 @@ vmt_update_guest_info(struct vmt_softc *

sc->sc_set_guest_os = 1;
}
+}
+
+void
+vmt_tick_hook(struct device *self)
+{
+   struct vmt_softc *sc = (struct vmt_softc *)self;
+
+   timeout_set(>sc_tick, vmt_tick, sc);
+   vmt_tick(sc);
 }

 void

Re: initial 11n support for iwn (n, not m)

[David Hill]

On Wed, Dec 16, 2015 at 05:15:27PM +0100, Stefan Sperling wrote:
> On Wed, Dec 16, 2015 at 10:14:49AM -0500, David Hill wrote:
> > Hi Stefan -
> > 
> > Thanks for the 11n work!
> > 
> > Unfortunately, your diff breaks iwn on my machine.
> > 
> > iwn0 at pci2 dev 0 function 0 "Intel Centrino Ultimate-N 6300" rev 0x35:
> > msi, MIMO 3T3R, MoW, 
> > 
> > It spews over and over:
> > 
> > iwn0: fatal firmware error
> > firmware error log:
> >   error type  = "SYSASSERT" (0x0005)
> >   program counter = 0x00022278
> >   source line = 0x0218
> >   error data  = 0x0218000B
> >   branch link = 0x0002225800022258
> >   interrupt link  = 0x1532
> >   time= 2127856977
> > driver status:
> >   tx ring  0: qid=0  cur=4   queued=0  
> >   tx ring  1: qid=1  cur=0   queued=0  
> >   tx ring  2: qid=2  cur=0   queued=0  
> >   tx ring  3: qid=3  cur=0   queued=0  
> >   tx ring  4: qid=4  cur=41  queued=0  
> >   tx ring  5: qid=5  cur=0   queued=0  
> >   tx ring  6: qid=6  cur=0   queued=0  
> >   tx ring  7: qid=7  cur=0   queued=0  
> >   tx ring  8: qid=8  cur=0   queued=0  
> >   tx ring  9: qid=9  cur=0   queued=0  
> >   tx ring 10: qid=10 cur=0   queued=0  
> >   tx ring 11: qid=11 cur=0   queued=0  
> >   tx ring 12: qid=12 cur=0   queued=0  
> >   tx ring 13: qid=13 cur=0   queued=0  
> >   tx ring 14: qid=14 cur=0   queued=0  
> >   tx ring 15: qid=15 cur=0   queued=0  
> >   tx ring 16: qid=16 cur=0   queued=0  
> >   tx ring 17: qid=17 cur=0   queued=0  
> >   tx ring 18: qid=18 cur=0   queued=0  
> >   tx ring 19: qid=19 cur=0   queued=0  
> >   rx ring: cur=14
> >   802.11 state 4
> > 
> 
> Thanks for testing!
> 
> I cannot do much based on the information provided.
> Could you recompile with IWM_DEBUG defined, and perhaps place a few
> additional printfs at strategic locations, to figure out which
> firmware command is last sent before the firmware crashes?
> That would help me a great deal.
> 
> If you don't want the firmware to be restarted over and over so it
> won't print these lines repeatedly, disabling the init_task which
> attempts to recover from firmware crashes might help:
> 
>   if (r1 & (IWN_INT_SW_ERR | IWN_INT_HW_ERR)) {
>   printf("%s: fatal firmware error\n", sc->sc_dev.dv_xname);
>   /* Dump firmware error log and stop. */
>   iwn_fatal_intr(sc);
>   iwn_stop(ifp, 1);
>   task_add(systq, >init_task); <-- remove this line
>   return 1;
>   }
>


Little more time to play, but not much. Will play more tonight.

I do not have open wifi to test with, wpakey required.

16:21:14.335908 802.11 flags=0<>: probe response,
caps=2061, ssid (wifi),
rates 1M 2M 5M 11M 6M 9M 12M 18M, ds (chan 11), country 'US ', erp 0x00,
rsn 0x010fac04010fac04010fac02, xrates 24M 36M 48M 54M,
htcaps=<20MHz,TXSTBC,RXSTBC 1 stream,A-MSDU 3839,A-MPDU max 65535,A-MPDU
spacing 8.00us,RxMCS 0x>, 

ifconfig iwn0 up works
ifconfig iwn0 scan works

but as soon as I use nwid/wpakey to associate, it bombs.

...

sending scan command nchan=24
scan finished nchan=24 status=1 chan=165
sending scan command nchan=13
scan finished nchan=13 status=1 chan=13
sending scan command nchan=24
scan finished nchan=24 status=1 chan=165
rxon chan 11 flags 40008025 cck f ofdm 15 
setting TX power
adding broadcast node
timing bintval=400, tstamp=5529864295299, init=306301
iwn_run: htprot = 3
rxon chan 11 flags 44008035 cck f ofdm 15
setting TX power
adding BSS node
setting link quality for node 0 
setting initial differential gains
sending request for statistics
iwn0: fatal firmware error
firmware error log:
  error type  = "SYSASSERT" (0x0005)
  program counter = 0x00022278
  source line = 0x0218
  error data  = 0x0218000B
  branch link = 0x0002225800022258
  interrupt link  = 0x1532
  time= 2241458206
driver status:
  tx ring  0: qid=0  cur=2   queued=0
  tx ring  1: qid=1  cur=0   queued=0
  tx ring  2: qid=2  cur=0   queued=0
  tx ring  3: qid=3  cur=0   queued=0
  tx ring  4: qid=4  cur=63  queued=0
  tx ring  5: qid=5  cur=0   queued=0
  tx ring  6: qid=6  cur=0   queued=0
  tx ring  7: qid=7  cur=0   queued=0
  tx ring  8: qid=8  cur=0   queued=0
  tx ring  9: qid=9  cur=0   queued=0
  tx ring 10: qid=10 cur=0   queued=0
  tx ring 11: qid=11 cur=0   queued=0
  tx ring 12: qid=12 cur=0   queued=0
  tx ring 13: qid=13 cur=0   queued=0
  tx ring 14: qid=14 cur=0   queued=0
  tx ring 15: qid=15 cur=0   queued=0
  tx ring 16: qid=16 cur=0   queued=0
  tx ring 17: qid=17 cur=0   queued=0
  tx ring 18: qid=18 cur=0   queued=0
  tx ring 19: qid=19 cur=0   queued=0
  rx ring: cur=20
  802.11 state 4

Re: OPENBSD performance // intel NIC interrupts // interrupt moderation

[Michael McConville]

That dmesg got pretty severely mangled by Yahoo. Could you send it
through an email client like Mutt or Thunderbird?

Re: OPENBSD performance // intel NIC interrupts // interrupt moderation

[Jeff Drago]

 Michael, I just upgraded my box to 5.8, and, for my surprise the CPU usage was 
worst... I was able to use 100% of the cpu0 and the latency started to increase.
Here is my dmesg output:

OpenBSD 5.8 (GENERIC.MP) #1236: Sun Aug 16 02:31:04 MDT 2015    
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MPreal mem = 
8559443968 (8162MB)avail mem = 8296136704 (7911MB)mpath0 at rootscsibus0 at 
mpath0: 256 targetsmainbus0 at rootbios0 at mainbus0: SMBIOS rev. 2.8 @ 
0x7f525000 (53 entries)bios0: vendor American Megatrends Inc. version "5.6.5" 
date 08/26/2014acpi0 at bios0: rev 2acpi0: sleep states S0 S5acpi0: tables DSDT 
FACP FPDT MCFG WDAT UEFI APIC BDAT HPET SSDT SPCR HEST BERT E                   
                                                                                
                  RST EINJacpi0: wakeup devices SIO1(S0) PEX1(S0) PEX2(S0) 
PEX3(S0) PEX4(S0) EHC1(S0)acpitimer0 at acpi0: 3579545 Hz, 24 bitsacpimcfg0 at 
acpi0 addr 0xe000, bus 0-255acpimadt0 at acpi0 addr 0xfee0: PC-AT 
compatcpu0 at mainbus0: apid 0 (boot processor)cpu0: Intel(R) Atom(TM) CPU 
C2758 @ 2.41GHz, 2417.11 MHzcpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF      
                                                                                
                               
LUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
                                                                                
                                     
,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE
                                                                                
                                     
,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARATcpu0: 1MB 64b/line 16-way L2 
cachecpu0: smt 0, core 0, package 0mtrr: Pentium Pro MTRR support, 8 var 
ranges, 88 fixed rangescpu0: apic clock running at 83MHzcpu0: mwait min=64, 
max=64, C-substates=0.2.0.0.0.0.3, IBEcpu1 at mainbus0: apid 2 (application 
processor)cpu1: Intel(R) Atom(TM) CPU C2758 @ 2.41GHz, 2416.67 MHzcpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF      
                                                                                
                               
LUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
                                                                                
                                     
,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE
                                                                                
                                     
,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARATcpu1: 1MB 64b/line 16-way L2 
cachecpu1: smt 0, core 1, package 0cpu2 at mainbus0: apid 4 (application 
processor)cpu2: Intel(R) Atom(TM) CPU C2758 @ 2.41GHz, 2416.67 MHzcpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF      
                                                                                
                               
LUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
                                                                                
                                     
,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE
                                                                                
                                     
,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARATcpu2: 1MB 64b/line 16-way L2 
cachecpu2: smt 0, core 2, package 0cpu3 at mainbus0: apid 6 (application 
processor)cpu3: Intel(R) Atom(TM) CPU C2758 @ 2.41GHz, 2416.67 MHzcpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF      
                                                                                
                               
LUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
                                                                                
                                     
,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE
                                                                                
                                     
,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARATcpu3: 1MB 64b/line 16-way L2 
cachecpu3: smt 0, core 3, package 0cpu4 at mainbus0: apid 8 (application 
processor)cpu4: Intel(R) Atom(TM) CPU C2758 @ 2.41GHz, 2416.67 MHzcpu4: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF      
                                                                                
                               
LUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
                                                                                
                                     

Re: preparing multitouch support - request for tests

[Ulf Brosziewski]

On 12/16/2015 03:11 PM, Matthieu Herrb wrote:

On Wed, Dec 16, 2015 at 02:32:44AM +0100, Ulf Brosziewski wrote:

Ping? No further thoughts on this, no tests? Do I have to conclude that
most people are happy with wsmouse as it is?


Hi,

I'd like to see things move forward, but I currently lack time to do
anything serious on this.

One thing is not clear to me after looking (quickly) at your patch and
trying it: how does this work integrate with the libinput port ?



I hope it keeps various options open. Something like the wsmouseinput
part, which tracks input states and produces events, is necessary
anyway, would you agree with that? Quite generally, there might be three
strategies for porting libinput:
1) We could try to make a port with a minimal change of the libinput
sources. I'm afraid this would require making our input framework
"libinput-compatible" and trying to rebuild at least a half of evdev.
2) We could try to separate the "reusable" parts of the libinput code
and replace the rest with new developments. I don't know what the
ratio would be, and whether the advantages would outweigh the
difficulties.
3) We provide a "thin" libinput layer that supports its API and is
backed by extended kernel functionality. This might be the most
flexible solution. Various mixtures of 3) and 2) will also be
possible.

Some work on a port that aims at 3) has already been done, and the
"touchpad extension" in my diff (wstpad) could support such a
solution.

With or without wstpad, it will be necessary to extend the event
system, and probably not only with a zoo of new (MT) type codes.

The wsmouse_configure() function and the struct wsmousehw might be
a base for handling extended informations about the devices. Perhaps
it isn't well-structured, and it will change in the future; but both
the basic MT suppport as well as wstpad already needed more than
wsconsio provides.

Using ws with touchpads isn't intended to be the end of the story
in this form. An unchanged ws isn't ideal, e.g., with respect to things
like acceleration and deceleration (I had to add a "deceleration"
feature because least the default acceleration profiles don't work well
with touchpads; but this means that similar and related operations are
scattered between distinct layers).


 From what I understand from libinput, it moves a lot of the code that
maps low-level events to higher-level X events (for multi-touch, but
also for features like 2 fingers scrolling or side scrolling) from the
kernel to libinput itself.

With libinput, xf86-input-ws should be replaced by xf86-input-libinput
and there is no need to hack on xf86-input-ws anymore.

I've the impression that here you're adding this code to the kernel.

Please correct me if I'm wrong.

There is also the fact that I'm conviced that xinput (and libinput)
needs more information about the individual input device than what is
currently exposed through wsconsio. This is probably even more true
for multi-touch devices, since they have such a large set of possible
features..



I'm aware that the diff isn't small, but anything smaller would make
some of the remaining parts void and possibly blur the concept. The core
of the approach is actually quite simple: wsmouse_input() will be
replaced by a set of functions for reporting state, and by
wsmouse_input_sync(), which generates the wscons events (please note
that it doesn't produce MT events yet; there are no userland drivers
that could use them). Running mice, and tablets and touchpads that can
only track a single contact wouldn't need much more. MT support needs
some bits of configuration: the number of touches that might be tracked
simultaneously, and the information whether a buffer for "MT tracking"
is required.

For use with the synaptics driver, MT input from touchpads must be
converted into a single-touch representation, and this conversion is
based on a mechanism that selects a "pointer-controlling" slot. The
implementation generalizes the method currently applied by the
Elantech-v4 packet handler in pms.

Single-touch representations are also the base for handling
"compat-mode" of touchpads in wsmouse. Currently, each hardware driver
tracks absolute coordinates in its device data, and has a compat-mode
branch in its packet handler that computes relative coordinates, applies
a more or less arbitrary scaling to them, and calls wsmouse_input() with
the "DELTA" flags. This is not only ugly, it would be even more ugly for
touchpad drivers that use the new MT functions: It would still require a
driver-internal representation of the input, a driver-internal selection
of the pointer-controlling touch, etc. That's obviously nonsense, compat
mode should be handled by wsmouse. However, it requires some
configuration.

There is a second point concerning compat mode that I would like to
change: it could be made useful. Because of the arbitrary scaling and
the unpredictable pointer movement, I cannot use it with wsmoused at the
console. Do touchpads 

minor build fix in libssl

[YASUOKA Masahiko]

Hi,

Compiling sha256-x86_64.S fails if the "src" is located a directory
which includes "512".

The diff below fixes this problem.

ok?

Index: lib/libssl/src/crypto/sha/asm/sha512-x86_64.pl
===
RCS file: /cvs/src/lib/libssl/src/crypto/sha/asm/sha512-x86_64.pl,v
retrieving revision 1.2
diff -u -p -r1.2 sha512-x86_64.pl
--- lib/libssl/src/crypto/sha/asm/sha512-x86_64.pl  30 Apr 2014 13:40:02 
-  1.2
+++ lib/libssl/src/crypto/sha/asm/sha512-x86_64.pl  17 Dec 2015 02:58:51 
-
@@ -52,7 +52,7 @@ die "can't locate x86_64-xlate.pl";
 open OUT,"| \"$^X\" $xlate $flavour $output";
 *STDOUT=*OUT;
 
-if ($output =~ /512/) {
+if ($output =~ m#.*[\/\\][^\/\\]*512[^\/\\]*$#) {
$func="sha512_block_data_order";
$TABLE="K512";
$SZ=8;

Re: removing expired once rules in pf_purge_thread()

[Martin Pieuchot]

On 16/12/15(Wed) 10:19, Alexandr Nedvedicky wrote:
> On Wed, Dec 16, 2015 at 02:48:49PM +1300, Richard Procter wrote:
> > 
> > On Tue, 15 Dec 2015, Mike Belopuhov wrote:
> > 
> > > >Yet another possibility is to drop 'once' rules as too complex to
> > > >implement for multiprocessor but I have no idea if this is viable.
> > > 
> > > It is.  And I have said that before with an authority of the implementor
> > > of "once" rules: since we don't have any userland applications that
> > > would use this yet, we can ditch them for now and possibly devise a
> > > better approach later.
> >  
> > > Don't make your lives harder than they have to be!
> > 
> > I tend to agree! And I can't see a way to reimplement it for a 
> > multithreaded pf without introducing downsides.

Guys, if none of you can come with a valid reason to keep "once" rules
please kill them.

There's so much work to do to make pf(4) runnable on multiple CPUs in
parallel that bikescheding/turd-polishing bits that are not used are
IMHO not the way to go.

Re: removing expired once rules in pf_purge_thread()

[Mike Belopuhov]

On Wed, Dec 16, 2015 at 02:31 +0100, Alexandr Nedvedicky wrote:
> Hello,
> 
> > It just occurred to me that another possibility would be a match-only
> > rule that matches one but doesn't involve any purging machinery.  Right
> > now we install ftp-proxy rules as having maximum number of states equal
> > to 1, however there's a time window between the moment the state is no
> > longer there, but anchor is not gone yet and it can potentially create
> > more states which is not a problem for an eavesdropper who can sniff
> > the plaintext protocol.
> 
> I'm not sure I'm following you. IMO the expire flag should solve
> that problem. As soon as rule is marked as expired it can not be
> matched by packet any more.
>

Sure.  I'm just saying that we could change the logic and remove
the purging part, while keeping only the "match once".

> I'm attaching yet another version of patch. The list of changes to
> patch sent by Richard is as follows:
> 
>   - atomic operations are gone as we don't need them
> right now. those will be introduced as soon as we will get
> there. pf_test()/pf_test_rule() is still processing a single
> packet at a time.
> 
>   - it's better to use TAILQ_EMPTY() instead of checking link
> members to determine if last rule is being removed from   
> anchor `a`
> 
>   - I've also realized we have to call pf_purge_expired_rules()
> from pf_commit_rules(). We have to make sure expired rules are gone
> from active lists. I think this is the best approach for pf@Puffy
> currently. It will be changed as soon as ruleset locks and
> reference counting for rules will be merged in. I had to also
> reshuffle a consistency lock a bit in pf_purge_thread().
> 
>   - last but not least: silly name got renamed (s/myruleset/ruleset)
> 
> so what do you think? OK?
>

I think it's almost OK, some comments inline.

> regards
> sasha
> 
> -8<8<8<---8<
> Index: pf.c
> ===
> RCS file: /cvs/src/sys/net/pf.c,v
> retrieving revision 1.960
> diff -u -p -r1.960 pf.c
> --- pf.c  6 Dec 2015 10:03:23 -   1.960
> +++ pf.c  16 Dec 2015 00:52:22 -
> @@ -295,6 +295,9 @@ RB_GENERATE(pf_state_tree, pf_state_key,
>  RB_GENERATE(pf_state_tree_id, pf_state,
>  entry_id, pf_state_compare_id);
>  
> +SLIST_HEAD(pf_rule_gcl, pf_rule) pf_rule_gcl =
> + SLIST_HEAD_INITIALIZER(pf_rule_gcl);
> +
>  __inline int
>  pf_addr_compare(struct pf_addr *a, struct pf_addr *b, sa_family_t af)
>  {
> @@ -1137,6 +1140,18 @@ pf_state_export(struct pfsync_state *sp,
>  /* END state table stuff */
>  
>  void
> +pf_purge_expired_rules(void)
> +{
> + struct pf_rule  *r;
> +
> + while ((r = SLIST_FIRST(_rule_gcl)) != NULL) {
> + SLIST_REMOVE(_rule_gcl, r, pf_rule, gcle);
> + KASSERT(r->rule_flag & PFRULE_EXPIRED);
> + pf_purge_rule(r);
> + }
> +}
> +
> +void
>  pf_purge_thread(void *v)
>  {
>   int nloops = 0, s;
> @@ -1154,6 +1169,11 @@ pf_purge_thread(void *v)
>   if (++nloops >= pf_default_rule.timeout[PFTM_INTERVAL]) {
>   pf_purge_expired_fragments();
>   pf_purge_expired_src_nodes(0);
> + if (!SLIST_EMPTY(_rule_gcl)) {
> + rw_enter_write(_consistency_lock);
> + pf_purge_expired_rules();
> + rw_exit_write(_consistency_lock);
> + }
>   nloops = 0;
>   }
>  

Please follow the example of pf_purge_expired_src_nodes and fold
all of this including the rwlocks inside pf_purge_expired_rules.

> @@ -3135,6 +3155,10 @@ pf_test_rule(struct pf_pdesc *pd, struct
>   ruleset = _main_ruleset;
>   r = TAILQ_FIRST(pf_main_ruleset.rules.active.ptr);
>   while (r != NULL) {
> + if (r->rule_flag & PFRULE_EXPIRED) {
> + r = TAILQ_NEXT(r, entries);
> + goto nextrule;
> + }
>   r->evaluations++;
>   PF_TEST_ATTRIB((pfi_kif_match(r->kif, pd->kif) == r->ifnot),
>   r->skip[PF_SKIP_IFP].ptr);
> @@ -3433,8 +3457,15 @@ pf_test_rule(struct pf_pdesc *pd, struct
>   }
>  #endif   /* NPFSYNC > 0 */
>  
> - if (r->rule_flag & PFRULE_ONCE)
> - pf_purge_rule(ruleset, r, aruleset, a);
> + if (r->rule_flag & PFRULE_ONCE) {
> + if ((a != NULL) && TAILQ_EMPTY(a->ruleset->rules.active.ptr)) {
> + a->rule_flag |= PFRULE_EXPIRED;
> + SLIST_INSERT_HEAD(_rule_gcl, a, gcle);
> + }
> +
> + r->rule_flag |= PFRULE_EXPIRED;
> + SLIST_INSERT_HEAD(_rule_gcl, r, gcle);
> + }
>

I like the generalised approach to a/r purging.  I have a few
questions however:

Re: ntpd setting date incorrectly

[Mike Belopuhov]

On Wed, Dec 16, 2015 at 03:53 +, Ian Mcwilliam wrote:
> 
> Disable sensors * in ntpd.conf and time is good again.
> 
> I see this on boot up when things go strange.
> 
> hw.sensors.vmt0.timedelta0=1450237689.498077 secs, OK, Tue Nov 29 18:36:38.371
> 
> I wonder if it's related to this change? Thoughts?
> 

Bah, I've noticed that, but forgot to mention this to mpi@.
Martin, what has prompted you to change the behaviour here?
It's the only spot in that commit that has changed the
mountroot to a startup hook.

> ===
> RCS file: /cvs/src/sys/dev/pv/vmt.c,v
> retrieving revision 1.5
> retrieving revision 1.6
> diff -u -r1.5 -r1.6
> --- src/sys/dev/pv/vmt.c  2015/08/27 19:51:36 1.5
> +++ src/sys/dev/pv/vmt.c  2015/12/11 16:07:01 1.6
> @@ -1,4 +1,4 @@
> -/*   $OpenBSD: vmt.c,v 1.5 2015/08/27 19:51:36 deraadt Exp $ */
> +/*   $OpenBSD: vmt.c,v 1.6 2015/12/11 16:07:01 mpi Exp $ */
>  
>  /*
>   * Copyright (c) 2007 David Crawshaw 
> @@ -365,7 +365,7 @@
>   sensordev_install(>sc_sensordev);
>  
>   timeout_set(>sc_tick, vmt_tick, sc);
> - if (mountroothook_establish(vmt_tick, sc) == NULL)
> + if (startuphook_establish(vmt_tick, sc) == NULL)
>   DPRINTF("%s: unable to establish tick\n", DEVNAME(sc));
>  
>   timeout_set(>sc_tclo_tick, vmt_tclo_tick, sc);
> 
> 
> Ian McWilliam
> 
> 
> From: Ian Mcwilliam
> Sent: Tuesday, 15 December 2015 12:04 PM
> To: tech@openbsd.org
> Subject: ntpd setting date incorrectly
> 
> Not sure what has changed in the last couple of days but apparently I need to 
> get back from the future.
> 
> This is an OpenBSD VM running under VMWare Fusion Professional Version 8.0.2 
> (3164312) Mac OS X 10.11.2
> 
> 
> Dec 14 17:22:44 ianm-openbsd ntpd[13773]: peer 121.0.0.41 now valid
> Dec 14 17:22:46 ianm-openbsd ntpd[13773]: peer 192.189.54.17 now valid
> Dec 14 17:22:49 ianm-openbsd ntpd[13773]: peer 54.252.165.245 now valid
> Dec 14 17:22:49 ianm-openbsd ntpd[13773]: peer 54.252.129.186 now valid
> Dec 14 17:23:44 ianm-openbsd ntpd[19417]: adjusting local clock by 45.252476s
> 
> Machine shutdown
> 
> Machine rebooted next day
> 
> Dec 15 09:26:00 ianm-openbsd ntpd[1991]: ntp engine ready
> 
> time correct until
> 
> Nov 27 07:52:36 ianm-openbsd ntpd[21778]: set local clock to Sun Nov 27 
> 07:52:36 AEDT 2061 (offset 1450131996.187864s)
> Nov 27 07:52:36 ianm-openbsd savecore: no core dump
> Nov 27 07:52:37 ianm-openbsd apmd: battery status: absent. external power 
> status: connected. estimated battery life 0%
> Nov 27 07:53:56 ianm-openbsd ntpd[11805]: adjusting local clock by 
> -1450131950.806132s
> Nov 27 07:55:26 ianm-openbsd ntpd[11805]: adjusting local clock by 
> -1450131950.410569s
> Nov 27 07:56:56 ianm-openbsd ntpd[11805]: adjusting local clock by 
> -1450131949.960758s
> Nov 27 07:58:26 ianm-openbsd ntpd[11805]: adjusting local clock by 
> -1450131949.511029s
> Nov 27 07:59:56 ianm-openbsd ntpd[11805]: adjusting local clock by 
> -1450131949.061268s
> Nov 27 08:01:26 ianm-openbsd ntpd[11805]: adjusting local clock by 
> -1450131948.611426s
> Nov 27 08:02:56 ianm-openbsd ntpd[11805]: adjusting local clock by 
> -1450131948.161660s
> Nov 27 08:04:26 ianm-openbsd ntpd[11805]: adjusting local clock by 
> -1450131947.711849s
> Nov 27 08:05:56 ianm-openbsd ntpd[11805]: adjusting local clock by 
> -1450131947.262024s
> Nov 27 08:07:26 ianm-openbsd ntpd[11805]: adjusting local clock by 
> -1450131946.812191s
> Nov 27 08:07:32 ianm-openbsd dhclient[21622]: DHCPDISCOVER on em0 - interval 1
> Nov 27 08:07:33 ianm-openbsd dhclient[21622]: DHCPDISCOVER on em0 - interval 1
> Nov 27 08:07:33 ianm-openbsd dhclient[21622]: DHCPOFFER from 172.16.28.254 
> (00:50:56:f1:c4:f7)
> Nov 27 08:07:33 ianm-openbsd dhclient[21622]: DHCPREQUEST on em0 to 
> 255.255.255.255
> Nov 27 08:07:33 ianm-openbsd dhclient[21622]: DHCPACK from 172.16.28.254 
> (00:50:56:f1:c4:f7)
> Nov 27 08:07:33 ianm-openbsd dhclient[21622]: bound to 172.16.28.141 -- 
> renewal in 900 seconds.
> Nov 27 08:08:56 ianm-openbsd ntpd[11805]: adjusting local clock by 
> -1450131946.362273s
> 
> manually setting the date/time shows that things appear fine until next 
> reboot.
> 
> Nov 27 08:57:27 ianm-openbsd ntpd[11805]: adjusting local clock by 
> -1450131932.766352s
> Nov 27 08:58:57 ianm-openbsd ntpd[11805]: adjusting local clock by 
> -1450131932.316650s
> Dec 15 10:34:21 ianm-openbsd ntpd[11805]: adjusting local clock by 33.548572s
> Dec 15 10:34:21 ianm-openbsd ntpd[1991]: clock is now synced
> Dec 15 10:35:52 ianm-openbsd ntpd[11805]: adjusting local clock by 33.107247s
> Dec 15 10:35:52 ianm-openbsd ntpd[1991]: clock is now unsynced
> Dec 15 10:37:21 ianm-openbsd ntpd[11805]: adjusting local clock by 32.662256s
> Dec 15 10:38:51 ianm-openbsd ntpd[11805]: adjusting local clock by 32.212314s
> Dec 15 10:40:21 ianm-openbsd ntpd[11805]: adjusting local clock by 

Re: preparing multitouch support - request for tests

[Stefan Sperling]

On Wed, Dec 16, 2015 at 12:55:03PM +, Tati Chevron wrote:
> Sorry to be negative, but I just don't see the perceived value in this.

You wouldn't want to use OpenBSD on a trouchscreen computer if you
had one? Where windows can be moved or resized depending on how many
fingers you use to touch them? I would. I already have a machine
capable of this but even if I wrote a driver for its wacom touchsceen
today I could not pass all possible input events to OpenBSD's input
subsystem.

Looking forward, such devices will probably become the norm in general
purpose computing. So I believe this work is important.

The only downside I see here is that Ulf has been working in too
much isolation, and that it's proabably too late for the result of
his work to go into the tree for the 5.9 release cycle. I hope it
will go into the tree in one form or another during the 6.0 cycle.

And I didn't take time for testing Ulf's changes yet either, to be
honest. Not because I wouldn't want to, but because I've been too
busy with other things.

initial 11n support for iwn (n, not m)

[Stefan Sperling]

This diff adds 11n MCS 0-7 with A-MPDU and A-MSDU Rx to the iwn(4) driver.

It also tweaks replay detection for CCMP encrypted frames, which needed
tweaking for A-MPDU anyway (see comments in code). Even in non-11n modes
this driver was discarding some retransmitted frames for no good reason.

This driver supports a very wide range of hardware so please test this
with as many iwn(4) adapters as possible. If we don't get enough tests
this change may not be able to make the 5.9 release.

Works for me on:
iwn0 at pci3 dev 0 function 0 "Intel Centrino Advanced-N 6200" rev 0x35: msi, 
MIMO 2T2R, MoW

Please post here or let me know in private which hardware you're testing on.
Thanks.

Note that if you'd like to test monitor mode you'll need to apply
this to a -current source tree from today.

Index: if_iwn.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v
retrieving revision 1.148
diff -u -p -r1.148 if_iwn.c
--- if_iwn.c25 Nov 2015 03:09:59 -  1.148
+++ if_iwn.c16 Dec 2015 14:00:22 -
@@ -148,7 +148,7 @@ int iwn_newstate(struct ieee80211com *,
 void   iwn_iter_func(void *, struct ieee80211_node *);
 void   iwn_calib_timeout(void *);
 intiwn_ccmp_decap(struct iwn_softc *, struct mbuf *,
-   struct ieee80211_key *);
+   struct ieee80211_node *);
 void   iwn_rx_phy(struct iwn_softc *, struct iwn_rx_desc *,
struct iwn_rx_data *);
 void   iwn_rx_done(struct iwn_softc *, struct iwn_rx_desc *,
@@ -189,7 +189,7 @@ int iwn5000_add_node(struct iwn_softc *
int);
 intiwn_set_link_quality(struct iwn_softc *,
struct ieee80211_node *);
-intiwn_add_broadcast_node(struct iwn_softc *, int);
+intiwn_add_broadcast_node(struct iwn_softc *, int, int);
 void   iwn_updateedca(struct ieee80211com *);
 void   iwn_set_led(struct iwn_softc *, uint8_t, uint8_t, uint8_t);
 intiwn_set_critical_temp(struct iwn_softc *);
@@ -458,6 +458,15 @@ iwn_attach(struct device *parent, struct
IEEE80211_C_PMGT;   /* power saving supported */
 
 #ifndef IEEE80211_NO_HT
+   /* No optional HT features supported for now, */
+   ic->ic_htcaps = 0;
+   ic->ic_htxcaps = 0;
+   ic->ic_txbfcaps = 0;
+   ic->ic_aselcaps = 0;
+#endif
+
+#ifdef notyet
+#ifndef IEEE80211_NO_HT
if (sc->sc_flags & IWN_FLAG_HAS_11N) {
/* Set HT capabilities. */
ic->ic_htcaps =
@@ -475,6 +484,7 @@ iwn_attach(struct device *parent, struct
ic->ic_htcaps |= IEEE80211_HTCAP_SMPS_DIS;
}
 #endif /* !IEEE80211_NO_HT */
+#endif /* notyet */
 
/* Set supported legacy rates. */
ic->ic_sup_rates[IEEE80211_MODE_11B] = ieee80211_std_rateset_11b;
@@ -487,10 +497,12 @@ iwn_attach(struct device *parent, struct
if (sc->sc_flags & IWN_FLAG_HAS_11N) {
/* Set supported HT rates. */
ic->ic_sup_mcs[0] = 0xff;   /* MCS 0-7 */
+#ifdef notyet
if (sc->nrxchains > 1)
-   ic->ic_sup_mcs[1] = 0xff;   /* MCS 7-15 */
+   ic->ic_sup_mcs[1] = 0xff;   /* MCS 8-15 */
if (sc->nrxchains > 2)
ic->ic_sup_mcs[2] = 0xff;   /* MCS 16-23 */
+#endif
}
 #endif
 
@@ -515,9 +527,11 @@ iwn_attach(struct device *parent, struct
 #ifndef IEEE80211_NO_HT
ic->ic_ampdu_rx_start = iwn_ampdu_rx_start;
ic->ic_ampdu_rx_stop = iwn_ampdu_rx_stop;
+#ifdef notyet
ic->ic_ampdu_tx_start = iwn_ampdu_tx_start;
ic->ic_ampdu_tx_stop = iwn_ampdu_tx_stop;
 #endif
+#endif
 
/* Override 802.11 state transition machine. */
sc->sc_newstate = ic->ic_newstate;
@@ -1635,6 +1649,11 @@ iwn_read_eeprom_channels(struct iwn_soft
/* Save maximum allowed TX power for this channel. */
sc->maxpwr[chan] = channels[i].maxpwr;
 
+#ifndef IEEE80211_NO_HT
+   if (sc->sc_flags & IWN_FLAG_HAS_11N)
+   ic->ic_channels[chan].ic_flags |= IEEE80211_CHAN_HT;
+#endif
+
DPRINTF(("adding chan %d flags=0x%x maxpwr=%d\n",
chan, channels[i].flags, sc->maxpwr[chan]));
}
@@ -1693,13 +1712,18 @@ iwn_newassoc(struct ieee80211com *ic, st
ieee80211_amrr_node_init(>amrr, >amn);
/* Start at lowest available bit-rate, AMRR will raise. */
ni->ni_txrate = 0;
+#ifndef IEEE80211_NO_HT
+   ni->ni_txmcs = 0;
+#endif
 
for (i = 0; i < ni->ni_rates.rs_nrates; i++) {
rate = ni->ni_rates.rs_rates[i] & IEEE80211_RATE_VAL;
/* Map 802.11 rate to HW rate index. */
-   for (ridx = 0; ridx <= IWN_RIDX_MAX; ridx++)
-   if (iwn_rates[ridx].rate == rate)
+   for (ridx = 0; 

Re: ntpd setting date incorrectly

[Martin Pieuchot]

On 16/12/15(Wed) 14:56, Mike Belopuhov wrote:
> On Wed, Dec 16, 2015 at 03:53 +, Ian Mcwilliam wrote:
> > 
> > Disable sensors * in ntpd.conf and time is good again.
> > 
> > I see this on boot up when things go strange.
> > 
> > hw.sensors.vmt0.timedelta0=1450237689.498077 secs, OK, Tue Nov 29 
> > 18:36:38.371
> > 
> > I wonder if it's related to this change? Thoughts?
> > 
> 
> Bah, I've noticed that, but forgot to mention this to mpi@.
> Martin, what has prompted you to change the behaviour here?
> It's the only spot in that commit that has changed the
> mountroot to a startup hook.

Because this driver is using the same function for a hook and a timer,
both taking (void *) pointer.

I don't understand for which reason this driver is using a hook, but
tell me if this works.

Index: dev/pv/vmt.c
===
RCS file: /cvs/src/sys/dev/pv/vmt.c,v
retrieving revision 1.6
diff -u -p -r1.6 vmt.c
--- dev/pv/vmt.c11 Dec 2015 16:07:01 -  1.6
+++ dev/pv/vmt.c16 Dec 2015 14:29:54 -
@@ -208,6 +208,7 @@ void vmt_shutdown(void *);
 voidvmt_update_guest_info(struct vmt_softc *);
 voidvmt_update_guest_uptime(struct vmt_softc *);
 
+voidvmt_tick_hook(struct device *self);
 voidvmt_tick(void *);
 voidvmt_resume(void);
 
@@ -364,9 +365,7 @@ vmt_attach(struct device *parent, struct
sensor_attach(>sc_sensordev, >sc_sensor);
sensordev_install(>sc_sensordev);
 
-   timeout_set(>sc_tick, vmt_tick, sc);
-   if (startuphook_establish(vmt_tick, sc) == NULL)
-   DPRINTF("%s: unable to establish tick\n", DEVNAME(sc));
+   config_mountroot(self, vmt_tick_hook);
 
timeout_set(>sc_tclo_tick, vmt_tclo_tick, sc);
timeout_add_sec(>sc_tclo_tick, 1);
@@ -467,6 +466,15 @@ vmt_update_guest_info(struct vmt_softc *
 
sc->sc_set_guest_os = 1;
}
+}
+
+void
+vmt_tick_hook(struct device *self)
+{
+   struct vmt_softc *sc = (struct vmt_softc *)self;
+
+   timeout_set(>sc_tick, vmt_tick, sc);
+   vmt_tick(sc);
 }
 
 void

Re: __progname in base

[Ted Unangst]

Theo Buehler wrote:
> ping.
> 

ok

> On Tue, Dec 08, 2015 at 07:15:39PM +0100, Theo Buehler wrote:
> > On Sat, Nov 07, 2015 at 12:20:42PM +0100, Tobias Stoeckmann wrote:
> > > Based on Todd's patch for at and cron, I did a grep through our base
> > > tree to see if there are more occurrences of self-made __progname
> > > handling.
> > 
> > A few more of those:
> > 
> > Index: caesar/caesar.c
> > ===
> > RCS file: /var/cvs/src/games/caesar/caesar.c,v
> > retrieving revision 1.17
> > diff -u -p -r1.17 caesar.c
> > --- caesar/caesar.c 14 Oct 2015 08:12:12 -  1.17
> > +++ caesar/caesar.c 8 Dec 2015 17:40:00 -
> > @@ -69,7 +69,8 @@ int
> >  main(int argc, char *argv[])
> >  {
> > int ch, i, nread;
> > -   char *inbuf, *p, **av;
> > +   extern char *__progname;
> > +   char *inbuf;
> > int obs[26], try, winner;
> > double dot, winnerdot;
> >  
> > @@ -77,11 +78,7 @@ main(int argc, char *argv[])
> > err(1, "pledge");
> >  
> > /* check to see if we were called as rot13 */
> > -   av = argv;
> > -   p = strrchr(*av, '/');
> > -   if (p++ == NULL)
> > -   p = *av;
> > -   if (strcmp(p,"rot13") == 0)
> > +   if (strcmp(__progname, "rot13") == 0)
> > printit(13);
> >  
> > if (argc > 1) {
> > Index: hack/hack.end.c
> > ===
> > RCS file: /var/cvs/src/games/hack/hack.end.c,v
> > retrieving revision 1.13
> > diff -u -p -r1.13 hack.end.c
> > --- hack/hack.end.c 24 Oct 2015 18:26:13 -  1.13
> > +++ hack/hack.end.c 8 Dec 2015 17:53:00 -
> > @@ -613,7 +613,7 @@ charcat(char *s, char c)
> >  void
> >  prscore(int argc, char **argv)
> >  {
> > -   extern char *hname;
> > +   extern char *__progname;
> > char **players;
> > int playerct;
> > int rank;
> > @@ -699,7 +699,7 @@ prscore(int argc, char **argv)
> >   if(playerct > 1) printf("any of ");
> >   for(i=0; i > printf("%s%s", players[i], (i > - printf("Call is: %s -s [playernames]\n", hname);
> > + printf("Call is: %s -s [playernames]\n", __progname);
> > }
> > }
> > return;
> > Index: hack/hack.main.c
> > ===
> > RCS file: /var/cvs/src/games/hack/hack.main.c,v
> > retrieving revision 1.18
> > diff -u -p -r1.18 hack.main.c
> > --- hack/hack.main.c4 Nov 2015 21:22:10 -   1.18
> > +++ hack/hack.main.c8 Dec 2015 17:54:14 -
> > @@ -90,7 +90,6 @@ int locknum;  /* max num of 
> > players */
> >  char *catmore; /* default pager */
> >  #endif
> >  char SAVEF[PL_NSIZ + 11] = "save/";/* save/9player */
> > -char *hname;   /* name of the game (argv[0] of call) */
> >  char obuf[BUFSIZ]; /* BUFSIZ is defined in stdio.h */
> >  
> >  extern char *nomovemsg;
> > @@ -103,12 +102,12 @@ static void chdirx(char *, boolean);
> >  int
> >  main(int argc, char **argv)
> >  {
> > +   extern char *__progname;
> > int fd;
> >  #ifdef CHDIR
> > char *dir;
> >  #endif
> >  
> > -   hname = argv[0];
> > hackpid = getpid();
> >  
> >  #ifdef CHDIR   /* otherwise no chdir() */
> > @@ -187,7 +186,7 @@ main(int argc, char **argv)
> >  * Find the creation date of this game,
> >  * so as to avoid restoring outdated savefiles.
> >  */
> > -   gethdate(hname);
> > +   gethdate(__progname);
> >  
> > /*
> >  * We cannot do chdir earlier, otherwise gethdate will fail.
> > Index: hunt/huntd/driver.c
> > ===
> > RCS file: /var/cvs/src/games/hunt/huntd/driver.c,v
> > retrieving revision 1.22
> > diff -u -p -r1.22 driver.c
> > --- hunt/huntd/driver.c 25 Sep 2015 17:50:53 -  1.22
> > +++ hunt/huntd/driver.c 8 Dec 2015 18:07:36 -
> > @@ -52,7 +52,6 @@
> >  #include "conf.h"
> >  #include "server.h"
> >  
> > -char   *First_arg; /* pointer to argv[0] */
> >  u_int16_t Server_port;
> >  intServer_socket;  /* test socket to answer datagrams */
> >  FLAG   should_announce = TRUE; /* true if listening on standard port */
> > @@ -88,6 +87,7 @@ main(ac, av)
> > static FLAG server = FALSE;
> > extern int  optind;
> > extern char *optarg;
> > +   extern char *__progname;
> > int c;
> > static struct timeval   linger = { 0, 0 };
> > static struct timeval   timeout = { 0, 0 }, *to;
> > @@ -97,8 +97,6 @@ main(ac, av)
> > int fd;
> > int background = 0;
> >  
> > -   First_arg = av[0];
> > -
> > config();
> >  
> > while ((c = getopt(ac, av, "bsp:a:D:")) != -1) {
> > @@ -127,7 +125,7 @@ erred:
> > fprintf(stderr,
> > 

Re: preparing multitouch support - request for tests

[Matthieu Herrb]

On Wed, Dec 16, 2015 at 02:32:44AM +0100, Ulf Brosziewski wrote:
> Ping? No further thoughts on this, no tests? Do I have to conclude that
> most people are happy with wsmouse as it is?

Hi,

I'd like to see things move forward, but I currently lack time to do
anything serious on this. 

One thing is not clear to me after looking (quickly) at your patch and
trying it: how does this work integrate with the libinput port ?

From what I understand from libinput, it moves a lot of the code that
maps low-level events to higher-level X events (for multi-touch, but
also for features like 2 fingers scrolling or side scrolling) from the
kernel to libinput itself.  

With libinput, xf86-input-ws should be replaced by xf86-input-libinput
and there is no need to hack on xf86-input-ws anymore. 

I've the impression that here you're adding this code to the kernel.

Please correct me if I'm wrong. 

There is also the fact that I'm conviced that xinput (and libinput)
needs more information about the individual input device than what is
currently exposed through wsconsio. This is probably even more true
for multi-touch devices, since they have such a large set of possible
features..

> 
> I'm aware that the diff isn't small, but anything smaller would make
> some of the remaining parts void and possibly blur the concept. The core
> of the approach is actually quite simple: wsmouse_input() will be
> replaced by a set of functions for reporting state, and by
> wsmouse_input_sync(), which generates the wscons events (please note
> that it doesn't produce MT events yet; there are no userland drivers
> that could use them). Running mice, and tablets and touchpads that can
> only track a single contact wouldn't need much more. MT support needs
> some bits of configuration: the number of touches that might be tracked
> simultaneously, and the information whether a buffer for "MT tracking"
> is required.
> 
> For use with the synaptics driver, MT input from touchpads must be
> converted into a single-touch representation, and this conversion is
> based on a mechanism that selects a "pointer-controlling" slot. The
> implementation generalizes the method currently applied by the
> Elantech-v4 packet handler in pms.
> 
> Single-touch representations are also the base for handling
> "compat-mode" of touchpads in wsmouse. Currently, each hardware driver
> tracks absolute coordinates in its device data, and has a compat-mode
> branch in its packet handler that computes relative coordinates, applies
> a more or less arbitrary scaling to them, and calls wsmouse_input() with
> the "DELTA" flags. This is not only ugly, it would be even more ugly for
> touchpad drivers that use the new MT functions: It would still require a
> driver-internal representation of the input, a driver-internal selection
> of the pointer-controlling touch, etc. That's obviously nonsense, compat
> mode should be handled by wsmouse. However, it requires some
> configuration.
> 
> There is a second point concerning compat mode that I would like to
> change: it could be made useful. Because of the arbitrary scaling and
> the unpredictable pointer movement, I cannot use it with wsmoused at the
> console. Do touchpads exist where it works?  Recently Thierry Deval
> posted a diff here which proved that we could easily do something about
> that, but that is a different story. In my diff, wsmouseinput hooks its
> "touchpad extension" (wstpad) into the compat-mode conversion function,
> which works well with ws for all touchpads that are available to me.
> 
> The internal configuration of wstpad may cause headaches, it seems to be
> easy to make a mess out if it. This is one of the reasons why there are
> no ioctl mechanisms yet for a configuration from userland.
> 
> Up to now, I had less headaches with the input-processing parts of
> wstpad, and I don't believe that a decent driver necessarily looks like
> the synaptics driver, or the touchpad module of libinput. Its tapping
> handler, for example, seems to be built on a somewhat unlucky
> abstraction (I mean the "state machine", where states mirror input
> states and sequences of input states; in wstpad, the "states" of the
> handler correspond the kind of decision that is to be taken next). Of
> course I don't want to suggest that this is children's play; e.g., I
> haven't worked seriously on the palm detection part up to now (I cannot
> do that, because I don't have "real" problems with accidental touches).
> Many things that may sound trivial first may turn out to be intricate
> (e.g., how do you distinguish a two-finger click from a click-and-drag
> action? This might need a timeout. Perhaps Mac users can help here ...)
> 
> 
> On 12/03/2015 12:20 AM, Ulf Brosziewski wrote:
> >The diffs below contain a complete and extensive rewrite of the
> >input-processing parts of wsmouse and the interface it provides to
> >the hardware drivers. It prepares the support for various kinds of
> >multitouch input, as well as an 

Re: initial 11n support for iwn (n, not m)

[David Hill]

Hi Stefan -

Thanks for the 11n work!

Unfortunately, your diff breaks iwn on my machine.

iwn0 at pci2 dev 0 function 0 "Intel Centrino Ultimate-N 6300" rev 0x35:
msi, MIMO 3T3R, MoW, 

It spews over and over:

iwn0: fatal firmware error
firmware error log:
  error type  = "SYSASSERT" (0x0005)
  program counter = 0x00022278
  source line = 0x0218
  error data  = 0x0218000B
  branch link = 0x0002225800022258
  interrupt link  = 0x1532
  time= 2127856977
driver status:
  tx ring  0: qid=0  cur=4   queued=0  
  tx ring  1: qid=1  cur=0   queued=0  
  tx ring  2: qid=2  cur=0   queued=0  
  tx ring  3: qid=3  cur=0   queued=0  
  tx ring  4: qid=4  cur=41  queued=0  
  tx ring  5: qid=5  cur=0   queued=0  
  tx ring  6: qid=6  cur=0   queued=0  
  tx ring  7: qid=7  cur=0   queued=0  
  tx ring  8: qid=8  cur=0   queued=0  
  tx ring  9: qid=9  cur=0   queued=0  
  tx ring 10: qid=10 cur=0   queued=0  
  tx ring 11: qid=11 cur=0   queued=0  
  tx ring 12: qid=12 cur=0   queued=0  
  tx ring 13: qid=13 cur=0   queued=0  
  tx ring 14: qid=14 cur=0   queued=0  
  tx ring 15: qid=15 cur=0   queued=0  
  tx ring 16: qid=16 cur=0   queued=0  
  tx ring 17: qid=17 cur=0   queued=0  
  tx ring 18: qid=18 cur=0   queued=0  
  tx ring 19: qid=19 cur=0   queued=0  
  rx ring: cur=14
  802.11 state 4

Re: UTF-8 support for fmt(1)

[Ingo Schwarze]

Hi,

Ingo Schwarze wrote on Tue, Dec 08, 2015 at 10:37:29PM +0100:

> here is UTF-8 support for fmt(1).
> This does not include the -c case; the patch is already large enough.

Meanwhile, i committed that.
Here is a simple solution for the -c case.
The loop in center_stream() is designed to be similar
to the loop in process_stream(), but it's a bit simpler.

This patch implies two changes in behaviour, though.

First, i don't see why fmt -c should pass through invalid bytes,
given that fmt without -c weeds them out.  So handle them the same
way in both cases, replace them with ASCII question marks.

Then, the concept of tabs inside lines that are to be centered makes
no sense in the first place.  In the past, the width of such a tab
depended on the leading whitespace on the line, even though that
whitespace was otherwise ignored.  Yet, tabs on subsequent lines
did not align because the leading space on output depends on the
width of the string following the tab.  None of that was useful.

I see no way to define the meaning of a tab in a line that is to
be centered in a more useful way.  If we want tabs on subsequent
centered lines to align, the *number* of tabs needed will depend
on the width of the string *following* the last tab.  That is
completely intransparent to people writing such files, and i see
no way to prepare such files correctly without experimentation.
Even then, the output positioning of the text preceding the tab
remains ill-defined.

So, i propose that in lines to be centered, we just replace each
tab with one single blank.  That is easy to understand, easy to
implement, and not less useful than any other solution i can think
of.

OK?
  Ingo


Index: fmt.c
===
RCS file: /cvs/src/usr.bin/fmt/fmt.c,v
retrieving revision 1.34
diff -u -p -r1.34 fmt.c
--- fmt.c   15 Dec 2015 16:26:17 -  1.34
+++ fmt.c   16 Dec 2015 10:37:27 -
@@ -620,13 +620,29 @@ output_word(size_t indent0, size_t inden
 static void
 center_stream(FILE *stream, const char *name)
 {
-   char *line;
-   size_t l;
+   char *line, *cp;
+   wchar_t wc;
+   size_t l;   /* Display width of the line. */
+   int wcw;/* Display width of one character. */
+   int wcl;/* Length in bytes of one character. */
 
while ((line = get_line(stream)) != NULL) {
-   while (isspace((unsigned char)*line))
-   ++line;
-   l = strlen(line);
+   l = 0;
+   for (cp = line; *cp != '\0'; cp += wcl) {
+   if (*cp == '\t')
+   *cp = ' ';
+   if ((wcl = mbtowc(, cp, MB_CUR_MAX)) == -1) {
+   (void)mbtowc(NULL, NULL, MB_CUR_MAX);
+   *cp = '?';
+   wcl = 1;
+   wcw = 1;
+   } else if ((wcw = wcwidth(wc)) == -1)
+   wcw = 1;
+   if (l == 0 && iswspace(wc))
+   line += wcl;
+   else
+   l += wcw;
+   }
while (l < goal_length) {
putchar(' ');
l += 2;

Re: initial 11n support for iwn (n, not m)

[Stefan Sperling]

On Wed, Dec 16, 2015 at 10:14:49AM -0500, David Hill wrote:
> Hi Stefan -
> 
> Thanks for the 11n work!
> 
> Unfortunately, your diff breaks iwn on my machine.
> 
> iwn0 at pci2 dev 0 function 0 "Intel Centrino Ultimate-N 6300" rev 0x35:
> msi, MIMO 3T3R, MoW, 
> 
> It spews over and over:
> 
> iwn0: fatal firmware error
> firmware error log:
>   error type  = "SYSASSERT" (0x0005)
>   program counter = 0x00022278
>   source line = 0x0218
>   error data  = 0x0218000B
>   branch link = 0x0002225800022258
>   interrupt link  = 0x1532
>   time= 2127856977
> driver status:
>   tx ring  0: qid=0  cur=4   queued=0  
>   tx ring  1: qid=1  cur=0   queued=0  
>   tx ring  2: qid=2  cur=0   queued=0  
>   tx ring  3: qid=3  cur=0   queued=0  
>   tx ring  4: qid=4  cur=41  queued=0  
>   tx ring  5: qid=5  cur=0   queued=0  
>   tx ring  6: qid=6  cur=0   queued=0  
>   tx ring  7: qid=7  cur=0   queued=0  
>   tx ring  8: qid=8  cur=0   queued=0  
>   tx ring  9: qid=9  cur=0   queued=0  
>   tx ring 10: qid=10 cur=0   queued=0  
>   tx ring 11: qid=11 cur=0   queued=0  
>   tx ring 12: qid=12 cur=0   queued=0  
>   tx ring 13: qid=13 cur=0   queued=0  
>   tx ring 14: qid=14 cur=0   queued=0  
>   tx ring 15: qid=15 cur=0   queued=0  
>   tx ring 16: qid=16 cur=0   queued=0  
>   tx ring 17: qid=17 cur=0   queued=0  
>   tx ring 18: qid=18 cur=0   queued=0  
>   tx ring 19: qid=19 cur=0   queued=0  
>   rx ring: cur=14
>   802.11 state 4
> 

Thanks for testing!

I cannot do much based on the information provided.
Could you recompile with IWM_DEBUG defined, and perhaps place a few
additional printfs at strategic locations, to figure out which
firmware command is last sent before the firmware crashes?
That would help me a great deal.

If you don't want the firmware to be restarted over and over so it
won't print these lines repeatedly, disabling the init_task which
attempts to recover from firmware crashes might help:

if (r1 & (IWN_INT_SW_ERR | IWN_INT_HW_ERR)) {
printf("%s: fatal firmware error\n", sc->sc_dev.dv_xname);
/* Dump firmware error log and stop. */
iwn_fatal_intr(sc);
iwn_stop(ifp, 1);
task_add(systq, >init_task); <-- remove this line
return 1;
}

Re: initial 11n support for iwn (n, not m)

[Gregor Best]

Hi Stefan,

On Wed, Dec 16, 2015 at 03:35:22PM +0100, Stefan Sperling wrote:
> This diff  adds 11n MCS  0-7 with A-MPDU and  A-MSDU Rx to  the iwn(4)
> driver.
> [...]

Whoo! Thanks a lot for your hard work :)

> [...]
> Please post  here or  let me  know in  private which  hardware you're.
> testing on Thanks.
> [...]

Works for me on:

iwn0 at pci2 dev 0 function 0 "Intel WiFi Link 5100" rev 0x00: msi, MIMO 1T2R, 
MoW, address 00:22:fa:d0:2f:a0

I have done some speed testing,  but with inconclusive results. I used a
Macbook Pro with  OS X as the  other side, testing was  done with iperf,
both machines connected to the same WiFi:

$ iperf -i 2 -c 192.168.178.54

Client connecting to 192.168.178.54, TCP port 5001
TCP window size: 17.0 KByte (default)

[  3] local 192.168.178.49 port 30131 connected with 192.168.178.54 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0- 2.0 sec   768 KBytes  3.15 Mbits/sec
[  3]  2.0- 4.0 sec   640 KBytes  2.62 Mbits/sec
[  3]  4.0- 6.0 sec   640 KBytes  2.62 Mbits/sec
[  3]  6.0- 8.0 sec   512 KBytes  2.10 Mbits/sec
[  3]  8.0-10.0 sec   640 KBytes  2.62 Mbits/sec
[  3]  0.0-10.3 sec  3.25 MBytes  2.64 Mbits/sec

I assume the low  bandwidth is due to the two  thick walls separating my
laptops and the  access point. Everything else seems to  be fine though.
I'll  retry the  speed  measurement in  a  few days  when  I'm home  for
christmas.

> Note that if you'd like to test monitor mode you'll need to apply this
> to a -current source tree from today.
> [...]

Haven't  tested monitor  mode so  far, except  for the  IFF_PROMISC that
comes with the device being a trunkport. Works fine as far as I can see.

-- 
Gregor
--

BLISS is ignorance.

Re: preparing multitouch support - request for tests

[Stefan Sperling]

On Wed, Dec 16, 2015 at 04:11:21PM +, Tati Chevron wrote:
> >So I believe this work is important.
> 
> I think it's much more important to look at the impact on existing use cases,
> before making changes and introducing a lot of new code that the end user
> can't easily disable, and potentially affects such basic things as a mouse.
 
Your use case is as much important to me as it is to you.
I also prefer keyboards for development and will still be using
mice and touchpads.

I'd like to run OpenBSD on a tablet to *use a tablet*.
And I don't want to use a tablet running an OS I don't trust.

Re: removing expired once rules in pf_purge_thread()

[Alexandr Nedvedicky]

hello,


> > > It just occurred to me that another possibility would be a match-only
> > > rule that matches one but doesn't involve any purging machinery.  Right
> > > now we install ftp-proxy rules as having maximum number of states equal
> > > to 1, however there's a time window between the moment the state is no
> > > longer there, but anchor is not gone yet and it can potentially create
> > > more states which is not a problem for an eavesdropper who can sniff
> > > the plaintext protocol.
> > 
> > I'm not sure I'm following you. IMO the expire flag should solve
> > that problem. As soon as rule is marked as expired it can not be
> > matched by packet any more.
> >
> 
> Sure.  I'm just saying that we could change the logic and remove
> the purging part, while keeping only the "match once".
> 
that might be other possibility. However I would give a try to
garbage collection.

> 
> Please follow the example of pf_purge_expired_src_nodes and fold
> all of this including the rwlocks inside pf_purge_expired_rules.
> 

fixed

> 
> I like the generalised approach to a/r purging.  I have a few
> questions however:
> 
> Since you're not removing the rule from the ruleset at this point
> what does "pfctl -sr" display in this case? 

new version of the patch makes pfctl -sr aware of PFRULE_EXPIRED
flag. The expired rule will be shown in verbose mode only.

> What happens if you
> list the anchor?  And what should the user see?
> 
> Should we omit exporting those rules into userland via ioctl?

I think we should export those rules to userland and let userland
to interpret what it gets from kernel. Changing DIOCGETRULE might
not be that easy.

> 
> What happens with pfsync in this case?

I keep forgetting about pfsync...

After looking at current pf_purge_rule() implementation in CVS it
seems to me it just does not care about pfsync at all.

The patch I'd like to commit keeps things same with respect to pfsync.

from my very limited understanding of pfsync, only main rulesets are synced up
between nodes. When pf_rules_commit() loads new rules to active list it calls
pf_setup_pfsync_matching(). the function calculates a checksum on ruleset.
It's still not clear to me how/when (if ever) are rules synced up.

thanks and
regards
sasha
 
8<---8<---8<--8<

Index: sys/net/pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.960
diff -u -p -r1.960 pf.c
--- sys/net/pf.c6 Dec 2015 10:03:23 -   1.960
+++ sys/net/pf.c16 Dec 2015 16:28:28 -
@@ -295,6 +295,9 @@ RB_GENERATE(pf_state_tree, pf_state_key,
 RB_GENERATE(pf_state_tree_id, pf_state,
 entry_id, pf_state_compare_id);
 
+SLIST_HEAD(pf_rule_gcl, pf_rule)   pf_rule_gcl =
+   SLIST_HEAD_INITIALIZER(pf_rule_gcl);
+
 __inline int
 pf_addr_compare(struct pf_addr *a, struct pf_addr *b, sa_family_t af)
 {
@@ -1137,6 +1140,27 @@ pf_state_export(struct pfsync_state *sp,
 /* END state table stuff */
 
 void
+pf_purge_expired_rules(int locked)
+{
+   struct pf_rule  *r;
+
+   if (SLIST_EMPTY(_rule_gcl))
+   return;
+
+   if (!locked)
+   rw_enter_write(_consistency_lock);
+
+   while ((r = SLIST_FIRST(_rule_gcl)) != NULL) {
+   SLIST_REMOVE(_rule_gcl, r, pf_rule, gcle);
+   KASSERT(r->rule_flag & PFRULE_EXPIRED);
+   pf_purge_rule(r);
+   }
+
+   if (!locked)
+   rw_exit_write(_consistency_lock);
+}
+
+void
 pf_purge_thread(void *v)
 {
int nloops = 0, s;
@@ -1154,6 +1178,7 @@ pf_purge_thread(void *v)
if (++nloops >= pf_default_rule.timeout[PFTM_INTERVAL]) {
pf_purge_expired_fragments();
pf_purge_expired_src_nodes(0);
+   pf_purge_expired_rules(0);
nloops = 0;
}
 
@@ -3135,6 +3160,10 @@ pf_test_rule(struct pf_pdesc *pd, struct
ruleset = _main_ruleset;
r = TAILQ_FIRST(pf_main_ruleset.rules.active.ptr);
while (r != NULL) {
+   if (r->rule_flag & PFRULE_EXPIRED) {
+   r = TAILQ_NEXT(r, entries);
+   goto nextrule;
+   }
r->evaluations++;
PF_TEST_ATTRIB((pfi_kif_match(r->kif, pd->kif) == r->ifnot),
r->skip[PF_SKIP_IFP].ptr);
@@ -3433,8 +3462,15 @@ pf_test_rule(struct pf_pdesc *pd, struct
}
 #endif /* NPFSYNC > 0 */
 
-   if (r->rule_flag & PFRULE_ONCE)
-   pf_purge_rule(ruleset, r, aruleset, a);
+   if (r->rule_flag & PFRULE_ONCE) {
+   if ((a != NULL) && TAILQ_EMPTY(a->ruleset->rules.active.ptr)) {
+   a->rule_flag |= PFRULE_EXPIRED;
+   SLIST_INSERT_HEAD(_rule_gcl, a, gcle);
+   }
+
+   r->rule_flag |= PFRULE_EXPIRED;
+   

Re: initial 11n support for iwn (n, not m)

[Christian Weisgerber]

On 2015-12-16, David Hill  wrote:

> Thanks for the 11n work!
> Unfortunately, your diff breaks iwn on my machine.
>
> iwn0 at pci2 dev 0 function 0 "Intel Centrino Ultimate-N 6300" rev 0x35:
> msi, MIMO 3T3R, MoW, 

That is odd, because it works for me:

iwn0 at pci2 dev 0 function 0 "Intel Centrino Ultimate-N 6300" rev 0x3e:
msi, MIMO 3T3R, MoW,

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

pledge: document "dpath" promise

[Sebastien Marie]

Hi,

It seems the "dpath" promise isn't documented in pledge(2) man page.

Technically, with "dpath" you have only access to mkfifo(2) and mknod(2)
system calls. No more promises are need for create the files.

If you request a mode with setuid/setgid/sticky bits, there are ignored.
It is already documented in "Some system calls have restrictions applied
to them" list.

I dunno if "special files" is the right expression for saying "FIFO file" and
"special file node" (if I take words from man pages of mkfifo(2) and
mknod(2)).

Comments ? OK ?
-- 
Sebastien Marie

Index: lib/libc/sys/pledge.2
===
RCS file: /cvs/src/lib/libc/sys/pledge.2,v
retrieving revision 1.20
diff -u -p -r1.20 pledge.2
--- lib/libc/sys/pledge.2   16 Dec 2015 08:27:32 -  1.20
+++ lib/libc/sys/pledge.2   16 Dec 2015 08:59:13 -
@@ -254,6 +254,12 @@ create new files or directories in the f
 .Xr unlinkat 2 ,
 .Xr mkdir 2 ,
 .Xr mkdirat 2 .
+.It Va "dpath"
+A number of system calls are allowed and may cause
+special file creation on the filesystem:
+.Pp
+.Xr mkfifo 2 ,
+.Xr mknod 2 .
 .It Va "tmppath"
 A number of system calls are allowed to do operations in the
 .Pa /tmp

Re: removing expired once rules in pf_purge_thread()

[Alexandr Nedvedicky]

Hello,


On Wed, Dec 16, 2015 at 02:48:49PM +1300, Richard Procter wrote:
> 
> On Tue, 15 Dec 2015, Mike Belopuhov wrote:
> 
> > >Yet another possibility is to drop 'once' rules as too complex to
> > >implement for multiprocessor but I have no idea if this is viable.
> > 
> > It is.  And I have said that before with an authority of the implementor
> > of "once" rules: since we don't have any userland applications that
> > would use this yet, we can ditch them for now and possibly devise a
> > better approach later.
>  
> > Don't make your lives harder than they have to be!
> 
> I tend to agree! And I can't see a way to reimplement it for a 
> multithreaded pf without introducing downsides.
> 
> Quoting pf.conf(5) "once - Creates a one shot rule that will remove itself 
> from an active ruleset after the first match."
> 
> A 'first' match presupposes a total ordering. This comes for free when pf 
> is single-threaded but concurrent rule matching must take the trouble to 
> re-impose it somewhere. (I assume that pf aims to do concurrent matching 
> of packets against the ruleset.)

pf@solaris allows the race here. The price for correct behavior, which is to
allow one and only one packet to hit the rule is too high (given the once rules
are kind of special case). What has to be granted is there is one 'winner'
only, which puts the rule to garbage collector list. The pragmatic approach
wins here.

regards
sasha

Re: ksh: variable substitution in double quoted string

[Pablo Méndez Hernández]

Hi,

On Wed, Dec 16, 2015 at 8:22 AM, Dmitrij D. Czarkoff  wrote:
> Hi!
>
> I recently came across a shell script that uses idiom
>
>   var1=var1
>   var2=var2
>   echo "${var1+($var2)}"
>
> ksh(1) doesn't like it:
>
>   ksh: ${var1+($var2)}": bad substitution
>
> Meanwhile bash and dash just print:
>
>   (var2)

FWIW, both "regular" ksh and ksh93 in Solaris 11.2 behave the same way
as bash and dash.

> Apparently ksh tries to parse parenthesis within substituted word.
> According to 2.2.3 Double-Quotes[1] of POSIX Shell Command Language,
> parentheses should not be parsed within double quotes, although 2.6.2
> Parameter Expansion[2] sets special rules for parameter substitution
> within double quotes, and those don't mention whether substituted word
> should be considered quoted or not.
>
> Patch below changes ksh's behavior to match that of bash and dash.  I am
> not decided on the matter.
>
> --
> Dmitrij D. Czarkoff
>
> [1] 
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02
> [2] 
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02
>
> Index: lex.c
> ===
> RCS file: /cvs/src/bin/ksh/lex.c,v
> retrieving revision 1.64
> diff -u -p -r1.64 lex.c
> --- lex.c   18 Nov 2015 15:31:21 -  1.64
> +++ lex.c   16 Dec 2015 07:05:42 -
> @@ -579,6 +579,15 @@ yylex(int cf)
> break;
>
> case SBRACEQ:
> +   /*{*/
> +   if (c == '}') {
> +   POP_STATE();
> +   *wp++ = CSUBST;
> +   *wp++ = /*{*/ '}';
> +   } else
> +   goto Subst;
> +   break;
> +
> case SBRACE:
> /*{*/
> if (c == '}') {
>


Regards.

-- 

Pablo Méndez Hernández