Re: kern_sched.c: unused functions

[Michael McConville]

Michal Mazurek wrote:
> On 17:19:39,  2.03.16, Martin Natano wrote:
> > On Wed, Mar 02, 2016 at 05:07:21PM +0100, Michal Mazurek wrote:
> > > kern_sched.c:
> > > - remove unused functions
> > > - mark static functions as static
> > 
> > Functions shouldn't be static in the kernel. "In userland,
> > functions local to one source module should be declared ???static???.  This
> > should not be done in kernel land since it makes it impossible to use the
> > kernel debugger." -- style(8)
> 
> Oh, right.
> 
> Remove cpuset_clear(), cpuset_add_all() and cpuset_union(), and move
> some declarations from proc.h to kern_sched.c.

ok mmcc@, pending an ok from someone who works with this code.

> Index: sys/kern/kern_sched.c
> ===
> RCS file: /cvs/src/sys/kern/kern_sched.c,v
> retrieving revision 1.41
> diff -u -p -r1.41 kern_sched.c
> --- sys/kern/kern_sched.c 23 Dec 2015 14:51:17 -  1.41
> +++ sys/kern/kern_sched.c 2 Mar 2016 16:37:18 -
> @@ -28,11 +28,18 @@
>  
>  #include 
>  
> -void sched_kthreads_create(void *);
> -
> -int sched_proc_to_cpu_cost(struct cpu_info *ci, struct proc *p);
> +void  sched_kthreads_create(void *);
> +int   sched_proc_to_cpu_cost(struct cpu_info *ci, struct proc *p);
>  struct proc *sched_steal_proc(struct cpu_info *);
>  
> +void  cpuset_complement(struct cpuset *, struct cpuset *, struct cpuset *);
> +void  cpuset_copy(struct cpuset *, struct cpuset *);
> +struct cpu_info *cpuset_first(struct cpuset *);
> +void  cpuset_del(struct cpuset *, struct cpu_info *);
> +void  cpuset_init_cpu(struct cpu_info *);
> +void  cpuset_intersection(struct cpuset *t, struct cpuset *,
> + struct cpuset *);
> +
>  /*
>   * To help choosing which cpu should run which process we keep track
>   * of cpus which are currently idle and which cpus have processes
> @@ -717,12 +724,6 @@ cpuset_init_cpu(struct cpu_info *ci)
>  }
>  
>  void
> -cpuset_clear(struct cpuset *cs)
> -{
> - memset(cs, 0, sizeof(*cs));
> -}
> -
> -void
>  cpuset_add(struct cpuset *cs, struct cpu_info *ci)
>  {
>   unsigned int num = CPU_INFO_UNIT(ci);
> @@ -744,12 +745,6 @@ cpuset_isset(struct cpuset *cs, struct c
>  }
>  
>  void
> -cpuset_add_all(struct cpuset *cs)
> -{
> - cpuset_copy(cs, _all);
> -}
> -
> -void
>  cpuset_copy(struct cpuset *to, struct cpuset *from)
>  {
>   memcpy(to, from, sizeof(*to));
> @@ -765,15 +760,6 @@ cpuset_first(struct cpuset *cs)
>   return (cpuset_infos[i * 32 + ffs(cs->cs_set[i]) - 1]);
>  
>   return (NULL);
> -}
> -
> -void
> -cpuset_union(struct cpuset *to, struct cpuset *a, struct cpuset *b)
> -{
> - int i;
> -
> - for (i = 0; i < CPUSET_ASIZE(ncpus); i++)
> - to->cs_set[i] = a->cs_set[i] | b->cs_set[i];
>  }
>  
>  void
> Index: sys/sys/proc.h
> ===
> RCS file: /cvs/src/sys/sys/proc.h,v
> retrieving revision 1.213
> diff -u -p -r1.213 proc.h
> --- sys/sys/proc.h6 Dec 2015 17:50:21 -   1.213
> +++ sys/sys/proc.h2 Mar 2016 15:56:33 -
> @@ -205,9 +205,9 @@ struct process {
>  
>   struct uprof {  /* profile arguments */
>   caddr_t pr_base;/* buffer base */
> - size_t  pr_size;/* buffer size */
> + size_t  pr_size;/* buffer size */
>   u_long  pr_off; /* pc offset */
> - u_int   pr_scale;   /* pc scaling */
> + u_int   pr_scale;   /* pc scaling */
>   } ps_prof;
>  
>   u_short ps_acflag;  /* Accounting flags. */
> @@ -215,8 +215,8 @@ struct process {
>   uint64_t ps_pledge;
>   struct whitepaths *ps_pledgepaths;
>  
> - int64_t ps_kbind_cookie;
> - u_long  ps_kbind_addr;
> + int64_t ps_kbind_cookie;
> + u_long  ps_kbind_addr;
>  
>  /* End area that is copied on creation. */
>  #define ps_endcopy   ps_refcnt
> @@ -255,7 +255,7 @@ struct process {
>  #define  PS_EMBRYO   0x0002  /* New process, not yet fledged 
> */
>  #define  PS_ZOMBIE   0x0004  /* Dead and ready to be waited 
> for */
>  #define  PS_NOBROADCASTKILL 0x0008   /* Process excluded from kill 
> -1. */
> -#define PS_PLEDGE0x0010  /* Has called pledge(2) */
> +#define  PS_PLEDGE   0x0010  /* Has called pledge(2) */
>  
>  #define  PS_BITS \
>  ("\20" "\01CONTROLT" "\02EXEC" "\03INEXEC" "\04EXITING" "\05SUGID" \
> @@ -380,12 +380,12 @@ struct proc {
>  #define  P_WEXIT 0x2000  /* Working on exiting. */
>  #define  P_OWEUPC0x8000  /* Owe proc an addupc() at next 
> ast. */
>  #define  P_SUSPSINGLE0x0008  /* Need to stop for single 
> threading. */
> -#define P_SYSTRACE   0x0040  /* Process system call tracing active*/
> -#define P_CONTINUED  0x0080  /* Proc has continued from a stopped 
> 

Re: Update `ticks' in the right place

[Mike Belopuhov]

On Wed, Mar 16, 2016 at 14:42 +0900, Masao Uebayashi wrote:
> This doesn't use atomic operation, because:
> 
> - hardclock() is the only writer
>   - Clock interrupt doesn't run simultaneously
> - Reading int should be atomic on all architectures
>

Well, in reality both the new location and timeout_hardclock_update
are only executed by the primary CPU so there's no concurrent
modification happening with or without your diff.

FWIW, I'm fine with moving it into the kern_clock.c.  I assume that
this will make even more sense with some upcoming diffs.

> On Wed, Mar 16, 2016 at 02:13:13PM +0900, Masao Uebayashi wrote:
> > This clarifies that the single, global `ticks' is owned by kern_clock.c.
> > timeout(9) is only one of users of `ticks', even though its handler,
> > timeout_hardclock_update(), is called from hardclock() after update of
> > `ticks' every time.
> > 
> > Theoretically timecounter(9)'s tick, tc_ticktock(), is independent of
> > the value of `ticks'.  Then it must be safe to update `ticks' first then
> > tick timecounter(9).  I leave this order as is for now.
> > 
> > Index: sys/kern/kern_clock.c
> > ===
> > RCS file: /cvs/src/sys/kern/kern_clock.c,v
> > retrieving revision 1.88
> > diff -u -p -r1.88 kern_clock.c
> > --- sys/kern/kern_clock.c   11 Jun 2015 16:03:04 -  1.88
> > +++ sys/kern/kern_clock.c   16 Mar 2016 04:30:42 -
> > @@ -191,6 +191,7 @@ hardclock(struct clockframe *frame)
> > return;
> >  
> > tc_ticktock();
> > +   ticks++;
> >  
> > /*
> >  * Update real-time timeout queue.
> > Index: sys/kern/kern_timeout.c
> > ===
> > RCS file: /cvs/src/sys/kern/kern_timeout.c,v
> > retrieving revision 1.43
> > diff -u -p -r1.43 kern_timeout.c
> > --- sys/kern/kern_timeout.c 20 Jul 2015 23:47:20 -  1.43
> > +++ sys/kern/kern_timeout.c 16 Mar 2016 04:30:42 -
> > @@ -304,8 +304,6 @@ timeout_hardclock_update(void)
> >  
> > mtx_enter(_mutex);
> >  
> > -   ticks++;
> > -
> > MOVEBUCKET(0, ticks);
> > if (MASKWHEEL(0, ticks) == 0) {
> > MOVEBUCKET(1, ticks);
> 

stty header cleanup

[Edgar Pettijohn]

Index: cchar.c
===
RCS file: /cvs/src/bin/stty/cchar.c,v
retrieving revision 1.11
diff -u -p -u -r1.11 cchar.c
--- cchar.c27 Oct 2009 23:59:22 -1.11
+++ cchar.c16 Mar 2016 23:53:58 -
@@ -30,6 +30,7 @@
  * SUCH DAMAGE.
  */

+#include 
 #include 

 #include 
@@ -37,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "stty.h"
 #include "extern.h"
Index: gfmt.c
===
RCS file: /cvs/src/bin/stty/gfmt.c,v
retrieving revision 1.8
diff -u -p -u -r1.8 gfmt.c
--- gfmt.c28 Oct 2009 07:12:59 -1.8
+++ gfmt.c16 Mar 2016 23:54:29 -
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "stty.h"
 #include "extern.h"
Index: key.c
===
RCS file: /cvs/src/bin/stty/key.c,v
retrieving revision 1.16
diff -u -p -u -r1.16 key.c
--- key.c20 Nov 2015 15:57:39 -1.16
+++ key.c16 Mar 2016 23:55:51 -
@@ -30,14 +30,16 @@
  * SUCH DAMAGE.
  */

+#include 
 #include 

 #include 
 #include 
-#include 
 #include 
 #include 
+#include 
 #include 
+#include 

 #include "stty.h"
 #include "extern.h"
Index: modes.c
===
RCS file: /cvs/src/bin/stty/modes.c,v
retrieving revision 1.10
diff -u -p -u -r1.10 modes.c
--- modes.c27 Oct 2009 23:59:22 -1.10
+++ modes.c16 Mar 2016 23:56:40 -
@@ -31,8 +31,11 @@
  */

 #include 
+
 #include 
 #include 
+#include 
+
 #include "stty.h"
 #include "extern.h"

Index: print.c
===
RCS file: /cvs/src/bin/stty/print.c,v
retrieving revision 1.13
diff -u -p -u -r1.13 print.c
--- print.c27 Oct 2009 23:59:22 -1.13
+++ print.c16 Mar 2016 23:57:24 -
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "stty.h"
 #include "extern.h"
Index: stty.c
===
RCS file: /cvs/src/bin/stty/stty.c,v
retrieving revision 1.18
diff -u -p -u -r1.18 stty.c
--- stty.c20 Nov 2015 15:58:28 -1.18
+++ stty.c16 Mar 2016 23:58:14 -
@@ -30,16 +30,18 @@
  * SUCH DAMAGE.
  */

+#include 
 #include 

 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
-#include 
 #include 
+#include 
 #include 

 #include "stty.h"
Index: stty.h
===
RCS file: /cvs/src/bin/stty/stty.h,v
retrieving revision 1.4
diff -u -p -u -r1.4 stty.h
--- stty.h2 Jun 2003 23:32:09 -1.4
+++ stty.h16 Mar 2016 23:52:41 -
@@ -32,9 +32,6 @@
  *@(#)stty.h8.1 (Berkeley) 5/31/93
  */

-#include 
-#include 
-
 struct info {
 int fd;/* file descriptor */
 int ldisc;/* line discipline */

A patch for allowing IPv6-only or IPv4-only bridges

[Momtchil Momtchev]

Hello there,

Here is my patch that adds support for creating IPv6-only or 
IPv4-only bridges. This is different from simply blocking one of the 
protocols via PF - it allows you to create a setup where IPv4 is routed 
and IPv6 is bridged (or vice versa). Both of them being filtered by the 
same set of PF rules. It adds two new bridge port options to ifconfig - 
BLOCKIPV4 and BLOCKIPV6. BLOCKIPV4 also stops ARPs requests from 
"leaking" across the bridge - something I couldn't accomplish by PF alone.
The patch breaks the binary compatibility of ifconfig - it must be 
rebuilt with the new kernel.
I don't know if anyone will find any use for it. For sure it is 
very useful with the second-biggest FTTH/ADSL operator in France who 
offers consumer-grade IPv6 access with an indivisible /64 network that 
must be bridged for firewalling (and a single IPv4/32 address that must 
be NATted).

Patch is against -current, any comments are welcome.


Index: sbin/ifconfig/brconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/brconfig.c,v
retrieving revision 1.9
diff -u -p -u -r1.9 brconfig.c
--- sbin/ifconfig/brconfig.c18 Jul 2015 06:50:24 -1.9
+++ sbin/ifconfig/brconfig.c16 Mar 2016 19:37:44 -
@@ -59,7 +59,7 @@ void bridge_showrule(struct ifbrlreq *);

 #defineIFBAFBITS"\020\1STATIC"
 #defineIFBIFBITS\
-"\020\1LEARNING\2DISCOVER\3BLOCKNONIP\4STP\5EDGE\6AUTOEDGE\7PTP\10AUTOPTP\11SPAN"
+"\020\1LEARNING\2DISCOVER\3BLOCKNONIP\4STP\5EDGE\6AUTOEDGE\7PTP\10AUTOPTP\11BLOCKIPV4\12BLOCKIPV6\15SPAN"

 #definePV2ID(pv, epri, eaddr)do {\
 epri = pv >> 48;\
@@ -93,102 +93,28 @@ char *stproles[] = {
 };


-void
-setdiscover(const char *val, int d)
-{
-bridge_ifsetflag(val, IFBIF_DISCOVER);
-}
-
-void
-unsetdiscover(const char *val, int d)
-{
-bridge_ifclrflag(val, IFBIF_DISCOVER);
-}
-
-void
-setblocknonip(const char *val, int d)
-{
-bridge_ifsetflag(val, IFBIF_BLOCKNONIP);
-}
-
-void
-unsetblocknonip(const char *val, int d)
-{
-bridge_ifclrflag(val, IFBIF_BLOCKNONIP);
-}
-
-void
-setlearn(const char *val, int d)
-{
-bridge_ifsetflag(val, IFBIF_LEARNING);
-}
-
-void
-unsetlearn(const char *val, int d)
-{
-bridge_ifclrflag(val, IFBIF_LEARNING);
-}
-
-void
-setstp(const char *val, int d)
-{
-bridge_ifsetflag(val, IFBIF_STP);
-}
-
-void
-unsetstp(const char *val, int d)
-{
-bridge_ifclrflag(val, IFBIF_STP);
-}
-
-void
-setedge(const char *val, int d)
-{
-bridge_ifsetflag(val, IFBIF_BSTP_EDGE);
-}
-
-void
-unsetedge(const char *val, int d)
-{
-bridge_ifclrflag(val, IFBIF_BSTP_EDGE);
-}
-
-void
-setautoedge(const char *val, int d)
-{
-bridge_ifsetflag(val, IFBIF_BSTP_AUTOEDGE);
-}
-
-void
-unsetautoedge(const char *val, int d)
-{
-bridge_ifclrflag(val, IFBIF_BSTP_AUTOEDGE);
-}
-
-void
-setptp(const char *val, int d)
-{
-bridge_ifsetflag(val, IFBIF_BSTP_PTP);
-}
-
-void
-unsetptp(const char *val, int d)
-{
-bridge_ifclrflag(val, IFBIF_BSTP_PTP);
-}
-
-void
-setautoptp(const char *val, int d)
-{
-bridge_ifsetflag(val, IFBIF_BSTP_AUTOPTP);
-}
-
-void
-unsetautoptp(const char *val, int d)
-{
-bridge_ifclrflag(val, IFBIF_BSTP_AUTOPTP);
-}
-
+#define IFBIF_SETUNSET(NAME,FLAG) \
+void \
+set ## NAME (const char *val, int d) \
+{ \
+bridge_ifsetflag(val, FLAG); \
+} \
+void \
+unset ## NAME (const char *val, int d) \
+{ \
+bridge_ifclrflag(val, FLAG); \
+}
+
+IFBIF_SETUNSET(discover,IFBIF_DISCOVER)
+IFBIF_SETUNSET(blocknonip,IFBIF_BLOCKNONIP)
+IFBIF_SETUNSET(blockipv4,IFBIF_BLOCKIPV4)
+IFBIF_SETUNSET(blockipv6,IFBIF_BLOCKIPV6)
+IFBIF_SETUNSET(learn,IFBIF_LEARNING)
+IFBIF_SETUNSET(stp,IFBIF_STP)
+IFBIF_SETUNSET(edge,IFBIF_BSTP_EDGE)
+IFBIF_SETUNSET(autoedge,IFBIF_BSTP_AUTOEDGE)
+IFBIF_SETUNSET(ptp,IFBIF_BSTP_PTP)
+IFBIF_SETUNSET(autoptp,IFBIF_BSTP_AUTOPTP)

 void
 bridge_ifsetflag(const char *ifsname, u_int32_t flag)
Index: sbin/ifconfig/brconfig.h
===
RCS file: /cvs/src/sbin/ifconfig/brconfig.h,v
retrieving revision 1.9
diff -u -p -u -r1.9 brconfig.h
--- sbin/ifconfig/brconfig.h7 Jan 2016 15:33:56 -1.9
+++ sbin/ifconfig/brconfig.h16 Mar 2016 19:37:44 -
@@ -25,6 +25,10 @@ void setdiscover(const char *, int);
 void unsetdiscover(const char *, int);
 void setblocknonip(const char *, int);
 void unsetblocknonip(const char *, int);
+void setblockipv4(const char *, int);
+void unsetblockipv4(const char *, int);
+void setblockipv6(const char *, int);
+void unsetblockipv6(const char *, int);
 void setlearn(const char *, int);
 void unsetlearn(const char *, int);
 void setstp(const char *, int);
Index: sbin/ifconfig/ifconfig.8
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.8,v
retrieving revision 1.266
diff -u -p -u -r1.266 

Re: make armv5te the gcc default

[Patrick Wildt]

On Sat, Mar 19, 2016 at 09:56:48AM +1100, Jonathan Gray wrote:
> Instead of armv4 tuned for strongarm switch to an armv5te default to
> allow additional instructions to be used (clz etc).
> 
> armish and zaurus are both xscale (armv5te with additional extensions).
> 
> The builtin gcc defines change from
> #define __ARM_ARCH_4__ 1
> to
> #define __ARM_ARCH_5TE__ 1
> 
> -mthumb-interwork remains off by default.

I like that.  Will try to run it as soon as I can spare some time.

Patrick

> 
> Index: openbsd.h
> ===
> RCS file: /cvs/src/gnu/gcc/gcc/config/arm/openbsd.h,v
> retrieving revision 1.4
> diff -u -p -r1.4 openbsd.h
> --- openbsd.h 21 Oct 2011 10:17:08 -  1.4
> +++ openbsd.h 18 Mar 2016 22:33:16 -
> @@ -38,8 +38,8 @@ Boston, MA 02111-1307, USA.  */
>  
>  #undef MULTILIB_DEFAULTS
>  
> -/* strongarm family default cpu.  */
> -#define SUBTARGET_CPU_DEFAULT TARGET_CPU_strongarm
> +/* armv5te default cpu.  */
> +#define SUBTARGET_CPU_DEFAULT TARGET_CPU_arm9e
>  
>  /* Default is to use APCS-32 mode.  */
>  
> 

nam2blk cleanup

[Artturi Alm]

Hi,

related to past cleanup for some of the sys/arch/x/x/conf.c.

-Artturi


Index: sys/arch/alpha/alpha/autoconf.c
===
RCS file: /cvs/src/sys/arch/alpha/alpha/autoconf.c,v
retrieving revision 1.35
diff -u -p -r1.35 autoconf.c
--- sys/arch/alpha/alpha/autoconf.c 25 Nov 2011 05:23:40 -  1.35
+++ sys/arch/alpha/alpha/autoconf.c 17 Mar 2016 16:35:48 -
@@ -214,7 +214,6 @@ struct nam2blk nam2blk[] = {
{ "rd", 6 },
{ "sd", 8 },
{ "wd", 0 },
-   { "raid",   16 },
{ "vnd",9 },
{ NULL, -1 }
 };
Index: sys/arch/amd64/amd64/autoconf.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/autoconf.c,v
retrieving revision 1.43
diff -u -p -r1.43 autoconf.c
--- sys/arch/amd64/amd64/autoconf.c 17 Jul 2015 21:53:56 -  1.43
+++ sys/arch/amd64/amd64/autoconf.c 17 Mar 2016 16:35:49 -
@@ -220,6 +220,5 @@ struct nam2blk nam2blk[] = {
{ "cd", 6 },
{ "vnd",14 },
{ "rd", 17 },
-   { "raid",   19 },
{ NULL, -1 }
 };
Index: sys/arch/armish/armish/autoconf.c
===
RCS file: /cvs/src/sys/arch/armish/armish/autoconf.c,v
retrieving revision 1.12
diff -u -p -r1.12 autoconf.c
--- sys/arch/armish/armish/autoconf.c   20 Sep 2011 22:02:13 -  1.12
+++ sys/arch/armish/armish/autoconf.c   17 Mar 2016 16:35:49 -
@@ -143,7 +143,6 @@ struct nam2blk nam2blk[] = {
{ "sd", 24 },
{ "cd", 26 },
{ "rd", 18 },
-   { "raid",   71 },
{ "vnd",19 },
{ NULL, -1 }
 };
Index: sys/arch/armv7/armv7/autoconf.c
===
RCS file: /cvs/src/sys/arch/armv7/armv7/autoconf.c,v
retrieving revision 1.3
diff -u -p -r1.3 autoconf.c
--- sys/arch/armv7/armv7/autoconf.c 19 May 2015 03:30:54 -  1.3
+++ sys/arch/armv7/armv7/autoconf.c 17 Mar 2016 16:35:49 -
@@ -153,7 +153,6 @@ struct nam2blk nam2blk[] = {
{ "sd", 24 },
{ "cd", 26 },
{ "rd", 18 },
-   { "raid",   71 },
{ NULL, -1 }
 };
 
Index: sys/arch/i386/i386/autoconf.c
===
RCS file: /cvs/src/sys/arch/i386/i386/autoconf.c,v
retrieving revision 1.94
diff -u -p -r1.94 autoconf.c
--- sys/arch/i386/i386/autoconf.c   24 Apr 2015 19:53:43 -  1.94
+++ sys/arch/i386/i386/autoconf.c   17 Mar 2016 16:35:50 -
@@ -258,7 +258,6 @@ struct nam2blk nam2blk[] = {
{ "sd", 4 },
{ "cd", 6 },
{ "rd", 17 },
-   { "raid",   19 },
{ "vnd",14 },
{ NULL, -1 }
 };
Index: sys/arch/macppc/macppc/autoconf.c
===
RCS file: /cvs/src/sys/arch/macppc/macppc/autoconf.c,v
retrieving revision 1.43
diff -u -p -r1.43 autoconf.c
--- sys/arch/macppc/macppc/autoconf.c   4 Apr 2014 01:50:25 -   1.43
+++ sys/arch/macppc/macppc/autoconf.c   17 Mar 2016 16:35:51 -
@@ -284,7 +284,6 @@ struct nam2blk nam2blk[] = {
{ "wd", 0 },
{ "sd", 2 },
{ "rd", 17 },
-   { "raid",   19 },
{ "vnd",14 },
{ NULL, -1 }
 };
Index: sys/arch/socppc/socppc/autoconf.c
===
RCS file: /cvs/src/sys/arch/socppc/socppc/autoconf.c,v
retrieving revision 1.5
diff -u -p -r1.5 autoconf.c
--- sys/arch/socppc/socppc/autoconf.c   1 Apr 2014 20:42:39 -   1.5
+++ sys/arch/socppc/socppc/autoconf.c   17 Mar 2016 16:35:51 -
@@ -68,7 +68,6 @@ struct nam2blk nam2blk[] = {
{ "wd", 0 },
{ "sd", 2 },
{ "rd", 17 },
-   { "raid",   19 },
{ "vnd",14 },
{ NULL, -1 }
 };
Index: sys/arch/sparc/sparc/autoconf.c
===
RCS file: /cvs/src/sys/arch/sparc/sparc/autoconf.c,v
retrieving revision 1.100
diff -u -p -r1.100 autoconf.c
--- sys/arch/sparc/sparc/autoconf.c 30 Mar 2015 20:30:22 -  1.100
+++ sys/arch/sparc/sparc/autoconf.c 17 Mar 2016 16:35:52 -
@@ -1886,7 +1886,6 @@ struct nam2blk nam2blk[] = {
{ "fd", 16 },
{ "rd", 17 },
{ "cd", 18 },
-   { "raid",   25 },
{ "vnd",8 },
{ NULL, -1 }
 };
Index: sys/arch/sparc64/sparc64/autoconf.c
===
RCS file: /cvs/src/sys/arch/sparc64/sparc64/autoconf.c,v
retrieving revision 1.123
diff -u -p -r1.123 autoconf.c
--- sys/arch/sparc64/sparc64/autoconf.c 

cron funcs.h patch

[Edgar Pettijohn]

I guess I could have organized alphabetically.  Still can if preferred.

Index: funcs.h
===
RCS file: /cvs/src/usr.sbin/cron/funcs.h,v
retrieving revision 1.28
diff -u -p -u -r1.28 funcs.h
--- funcs.h14 Nov 2015 13:09:14 -1.28
+++ funcs.h20 Mar 2016 01:43:01 -
@@ -19,39 +19,51 @@

 /* Notes:
  *This file has to be included by cron.h after data structure defs.
- *We should reorg this into sections by module.
  */

-voidload_database(cron_db **),
-job_add(entry *, user *),
-do_command(entry *, user *),
-free_user(user *),
-env_free(char **),
-unget_char(int, FILE *),
-free_entry(entry *),
-skip_comments(FILE *),
-poke_daemon(unsigned char),
-atrun(at_db *, double, time_t);
-
-intjob_runqueue(void),
-get_char(FILE *),
-get_string(char *, int, FILE *, char *),
-load_env(char *, FILE *),
-cron_pclose(FILE *, pid_t),
-allowed(const char *, const char *, const char *),
-safe_p(const char *, const char *),
-scan_atjobs(at_db **, struct timespec *);
-
-char*env_get(char *, char **),
-*first_word(char *, char *),
-**env_init(void),
-**env_copy(char **),
-**env_set(char **, char *);
-
-user*load_user(int, struct passwd *, const char *),
-*find_user(cron_db *, const char *);
-
-entry*load_entry(FILE *,
-void (*)(const char *), struct passwd *, char **);
-
-FILE*cron_popen(char *, char *, struct passwd *, pid_t *);
+/* database.c */
+voidload_database(cron_db **);
+user   *find_user(cron_db *, const char *);
+
+/* job.c */
+voidjob_add(entry *, user *);
+intjob_runqueue(void);
+
+/* do_command.c */
+voiddo_command(entry *, user *);
+intsafe_p(const char *, const char *);
+
+/* user.c */
+voidfree_user(user *);
+user   *load_user(int, struct passwd *, const char *);
+
+/* env.c */
+voidenv_free(char **);
+intload_env(char *, FILE *);
+char   *env_get(char *, char **);
+char  **env_init(void);
+char  **env_copy(char **);
+char  **env_set(char **, char *);
+
+/* misc.c */
+voidunget_char(int, FILE *);
+voidskip_comments(FILE *);
+intget_char(FILE *);
+intget_string(char *, int, FILE *, char *);
+char   *first_word(char *, char *);
+
+/* entry.c */
+voidfree_entry(entry *);
+entry   *load_entry(FILE *,
+void (*)(const char *), struct passwd *, char **);
+/* client.c */
+voidpoke_daemon(unsigned char);
+intallowed(const char *, const char *, const char *);
+
+/* atrun.c */
+voidatrun(at_db *, double, time_t);
+intscan_atjobs(at_db **, struct timespec *);
+
+/* popen.c */
+intcron_pclose(FILE *, pid_t);
+FILE   *cron_popen(char *, char *, struct passwd *, pid_t *);

Re: New scheduler for OpenBSD

[Juan Francisco Cantero Hurtado]

On Tue, Mar 15, 2016 at 03:05:47PM +0100, Michal Mazurek wrote:
> On 16:28:33, 14.03.16, Martin Pieuchot wrote:
> > > The number of calls to yield() dropped to 4,576.
> > 
> > This is really similar to what I observed with Firefox and Chrome.
> > 
> > > This is where I get stuck, I don't know how to replace the call to
> > > sched_yield(), or whether it is a good idea to do so. Any advice?
> > 
> > I'd assume the problem is not in the _spinlock() implementation itself
> > but rather on the code calling this lock.  Do you know which code is
> > triggering this?
> > 
> > See r1.13 of lib/librthread/rthread_libc.c, this is an example where a
> > the use of a spinlock created similar symptoms.
> 
> I don't know how to fix it, but in the meanwhile here is a workaround so
> I can continue working on the scheduler. In yield():
> 
> + tmp = p->p_rrticks;
> + sched_deadline(p);
> + p->p_rrticks = tmp;
> 
> So penalise a process calling yield() by giving it the worst deadline,
> i.e. make it go to the end of the run queue.
> 
> Other than this, no changes.
> 
> Chrome still isn't smooth.
> 
> Please test, and let me know if the performance of something else
> degrades.

The performance in the ffmpeg test has increased about 30-40% compared with
the default scheduler.

Please keep working on it.

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

Re: tedu empty tcsh files in /etc

[Alexander Hall]

On Sun, Mar 20, 2016 at 01:33:06AM +0100, Alexander Hall wrote:
> Hi,
> 
> As far as I can tell, there is no point in having these files lying
> around in /etc as they are not needed by tcsh.  They're all comments
> and don't even hold an example.
> 
> Thus, remove them and make them optional in /etc/mtree/special.
> 
> Objections from tcsh users?

s/tcsh/csh/g, also in subject, as pointed out to me off-list.  I did get
a strange feeling typing all those "tcsh"s.

/Alexander

> 
> OK?
> 
> /Alexander
> 
> 
> Index: Makefile
> ===
> RCS file: /cvs/src/etc/Makefile,v
> retrieving revision 1.421
> diff -u -p -r1.421 Makefile
> --- Makefile  9 Mar 2016 16:28:46 -   1.421
> +++ Makefile  20 Mar 2016 00:21:11 -
> @@ -30,9 +30,8 @@ kernels: bootblocks ${ALL_KERNELS}
>  # -rw-r--r--
>  BINOWN= root
>  BINGRP= wheel
> -MUTABLE=changelist csh.cshrc csh.login csh.logout daily \
> - etc.${MACHINE}/disktab etc.${MACHINE}/login.conf ftpusers \
> - gettytab group ksh.kshrc locate.rc mailer.conf \
> +MUTABLE=changelist daily etc.${MACHINE}/disktab etc.${MACHINE}/login.conf \
> + ftpusers gettytab group ksh.kshrc locate.rc mailer.conf \
>   moduli monthly netstart networks newsyslog.conf ntpd.conf \
>   pf.os protocols rc rc.conf rpc services shells syslog.conf weekly
>  
> Index: csh.cshrc
> ===
> RCS file: /cvs/src/etc/csh.cshrc,v
> retrieving revision 1.2
> diff -u -p -r1.2 csh.cshrc
> --- csh.cshrc 26 May 1996 10:25:19 -  1.2
> +++ csh.cshrc 20 Mar 2016 00:21:11 -
> @@ -1,3 +0,0 @@
> -#$OpenBSD: csh.cshrc,v 1.2 1996/05/26 10:25:19 deraadt Exp $
> -#
> -# System-wide .cshrc file for csh(1).
> Index: csh.login
> ===
> RCS file: /cvs/src/etc/csh.login,v
> retrieving revision 1.2
> diff -u -p -r1.2 csh.login
> --- csh.login 26 May 1996 10:25:19 -  1.2
> +++ csh.login 20 Mar 2016 00:21:11 -
> @@ -1,3 +0,0 @@
> -#$OpenBSD: csh.login,v 1.2 1996/05/26 10:25:19 deraadt Exp $
> -#
> -# System-wide .login file for csh(1).
> Index: csh.logout
> ===
> RCS file: /cvs/src/etc/csh.logout,v
> retrieving revision 1.2
> diff -u -p -r1.2 csh.logout
> --- csh.logout26 May 1996 10:25:20 -  1.2
> +++ csh.logout20 Mar 2016 00:21:11 -
> @@ -1,3 +0,0 @@
> -#$OpenBSD: csh.logout,v 1.2 1996/05/26 10:25:20 deraadt Exp $
> -#
> -# System-wide .logout file for csh(1).
> Index: mtree/special
> ===
> RCS file: /cvs/src/etc/mtree/special,v
> retrieving revision 1.117
> diff -u -p -r1.117 special
> --- mtree/special 8 Mar 2016 00:16:47 -   1.117
> +++ mtree/special 20 Mar 2016 00:21:11 -
> @@ -16,9 +16,9 @@ etc type=dir mode=0755 uname=root gname
>  bgpd.conftype=file mode=0600 uname=root gname=wheel optional
>  chio.conftype=file mode=0644 uname=root gname=operator optional
>  crontab  type=file mode=0600 uname=root gname=wheel optional
> -csh.cshrctype=file mode=0644 uname=root gname=wheel
> -csh.logintype=file mode=0644 uname=root gname=wheel
> -csh.logout   type=file mode=0644 uname=root gname=wheel
> +csh.cshrctype=file mode=0644 uname=root gname=wheel optional
> +csh.logintype=file mode=0644 uname=root gname=wheel optional
> +csh.logout   type=file mode=0644 uname=root gname=wheel optional
>  dailytype=file mode=0644 uname=root gname=wheel
>  daily.local  type=file mode=0644 uname=root gname=wheel optional
>  dhcpd.conf   type=file mode=0644 uname=root gname=wheel optional
> 

Re: arm: remove sa1/ixp12x0

[Patrick Wildt]

On Sat, Mar 19, 2016 at 09:27:19AM +1100, Jonathan Gray wrote:
> On Fri, Mar 18, 2016 at 04:43:08PM +0100, Patrick Wildt wrote:
> > Hi,
> > 
> > next up on the list is the StrongARM and IXP12x0.
> > 
> > This diff removes most, but keeps the SA1100 headers,
> > which are still used by zaurus.
> > 
> > Patrick
> 
> Here is the diff I had:
> 
> The only difference seems to be you've gone with
> 
> #elif ARM_MMU_GENERIC == 1
> 
> and I kept the != 0
> 
> #elif (ARM_MMU_GENERIC) != 0

Yeah, I changed that to == 1 as there are no further calculations going
on anymore.  As long as one of the versions goes in I'm happy.

> 
> Index: arm/bus_space_asm_generic.S
> ===
> RCS file: /cvs/src/sys/arch/arm/arm/bus_space_asm_generic.S,v
> retrieving revision 1.2
> diff -u -p -r1.2 bus_space_asm_generic.S
> --- arm/bus_space_asm_generic.S   8 May 2009 02:57:31 -   1.2
> +++ arm/bus_space_asm_generic.S   18 Mar 2016 22:17:19 -
> @@ -50,7 +50,7 @@ ENTRY(generic_bs_r_1)
>   ldrbr0, [r1, r2]
>   mov pc, lr
>  
> -#if (ARM_ARCH_4 + ARM_ARCH_5 + ARM_ARCH_6 + ARM_ARCH_7) > 0
> +#if (ARM_ARCH_5 + ARM_ARCH_6 + ARM_ARCH_7) > 0
>  ENTRY(generic_armv4_bs_r_2)
>   ldrhr0, [r1, r2]
>   mov pc, lr
> @@ -68,7 +68,7 @@ ENTRY(generic_bs_w_1)
>   strbr3, [r1, r2]
>   mov pc, lr
>  
> -#if (ARM_ARCH_4 + ARM_ARCH_5 + ARM_ARCH_6 + ARM_ARCH_7) > 0
> +#if (ARM_ARCH_5 + ARM_ARCH_6 + ARM_ARCH_7) > 0
>  ENTRY(generic_armv4_bs_w_2)
>   strhr3, [r1, r2]
>   mov pc, lr
> @@ -96,7 +96,7 @@ ENTRY(generic_bs_rm_1)
>  
>   mov pc, lr
>  
> -#if (ARM_ARCH_4 + ARM_ARCH_5 + ARM_ARCH_6 + ARM_ARCH_7) > 0
> +#if (ARM_ARCH_5 + ARM_ARCH_6 + ARM_ARCH_7) > 0
>  ENTRY(generic_armv4_bs_rm_2)
>   add r0, r1, r2
>   mov r1, r3
> @@ -144,7 +144,7 @@ ENTRY(generic_bs_wm_1)
>  
>   mov pc, lr
>  
> -#if (ARM_ARCH_4 + ARM_ARCH_5 + ARM_ARCH_6 + ARM_ARCH_7) > 0
> +#if (ARM_ARCH_5 + ARM_ARCH_6 + ARM_ARCH_7) > 0
>  ENTRY(generic_armv4_bs_wm_2)
>   add r0, r1, r2
>   mov r1, r3
> @@ -192,7 +192,7 @@ ENTRY(generic_bs_rr_1)
>  
>   mov pc, lr
>  
> -#if (ARM_ARCH_4 + ARM_ARCH_5 + ARM_ARCH_6 + ARM_ARCH_7) > 0
> +#if (ARM_ARCH_5 + ARM_ARCH_6 + ARM_ARCH_7) > 0
>  ENTRY(generic_armv4_bs_rr_2)
>   add r0, r1, r2
>   mov r1, r3
> @@ -240,7 +240,7 @@ ENTRY(generic_bs_wr_1)
>  
>   mov pc, lr
>  
> -#if (ARM_ARCH_4 + ARM_ARCH_5 + ARM_ARCH_6 + ARM_ARCH_7) > 0
> +#if (ARM_ARCH_5 + ARM_ARCH_6 + ARM_ARCH_7) > 0
>  ENTRY(generic_armv4_bs_wr_2)
>   add r0, r1, r2
>   mov r1, r3
> @@ -287,7 +287,7 @@ ENTRY(generic_bs_sr_1)
>  
>   mov pc, lr
>  
> -#if (ARM_ARCH_4 + ARM_ARCH_5 + ARM_ARCH_6 + ARM_ARCH_7) > 0
> +#if (ARM_ARCH_5 + ARM_ARCH_6 + ARM_ARCH_7) > 0
>  ENTRY(generic_armv4_bs_sr_2)
>   add r0, r1, r2
>   mov r1, r3
> @@ -319,7 +319,7 @@ ENTRY(generic_bs_sr_4)
>   * copy region
>   */
>  
> -#if (ARM_ARCH_4 + ARM_ARCH_5 + ARM_ARCH_6 + ARM_ARCH_7) > 0
> +#if (ARM_ARCH_5 + ARM_ARCH_6 + ARM_ARCH_7) > 0
>  ENTRY(generic_armv4_bs_c_2)
>   add r0, r1, r2
>   ldr r2, [sp, #0]
> Index: arm/cpu.c
> ===
> RCS file: /cvs/src/sys/arch/arm/arm/cpu.c,v
> retrieving revision 1.24
> diff -u -p -r1.24 cpu.c
> --- arm/cpu.c 18 Mar 2016 13:16:02 -  1.24
> +++ arm/cpu.c 18 Mar 2016 22:17:20 -
> @@ -87,7 +87,6 @@ enum cpu_class {
>   CPU_CLASS_ARM9ES,
>   CPU_CLASS_ARM9EJS,
>   CPU_CLASS_ARM10E,
> - CPU_CLASS_SA1,
>   CPU_CLASS_XSCALE,
>   CPU_CLASS_ARM11J,
>   CPU_CLASS_ARMv7
> @@ -100,36 +99,6 @@ static const char * const generic_steppi
>   "rev 12",   "rev 13",   "rev 14",   "rev 15"
>  };
>  
> -static const char * const sa110_steppings[16] = {
> - "rev 0","step J",   "step K",   "step S",
> - "step T",   "rev 5","rev 6","rev 7",
> - "rev 8","rev 9","rev 10",   "rev 11",
> - "rev 12",   "rev 13",   "rev 14",   "rev 15"
> -};
> -
> -static const char * const sa1100_steppings[16] = {
> - "rev 0","step B",   "step C",   "rev 3",
> - "rev 4","rev 5","rev 6","rev 7",
> - "step D",   "step E",   "rev 10""step G",
> - "rev 12",   "rev 13",   "rev 14",   "rev 15"
> -};
> -
> -static const char * const sa1110_steppings[16] = {
> - "step A-0", "rev 1","rev 2","rev 3",
> - "step B-0", "step B-1", "step B-2", "step B-3",
> - "step B-4", "step B-5", "rev 10",   "rev 11",
> - "rev 12",   "rev 13",   "rev 14",   "rev 15"
> -};
> -
> -static const char * const ixp12x0_steppings[16] = {
> - "(IXP1200 step A)", "(IXP1200 step B)",
> - "rev 2",

tedu empty tcsh files in /etc

[Alexander Hall]

Hi,

As far as I can tell, there is no point in having these files lying
around in /etc as they are not needed by tcsh.  They're all comments
and don't even hold an example.

Thus, remove them and make them optional in /etc/mtree/special.

Objections from tcsh users?

OK?

/Alexander


Index: Makefile
===
RCS file: /cvs/src/etc/Makefile,v
retrieving revision 1.421
diff -u -p -r1.421 Makefile
--- Makefile9 Mar 2016 16:28:46 -   1.421
+++ Makefile20 Mar 2016 00:21:11 -
@@ -30,9 +30,8 @@ kernels: bootblocks ${ALL_KERNELS}
 # -rw-r--r--
 BINOWN= root
 BINGRP= wheel
-MUTABLE=changelist csh.cshrc csh.login csh.logout daily \
-   etc.${MACHINE}/disktab etc.${MACHINE}/login.conf ftpusers \
-   gettytab group ksh.kshrc locate.rc mailer.conf \
+MUTABLE=changelist daily etc.${MACHINE}/disktab etc.${MACHINE}/login.conf \
+   ftpusers gettytab group ksh.kshrc locate.rc mailer.conf \
moduli monthly netstart networks newsyslog.conf ntpd.conf \
pf.os protocols rc rc.conf rpc services shells syslog.conf weekly
 
Index: csh.cshrc
===
RCS file: /cvs/src/etc/csh.cshrc,v
retrieving revision 1.2
diff -u -p -r1.2 csh.cshrc
--- csh.cshrc   26 May 1996 10:25:19 -  1.2
+++ csh.cshrc   20 Mar 2016 00:21:11 -
@@ -1,3 +0,0 @@
-#  $OpenBSD: csh.cshrc,v 1.2 1996/05/26 10:25:19 deraadt Exp $
-#
-# System-wide .cshrc file for csh(1).
Index: csh.login
===
RCS file: /cvs/src/etc/csh.login,v
retrieving revision 1.2
diff -u -p -r1.2 csh.login
--- csh.login   26 May 1996 10:25:19 -  1.2
+++ csh.login   20 Mar 2016 00:21:11 -
@@ -1,3 +0,0 @@
-#  $OpenBSD: csh.login,v 1.2 1996/05/26 10:25:19 deraadt Exp $
-#
-# System-wide .login file for csh(1).
Index: csh.logout
===
RCS file: /cvs/src/etc/csh.logout,v
retrieving revision 1.2
diff -u -p -r1.2 csh.logout
--- csh.logout  26 May 1996 10:25:20 -  1.2
+++ csh.logout  20 Mar 2016 00:21:11 -
@@ -1,3 +0,0 @@
-#  $OpenBSD: csh.logout,v 1.2 1996/05/26 10:25:20 deraadt Exp $
-#
-# System-wide .logout file for csh(1).
Index: mtree/special
===
RCS file: /cvs/src/etc/mtree/special,v
retrieving revision 1.117
diff -u -p -r1.117 special
--- mtree/special   8 Mar 2016 00:16:47 -   1.117
+++ mtree/special   20 Mar 2016 00:21:11 -
@@ -16,9 +16,9 @@ etc   type=dir mode=0755 uname=root gname
 bgpd.conf  type=file mode=0600 uname=root gname=wheel optional
 chio.conf  type=file mode=0644 uname=root gname=operator optional
 crontabtype=file mode=0600 uname=root gname=wheel optional
-csh.cshrc  type=file mode=0644 uname=root gname=wheel
-csh.login  type=file mode=0644 uname=root gname=wheel
-csh.logout type=file mode=0644 uname=root gname=wheel
+csh.cshrc  type=file mode=0644 uname=root gname=wheel optional
+csh.login  type=file mode=0644 uname=root gname=wheel optional
+csh.logout type=file mode=0644 uname=root gname=wheel optional
 daily  type=file mode=0644 uname=root gname=wheel
 daily.localtype=file mode=0644 uname=root gname=wheel optional
 dhcpd.conf type=file mode=0644 uname=root gname=wheel optional

stop urndis(4) dmesg spam

[Stefan Sperling]

While tethering to my phone on a train, I'm seeing a lot of these lines
in dmesg:

urndis0: usb errors on rx: IOERROR
urndis0: usb error on tx: IOERROR

So many in fact that if I run 'dmesg' that's all I see, over and over.
However, network mostly works, and works particularly well given the right
conditions (e.g. when the train stops at a station :)

I don't think a driver should write a line to dmesg for every dropped packet.
We have error counters for that.
Moreover, this driver forgot about counting input errors.

Index: if_urndis.c
===
RCS file: /cvs/src/sys/dev/usb/if_urndis.c,v
retrieving revision 1.59
diff -u -p -r1.59 if_urndis.c
--- if_urndis.c 25 Nov 2015 03:10:00 -  1.59
+++ if_urndis.c 16 Mar 2016 13:00:59 -
@@ -854,11 +854,11 @@ urndis_decap(struct urndis_softc *sc, st
 
if (letoh32(msg->rm_datalen) < sizeof(struct ether_header)) {
ifp->if_ierrors++;
-   printf("%s: urndis_decap invalid ethernet size "
+   DPRINTF(("%s: urndis_decap invalid ethernet size "
"%u < %zu\n",
DEVNAME(sc),
letoh32(msg->rm_datalen),
-   sizeof(struct ether_header));
+   sizeof(struct ether_header)));
return;
}
 
@@ -1200,12 +1200,13 @@ urndis_rxeof(struct usbd_xfer *xfer,
if (status == USBD_NOT_STARTED || status == USBD_CANCELLED)
return;
if (usbd_ratecheck(>sc_rx_notice)) {
-   printf("%s: usb errors on rx: %s\n",
-   DEVNAME(sc), usbd_errstr(status));
+   DPRINTF(("%s: usb errors on rx: %s\n",
+   DEVNAME(sc), usbd_errstr(status)));
}
if (status == USBD_STALLED)
usbd_clear_endpoint_stall_async(sc->sc_bulkin_pipe);
 
+   ifp->if_ierrors++;
goto done;
}
 
@@ -1251,8 +1252,8 @@ urndis_txeof(struct usbd_xfer *xfer,
return;
}
ifp->if_oerrors++;
-   printf("%s: usb error on tx: %s\n", DEVNAME(sc),
-   usbd_errstr(status));
+   DPRINTF(("%s: usb error on tx: %s\n", DEVNAME(sc),
+   usbd_errstr(status)));
if (status == USBD_STALLED)
usbd_clear_endpoint_stall_async(sc->sc_bulkout_pipe);
splx(s);

Re: New scheduler for OpenBSD

[Michael McConville]

Bob Beck wrote:
> this is cool .. but
> 
> I would be interested in someone comparing server workloads, as
> opposed to interactive GUI response, using this.
> 
> I wouldn't be surprised that inspiriation from BFS would produce
> better interactive response, my bigger concern would be does this
> adversely impact how we deal with non-interactive workloads.

Those interested might find the benchmarks/siege port useful.

Re: Scheduler hack for multi-threaded processes

[Miod Vallat]

> p_p->ps_threads (and p_thr_link) can only be modified by threads in
> this process.  The result is that the test here can't claim the
> process is single-threaded when it's multi-threaded.  (An "is MT"
> result can go stale if there's no locking and the only other thread in
> the process exits, but that's generally not an issue.)
>
> If you really need to walk the p_p->ps_threads list, then you
> currently need the kernel lock to keep the threads in it from
> disappearing.

The proposed diff only peeks at the head of the list. But you're right,
the other code paths doing this (peek instead of full traversal) seem to
be under KERNEL_LOCK already.

Re: Scheduler hack for multi-threaded processes

[Juan Francisco Cantero Hurtado]

On Sat, Mar 19, 2016 at 01:53:07PM +0100, Martin Pieuchot wrote:
> Applications using multiple threads often call sched_yield(2) to
> indicate that one of the threads cannot make any progress because
> it is waiting for a resource held by another one.
> 
> One example of this scenario is the _spinlock() implementation of
> our librthread.  But if you look on https://codesearch.debian.net
> you can find much more use cases, notably MySQL, PostgreSQL, JDK,
> libreoffice, etc.
> 
> Now the problem with our current scheduler is that the priority of
> a thread decreases when it is the "curproc" of a CPU.  So the threads
> that don't run and sched_yield(2) end up having a higher priority than
> the thread holding the resource.  Which means that it's really hard for
> such multi-threaded applications to make progress, resulting in a lot of
> IPIs numbers.
> That'd also explain why if you have a more CPUs, let's say 4 instead
> of 2, your application will more likely make some progress and you'll
> see less sluttering/freezing.
> 
> So what the diff below does is that it penalizes the threads from
> multi-threaded applications such that progress can be made.  It is
> inspired from the recent scheduler work done by Michal Mazurek on
> tech@.
> 
> I experimented with various values for "p_priority" and this one is
> the one that generates fewer # IPIs when watching a HD video on firefox. 
> Because yes, with this diff, now I can.
> 
> I'd like to know if dereferencing ``p_p'' is safe without holding the
> KERNEL_LOCK.
> 
> I'm also interested in hearing from more people using multi-threaded
> applications.

In the ffmpeg test case, the frames-per-second increased 25%. The only
modification in the kernel was your patch.

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

Re: stty header cleanup

[Michael McConville]

One correction:

Edgar Pettijohn wrote:
> Index: cchar.c
> ===
> RCS file: /cvs/src/bin/stty/cchar.c,v
> retrieving revision 1.11
> diff -u -p -u -r1.11 cchar.c
> --- cchar.c27 Oct 2009 23:59:22 -1.11
> +++ cchar.c16 Mar 2016 23:53:58 -
> @@ -30,6 +30,7 @@
>   * SUCH DAMAGE.
>   */
> 
> +#include 
>  #include 
> 
>  #include 

deraadt pointed out that sys/types.h has to come first here.

> Index: key.c
> ===
> RCS file: /cvs/src/bin/stty/key.c,v
> retrieving revision 1.16
> diff -u -p -u -r1.16 key.c
> --- key.c20 Nov 2015 15:57:39 -1.16
> +++ key.c16 Mar 2016 23:55:51 -
> @@ -30,14 +30,16 @@
>   * SUCH DAMAGE.
>   */
> 
> +#include 
>  #include 

And here.

> Index: stty.c
> ===
> RCS file: /cvs/src/bin/stty/stty.c,v
> retrieving revision 1.18
> diff -u -p -u -r1.18 stty.c
> --- stty.c20 Nov 2015 15:58:28 -1.18
> +++ stty.c16 Mar 2016 23:58:14 -
> @@ -30,16 +30,18 @@
>   * SUCH DAMAGE.
>   */
> 
> +#include 
>  #include 

And here.

uvm amap: Simplify amap traversal in amap_swap_off

[Stefan Kempf]

The recent uvm commits fixed hangs because machines went out of memory
because of using too much space for amap slots.

It's possible to shrink memory requirements for amaps even more,
but the current code needs some simplifications first. So here's another
cleanup diff. There'll be one or two more before we get to the real stuff.

This one simplifies the traversal of an amap when swap is disabled.

There's no need to insert marker elements to find the next item in the
amap list. The next amap can be determined by looking at the
currently examined amap.

Care must be taken to get the next element before the current amap is
possibly deleted, and after all the current amap's pages were read in
from swap (because the page-in may sleep and remove items from the amap
list).

ok?

Index: uvm/uvm_amap.c
===
RCS file: /cvs/src/sys/uvm/uvm_amap.c,v
retrieving revision 1.62
diff -u -p -r1.62 uvm_amap.c
--- uvm/uvm_amap.c  16 Mar 2016 16:53:43 -  1.62
+++ uvm/uvm_amap.c  17 Mar 2016 18:08:29 -
@@ -902,21 +902,11 @@ amap_swap_off(int startslot, int endslot
 {
struct vm_amap *am;
struct vm_amap *am_next;
-   struct vm_amap marker_prev;
-   struct vm_amap marker_next;
boolean_t rv = FALSE;
 
-#if defined(DIAGNOSTIC)
-   memset(_prev, 0, sizeof(marker_prev));
-   memset(_next, 0, sizeof(marker_next));
-#endif /* defined(DIAGNOSTIC) */
-
for (am = LIST_FIRST(_list); am != NULL && !rv; am = am_next) {
int i;
 
-   LIST_INSERT_BEFORE(am, _prev, am_list);
-   LIST_INSERT_AFTER(am, _next, am_list);
-
for (i = 0; i < am->am_nused; i++) {
int slot;
int swslot;
@@ -935,23 +925,14 @@ amap_swap_off(int startslot, int endslot
rv = uvm_anon_pagein(anon);
 
am->am_flags &= ~AMAP_SWAPOFF;
-   if (amap_refs(am) == 0) {
-   amap_wipeout(am);
-   am = NULL;
+   if (rv || amap_refs(am) == 0)
break;
-   }
-   if (rv) {
-   break;
-   }
i = 0;
}
 
-   KASSERT(LIST_NEXT(_prev, am_list) == _next ||
-   LIST_NEXT(LIST_NEXT(_prev, am_list), am_list) ==
-   _next);
-   am_next = LIST_NEXT(_next, am_list);
-   LIST_REMOVE(_prev, am_list);
-   LIST_REMOVE(_next, am_list);
+   am_next = LIST_NEXT(am, am_list);
+   if (amap_refs(am) == 0)
+   amap_wipeout(am);
}
 
return rv;

Re: New scheduler for OpenBSD

[Bob Beck]

this is cool .. but

I would be interested in someone comparing server workloads, as
opposed to interactive GUI response, using this.

I wouldn't be surprised that inspiriation from BFS would produce
better interactive response, my bigger concern
would be does this adversely impact how we deal with non-interactive workloads.


On Fri, Mar 18, 2016 at 8:56 AM, Norman Golisz  wrote:
> Hi Michal,
>
> On Fri Mar 18 2016 10:03, Edd Barrett wrote:
>> On Thu, Mar 17, 2016 at 09:26:08PM +0100, Henrik Friedrichsen wrote:
>> > On Tue, Mar 15, 2016 at 03:05:47PM +0100, Michal Mazurek wrote:
>> > > Chrome still isn't smooth.
>> > >
>> > > Please test, and let me know if the performance of something else
>> > > degrades.
>> >
>> > While Chrome may not be 100% smooth yet, the system is a lot more
>> > interactive. I can now play YouTube videos without stutters while doing
>> > other things.
>>
>> I can't vouch for the code, but this makes video playback in firefox
>> usable on my x240t. Before it would stutter beyond belief.
>>
>> I'll run with this for a while and let you know if anything comes up.
>
> I can also confirm this patch makes a HUGE difference in video playback
> performance in firefox and minitube on my T400.
>
> This is the first time I can watch videos without stuttering (even in
> HD/full screen).
>
> And it seems to improve "GUI responsiveness" in general, too.
>
> Thank you for working on this!
>

Re: CPUID in amd64/i386 boot code

[Masao Uebayashi]

This is the intended use, avoid busy-polling of BIOS PC console if
running on HV.  Avoid 100% CPU usage at boot prompt on hypervisors.

Originally I unconditionally reverted the polling part, which was
introduced only for Intel Mac Mini.  After brief discussion with mikeb@,
I decided to leave that hack by checking HV bit in CPUID (cpu_ecxfeature).

diff --git a/sys/arch/amd64/stand/libsa/bioscons.c 
b/sys/arch/amd64/stand/libsa/bioscons.c
index bdff9a4..fa42751 100644
--- a/sys/arch/amd64/stand/libsa/bioscons.c
+++ b/sys/arch/amd64/stand/libsa/bioscons.c
@@ -30,6 +30,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -37,7 +38,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 #include "biosdev.h"
 
@@ -82,14 +83,17 @@ pc_getc(dev_t dev)
return (rv & 0xff);
}
 
-   /*
-* Wait for a character to actually become available.  Appears to
-* be necessary on (at least) the Intel Mac Mini.
-*/
-   do {
-   __asm volatile(DOINT(0x16) "; setnz %b0" : "=a" (rv) :
-   "0" (0x100) : "%ecx", "%edx", "cc" );
-   } while ((rv & 0xff) == 0);
+   if ((cpu_ecxfeature & CPUIDECX_HV) == 0) {
+   /*
+ * Wait for a character to actually become available.
+ * Appears to be necessary on (at least) the Intel Mac
+ * Mini.
+*/
+   do {
+   __asm volatile(DOINT(0x16) "; setnz %b0" : "=a" (rv) :
+   "0" (0x100) : "%ecx", "%edx", "cc" );
+   } while ((rv & 0xff) == 0);
+   }
 
__asm volatile(DOINT(0x16) : "=a" (rv) : "0" (0x000) :
"%ecx", "%edx", "cc" );
diff --git a/sys/arch/i386/stand/libsa/bioscons.c 
b/sys/arch/i386/stand/libsa/bioscons.c
index 028bef3..b53abcf 100644
--- a/sys/arch/i386/stand/libsa/bioscons.c
+++ b/sys/arch/i386/stand/libsa/bioscons.c
@@ -27,15 +27,20 @@
  */
 
 #include 
+
 #include 
 #include 
+#include 
+
 #include 
 #include 
 #include 
 #include 
 /* #include  */
 #include 
-#include 
+
+#include 
+
 #include "debug.h"
 #include "biosdev.h"
 
@@ -80,14 +85,17 @@ pc_getc(dev_t dev)
return (rv & 0xff);
}
 
-   /*
-* Wait for a character to actually become available.  Appears to
-* be necessary on (at least) the Intel Mac Mini.
-*/
-   do {
-   __asm volatile(DOINT(0x16) "; setnz %b0" : "=a" (rv) :
-   "0" (0x100) : "%ecx", "%edx", "cc" );
-   } while ((rv & 0xff) == 0);
+   if ((cpu_ecxfeature & CPUIDECX_HV) == 0) {
+   /*
+ * Wait for a character to actually become available.
+ * Appears to be necessary on (at least) the Intel Mac
+ * Mini.
+*/
+   do {
+   __asm volatile(DOINT(0x16) "; setnz %b0" : "=a" (rv) :
+   "0" (0x100) : "%ecx", "%edx", "cc" );
+   } while ((rv & 0xff) == 0);
+   }
 
__asm volatile(DOINT(0x16) : "=a" (rv) : "0" (0x000) :
"%ecx", "%edx", "cc" );

On Thu, Mar 17, 2016 at 02:58:58PM +0900, Masao Uebayashi wrote:
> Factor out CPUID code in mdrandom(), invoke it once, then save the
> result.  I'll use it to switch behavior depending on HV or not.
> 
> efiboot is not tested.
> 
> Comments?

> >From 104cb04bbbd0f7e40758938cc3103b2370a2285c Mon Sep 17 00:00:00 2001
> From: Masao Uebayashi 
> Date: Thu, 10 Mar 2016 21:03:07 +0900
> Subject: [PATCH 1/3] Factor out CPUID instruction in amd64 boot code
> 
> ---
>  sys/arch/amd64/stand/boot/Makefile   |  1 +
>  sys/arch/amd64/stand/boot/srt0.S |  1 +
>  sys/arch/amd64/stand/cdboot/Makefile |  1 +
>  sys/arch/amd64/stand/cdboot/srt0.S   |  2 +
>  sys/arch/amd64/stand/libsa/cpuid.S   | 69 
> 
>  sys/arch/amd64/stand/libsa/libsa.h   |  7 
>  sys/arch/amd64/stand/libsa/random_i386.S | 22 +-
>  sys/arch/amd64/stand/pxeboot/Makefile|  1 +
>  sys/arch/amd64/stand/pxeboot/srt0.S  |  2 +
>  9 files changed, 86 insertions(+), 20 deletions(-)
>  create mode 100644 sys/arch/amd64/stand/libsa/cpuid.S
> 
> diff --git a/sys/arch/amd64/stand/boot/Makefile 
> b/sys/arch/amd64/stand/boot/Makefile
> index 359ea31..5811646 100644
> --- a/sys/arch/amd64/stand/boot/Makefile
> +++ b/sys/arch/amd64/stand/boot/Makefile
> @@ -26,6 +26,7 @@ SRCS+=  boot.c bootarg.c cmd.c vars.c
>  
>  .PATH:   ${SADIR}/libsa
>  SRCS+=   gidt.S random_i386.S
> +SRCS+=   cpuid.S
>  SRCS+=   cmd_i386.c dev_i386.c exec_i386.c gateA20.c machdep.c
>  SRCS+=   bioscons.c biosdev.c diskprobe.c memprobe.c time.c
>  .if ${SOFTRAID:L} == "yes"
> diff --git a/sys/arch/amd64/stand/boot/srt0.S 
> b/sys/arch/amd64/stand/boot/srt0.S
> index 9e1ede6..c2a5b2a 100644
> --- a/sys/arch/amd64/stand/boot/srt0.S
> +++ b/sys/arch/amd64/stand/boot/srt0.S
> @@ 

tcp syn cache random reseed

[Alexander Bluhm]

Hi,

To prevent attacks on the hash buckets of the syn cache, our TCP
stack reseeds the hash function every time the cache is empty.
Unfortunatly the attacker can prevent the reseeding by sending
unanswered SYN packes periodically.

I fix this by having an active syn cache that gets new entries and
a passive one that is idling out.  When the passive one is empty
it becomes active with a new random hash seed.

The drawback is that the the cache lookup has to be done in two syn
caches when an ACK arrives.

Perhaps the tcps_sc_seedrandom counter with a netstat -s line should
be commited anyway to show the problem.

I think this reseeding fix is independent from a decision if the
change the hash algorithm to sip hash.  I also have a diff for that.

comments?

bluhm

Index: netinet/tcp_input.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/tcp_input.c,v
retrieving revision 1.314
diff -u -p -r1.314 tcp_input.c
--- netinet/tcp_input.c 7 Mar 2016 18:44:00 -   1.314
+++ netinet/tcp_input.c 19 Mar 2016 20:58:34 -
@@ -3260,40 +3260,44 @@ tcp_mss_adv(struct mbuf *m, int af)
 inttcp_syn_cache_size = TCP_SYN_HASH_SIZE;
 inttcp_syn_cache_limit = TCP_SYN_HASH_SIZE*TCP_SYN_BUCKET_SIZE;
 inttcp_syn_bucket_limit = 3*TCP_SYN_BUCKET_SIZE;
-inttcp_syn_cache_count;
-struct syn_cache_head tcp_syn_cache[TCP_SYN_HASH_SIZE];
-u_int32_t tcp_syn_hash[5];
-
-#define SYN_HASH(sa, sp, dp) \
-   (((sa)->s_addr ^ tcp_syn_hash[0]) * \
-   (u_int32_t)(dp))<<16) + ((u_int32_t)(sp))) ^ tcp_syn_hash[4]))
+
+struct syn_cache_set {
+struct syn_cache_head scs_buckethead[TCP_SYN_HASH_SIZE];
+intscs_count;
+u_int32_t  scs_random[5];
+} tcp_syn_cache[2];
+int tcp_syn_cache_active;
+
+#define SYN_HASH(sa, sp, dp, rand) \
+   (((sa)->s_addr ^ (rand)[0]) *   \
+   (u_int32_t)(dp))<<16) + ((u_int32_t)(sp))) ^ (rand)[4]))
 #ifndef INET6
-#defineSYN_HASHALL(hash, src, dst) \
+#defineSYN_HASHALL(hash, src, dst, rand) \
 do {   \
hash = SYN_HASH((src)->sin_addr,\
satosin(src)->sin_port, \
-   satosin(dst)->sin_port);\
+   satosin(dst)->sin_port, (rand));\
 } while (/*CONSTCOND*/ 0)
 #else
-#define SYN_HASH6(sa, sp, dp) \
-   (((sa)->s6_addr32[0] ^ tcp_syn_hash[0]) *   \
-   ((sa)->s6_addr32[1] ^ tcp_syn_hash[1]) *\
-   ((sa)->s6_addr32[2] ^ tcp_syn_hash[2]) *\
-   ((sa)->s6_addr32[3] ^ tcp_syn_hash[3]) *\
-   (u_int32_t)(dp))<<16) + ((u_int32_t)(sp))) ^ tcp_syn_hash[4]))
+#define SYN_HASH6(sa, sp, dp, rand) \
+   (((sa)->s6_addr32[0] ^ (rand)[0]) * \
+   ((sa)->s6_addr32[1] ^ (rand)[1]) *  \
+   ((sa)->s6_addr32[2] ^ (rand)[2]) *  \
+   ((sa)->s6_addr32[3] ^ (rand)[3]) *  \
+   (u_int32_t)(dp))<<16) + ((u_int32_t)(sp))) ^ (rand)[4]))
 
-#define SYN_HASHALL(hash, src, dst) \
+#define SYN_HASHALL(hash, src, dst, rand) \
 do {   \
switch ((src)->sa_family) { \
case AF_INET:   \
hash = SYN_HASH((src)->sin_addr,\
satosin(src)->sin_port, \
-   satosin(dst)->sin_port);\
+   satosin(dst)->sin_port, (rand));\
break;  \
case AF_INET6:  \
hash = SYN_HASH6((src)->sin6_addr, \
satosin6(src)->sin6_port,   \
-   satosin6(dst)->sin6_port);  \
+   satosin6(dst)->sin6_port, (rand));  \
break;  \
default:\
hash = 0;   \
@@ -3305,13 +3309,12 @@ void
 syn_cache_rm(struct syn_cache *sc)
 {
sc->sc_flags |= SCF_DEAD;
-   TAILQ_REMOVE(_syn_cache[sc->sc_bucketidx].sch_bucket,
-   sc, sc_bucketq);
+   TAILQ_REMOVE(>sc_buckethead->sch_bucket, sc, sc_bucketq);
sc->sc_tp = NULL;
LIST_REMOVE(sc, sc_tpq);
-   tcp_syn_cache[sc->sc_bucketidx].sch_length--;
+   sc->sc_buckethead->sch_length--;

Re: Scheduler hack for multi-threaded processes

[Bob]

I'm also interested in hearing from more people using multi-threaded
applications.


I applied the patch to my old core duo p7570 running CURRENT/amd64.
Firefox is more responsive and youtube videos, previously impossible to 
watch, run smoothly, even in full screen. Sumultaneously did some photo 
editing work in gimp, ran gigabyte sized file transfers with sftp and took 
a CVS update on ports without any hiccups. Browsing in Firefox remained 
smooth although I heard a few glitchs in audio playback when scrolling 
while a busy page was still loading, with load average hovering around 
2.5 with 58 processes and 138 threads at the time. Otherwise smooth 
sailing, very nice.


Bob

Re: fan control on macppc G5 smu

[Olivier Cherrier]

On Fri, Mar 18, 2016 at 01:02:43PM +0100, m...@openbsd.org wrote:
> 
> Could you test the diff below and tell me if it also helps?  It is
> adapted from a submission from Dominic Marks:
>   https://marc.info/?l=openbsd-ppc=142836014007157=2
 
Indeed it does more or less the same thing.
So, it helps.


But I would say it doesn't slow down enough the fan speed to be really
silent when the machine is idle.


For instance, with the patch I sent (when idle) :
hw.sensors.smu0.temp0=39.19 degC (CPU T-Diode)
hw.sensors.smu0.fan0=1128 RPM (System Fan)
hw.sensors.smu0.fan1=1128 RPM (CPU fan)
hw.sensors.smu0.fan2=1128 RPM (Hard Drive)
hw.sensors.smu0.volt0=11.88 VDC (CPU Voltage)
hw.sensors.smu0.current0=0.62 A (CPU Current)
hw.sensors.lmtemp0.temp0=33.00 degC

With a speed around 1100 RPM, it is almost silent and it is similar as if
it were running MacOS X.


With the patch you sent, we get (when idle) :
hw.sensors.smu0.temp0=39.02 degC (CPU T-Diode)
hw.sensors.smu0.fan0=1520 RPM (System Fan)
hw.sensors.smu0.fan1=1520 RPM (CPU fan)
hw.sensors.smu0.fan2=1520 RPM (Hard Drive)
hw.sensors.smu0.volt0=11.88 VDC (CPU Voltage)
hw.sensors.smu0.current0=0.62 A (CPU Current)
hw.sensors.lmtemp0.temp0=37.00 degC
... and it's a bit noisy and borring on a desk.


Maybe CPU_TEMP_MIN could be bumped a little bit ?


Thanks !
Best
oc

Re: CPUID in amd64/i386 boot code

[Mike Larkin]

On Thu, Mar 17, 2016 at 03:31:45PM +0900, Masao Uebayashi wrote:
> On Wed, Mar 16, 2016 at 11:26:39PM -0700, Mike Larkin wrote:
> > On Thu, Mar 17, 2016 at 03:15:07PM +0900, Masao Uebayashi wrote:
> > > This is the intended use, avoid busy-polling of BIOS PC console if
> > > running on HV.  Avoid 100% CPU usage at boot prompt on hypervisors.
> > > 
> > 
> > Which hypervisors have you tested this on?
> 
> VMware ESXi
> KVM
> QEMU

While I share some of Theo's concerns about testing this, this particular
diff seems ok to me. You probably at least need to get someone to test on
Hyper-V, and run these new bootblocks on a variety of machines (especially
older non-Intel/AMD i386 machines).

-ml

> 
> > -ml
> > 
> > > Originally I unconditionally reverted the polling part, which was
> > > introduced only for Intel Mac Mini.  After brief discussion with mikeb@,
> > > I decided to leave that hack by checking HV bit in CPUID (cpu_ecxfeature).
> > > 
> > > diff --git a/sys/arch/amd64/stand/libsa/bioscons.c 
> > > b/sys/arch/amd64/stand/libsa/bioscons.c
> > > index bdff9a4..fa42751 100644
> > > --- a/sys/arch/amd64/stand/libsa/bioscons.c
> > > +++ b/sys/arch/amd64/stand/libsa/bioscons.c
> > > @@ -30,6 +30,7 @@
> > >  
> > >  #include 
> > >  #include 
> > > +#include 
> > >  
> > >  #include 
> > >  #include 
> > > @@ -37,7 +38,7 @@
> > >  #include 
> > >  #include 
> > >  
> > > -#include 
> > > +#include 
> > >  
> > >  #include "biosdev.h"
> > >  
> > > @@ -82,14 +83,17 @@ pc_getc(dev_t dev)
> > >   return (rv & 0xff);
> > >   }
> > >  
> > > - /*
> > > -  * Wait for a character to actually become available.  Appears to
> > > -  * be necessary on (at least) the Intel Mac Mini.
> > > -  */
> > > - do {
> > > - __asm volatile(DOINT(0x16) "; setnz %b0" : "=a" (rv) :
> > > - "0" (0x100) : "%ecx", "%edx", "cc" );
> > > - } while ((rv & 0xff) == 0);
> > > + if ((cpu_ecxfeature & CPUIDECX_HV) == 0) {
> > > + /*
> > > + * Wait for a character to actually become available.
> > > + * Appears to be necessary on (at least) the Intel Mac
> > > + * Mini.
> > > +  */
> > > + do {
> > > + __asm volatile(DOINT(0x16) "; setnz %b0" : "=a" (rv) :
> > > + "0" (0x100) : "%ecx", "%edx", "cc" );
> > > + } while ((rv & 0xff) == 0);
> > > + }
> > >  
> > >   __asm volatile(DOINT(0x16) : "=a" (rv) : "0" (0x000) :
> > >   "%ecx", "%edx", "cc" );
> > > diff --git a/sys/arch/i386/stand/libsa/bioscons.c 
> > > b/sys/arch/i386/stand/libsa/bioscons.c
> > > index 028bef3..b53abcf 100644
> > > --- a/sys/arch/i386/stand/libsa/bioscons.c
> > > +++ b/sys/arch/i386/stand/libsa/bioscons.c
> > > @@ -27,15 +27,20 @@
> > >   */
> > >  
> > >  #include 
> > > +
> > >  #include 
> > >  #include 
> > > +#include 
> > > +
> > >  #include 
> > >  #include 
> > >  #include 
> > >  #include 
> > >  /* #include  */
> > >  #include 
> > > -#include 
> > > +
> > > +#include 
> > > +
> > >  #include "debug.h"
> > >  #include "biosdev.h"
> > >  
> > > @@ -80,14 +85,17 @@ pc_getc(dev_t dev)
> > >   return (rv & 0xff);
> > >   }
> > >  
> > > - /*
> > > -  * Wait for a character to actually become available.  Appears to
> > > -  * be necessary on (at least) the Intel Mac Mini.
> > > -  */
> > > - do {
> > > - __asm volatile(DOINT(0x16) "; setnz %b0" : "=a" (rv) :
> > > - "0" (0x100) : "%ecx", "%edx", "cc" );
> > > - } while ((rv & 0xff) == 0);
> > > + if ((cpu_ecxfeature & CPUIDECX_HV) == 0) {
> > > + /*
> > > + * Wait for a character to actually become available.
> > > + * Appears to be necessary on (at least) the Intel Mac
> > > + * Mini.
> > > +  */
> > > + do {
> > > + __asm volatile(DOINT(0x16) "; setnz %b0" : "=a" (rv) :
> > > + "0" (0x100) : "%ecx", "%edx", "cc" );
> > > + } while ((rv & 0xff) == 0);
> > > + }
> > >  
> > >   __asm volatile(DOINT(0x16) : "=a" (rv) : "0" (0x000) :
> > >   "%ecx", "%edx", "cc" );
> > > 
> > > On Thu, Mar 17, 2016 at 02:58:58PM +0900, Masao Uebayashi wrote:
> > > > Factor out CPUID code in mdrandom(), invoke it once, then save the
> > > > result.  I'll use it to switch behavior depending on HV or not.
> > > > 
> > > > efiboot is not tested.
> > > > 
> > > > Comments?
> > > 
> > > > >From 104cb04bbbd0f7e40758938cc3103b2370a2285c Mon Sep 17 00:00:00 2001
> > > > From: Masao Uebayashi 
> > > > Date: Thu, 10 Mar 2016 21:03:07 +0900
> > > > Subject: [PATCH 1/3] Factor out CPUID instruction in amd64 boot code
> > > > 
> > > > ---
> > > >  sys/arch/amd64/stand/boot/Makefile   |  1 +
> > > >  sys/arch/amd64/stand/boot/srt0.S |  1 +
> > > >  sys/arch/amd64/stand/cdboot/Makefile |  1 +
> > > >  sys/arch/amd64/stand/cdboot/srt0.S   |  2 +
> > > >  sys/arch/amd64/stand/libsa/cpuid.S   | 69 
> > > > 

Re: Implement delay() using TSC

[Masao Uebayashi]

On Wed, Mar 16, 2016 at 11:49:32PM -0700, Mike Larkin wrote:
> On Thu, Mar 17, 2016 at 03:38:20PM +0900, Masao Uebayashi wrote:
> > On Wed, Mar 16, 2016 at 11:25:11PM -0700, Mike Larkin wrote:
> > > On Thu, Mar 17, 2016 at 09:44:22AM +0900, Masao Uebayashi wrote:
> > > > Implement delay() using TSC
> > > > 
> > > > - Calculate delay using 64-bit RDTSC instruction
> > > > - Enable tsc_delay() as delay(9) backend
> > > > - Use tsc_delay() only when TSC is invariant
> > > > - Configure tsc_delay() after primary CPU is identified
> > > > - Assume all CPUs are identical
> > > 
> > > Why is this needed, or wanted? There is no explanation given above
> > > aside from "let's make things different". Are you claiming that
> > > delay(9) is somehow inaccurate or incorrect without this?
> > 
> > I think LAPIC delay() is just fine.  Accuracy is not a problem for me.
> > 
> > In the long run, I want to use LAPIC for per-CPU one-shot timer.  This
> > will come later ... but it'd be nice for me to know if using TSC for
> > delay() is not a problem.
> > 
> 
> So are you asking people to just test this to see if there are side
> effects (in order to switch to this "in the long run"), or are you
> asking for oks?
> 
> The way the diff is written, it looks like if it were committed, it
> would force every machine to use TSC. Is that what you want?

I don't need this to be committed & enabled for everyone right now, but
tests and feedbacks are really appreciated.

(Unfortunately using TSC for delay() itself has nothing visible or
beneficial for users.)

> -ml
> 
> > > -ml
> > > 
> > > > 
> > > > diff --git a/sys/arch/amd64/amd64/cpu.c b/sys/arch/amd64/amd64/cpu.c
> > > > index df6c623..0863306 100644
> > > > --- a/sys/arch/amd64/amd64/cpu.c
> > > > +++ b/sys/arch/amd64/amd64/cpu.c
> > > > @@ -330,6 +330,7 @@ cpu_attach(struct device *parent, struct device 
> > > > *self, void *aux)
> > > > vaddr_t kstack;
> > > > struct pcb *pcb;
> > > >  #endif
> > > > +   void tsc_delay_init(struct cpu_info *);
> > > >  
> > > > /*
> > > >  * If we're an Application Processor, allocate a cpu_info
> > > > @@ -409,6 +410,7 @@ cpu_attach(struct device *parent, struct device 
> > > > *self, void *aux)
> > > >  #endif /* MTRR */
> > > > cpu_init(ci);
> > > > cpu_init_mwait(sc);
> > > > +   tsc_delay_init(ci);
> > > > break;
> > > >  
> > > > case CPU_ROLE_BP:
> > > > @@ -432,6 +434,7 @@ cpu_attach(struct device *parent, struct device 
> > > > *self, void *aux)
> > > > ioapic_bsp_id = caa->cpu_number;
> > > >  #endif
> > > > cpu_init_mwait(sc);
> > > > +   tsc_delay_init(ci);
> > > > break;
> > > >  
> > > > case CPU_ROLE_AP:
> > > > diff --git a/sys/arch/amd64/amd64/tsc.c b/sys/arch/amd64/amd64/tsc.c
> > > > new file mode 100644
> > > > index 000..15242ca
> > > > --- /dev/null
> > > > +++ b/sys/arch/amd64/amd64/tsc.c
> > > > @@ -0,0 +1,68 @@
> > > > +/*
> > > > + * Copyright (c) 2016 Masao Uebayashi 
> > > > + *
> > > > + * Permission to use, copy, modify, and distribute this software for 
> > > > any
> > > > + * purpose with or without fee is hereby granted, provided that the 
> > > > above
> > > > + * copyright notice and this permission notice appear in all copies.
> > > > + *
> > > > + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL 
> > > > WARRANTIES
> > > > + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> > > > + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE 
> > > > FOR
> > > > + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY 
> > > > DAMAGES
> > > > + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN 
> > > > AN
> > > > + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING 
> > > > OUT OF
> > > > + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> > > > + */
> > > > +
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +
> > > > +#include 
> > > > +#include 
> > > > +
> > > > +void tsc_delay_init(struct cpu_info *);
> > > > +void tsc_delay(int);
> > > > +uint64_t tsc2usec(uint64_t n);
> > > > +
> > > > +int64_t tsc_delay_mult;
> > > > +
> > > > +void
> > > > +tsc_delay_init(struct cpu_info *ci)
> > > > +{
> > > > +#ifdef DIAGNOSTIC
> > > > +   KASSERT(ci->ci_tsc_freq != 0);
> > > > +#endif
> > > > +   if ((ci->ci_flags & CPUF_CONST_TSC) == 0)
> > > > +   return;
> > > > +
> > > > +   tsc_delay_mult = ci->ci_tsc_freq / 100;
> > > > +   delay_func = tsc_delay;
> > > > +}
> > > > +
> > > > +void
> > > > +tsc_delay(int usec)
> > > > +{
> > > > +   int64_t n;
> > > > +   uint64_t now, prev;
> > > > +
> > > > +   n = tsc_delay_mult * usec;
> > > > +   prev = rdtsc();
> > > > +   while (n > 0) {
> > > > +   CPU_BUSY_CYCLE();
> > > > +   

Implement delay() using TSC

[Masao Uebayashi]

Implement delay() using TSC

- Calculate delay using 64-bit RDTSC instruction
- Enable tsc_delay() as delay(9) backend
- Use tsc_delay() only when TSC is invariant
- Configure tsc_delay() after primary CPU is identified
- Assume all CPUs are identical

diff --git a/sys/arch/amd64/amd64/cpu.c b/sys/arch/amd64/amd64/cpu.c
index df6c623..0863306 100644
--- a/sys/arch/amd64/amd64/cpu.c
+++ b/sys/arch/amd64/amd64/cpu.c
@@ -330,6 +330,7 @@ cpu_attach(struct device *parent, struct device *self, void 
*aux)
vaddr_t kstack;
struct pcb *pcb;
 #endif
+   void tsc_delay_init(struct cpu_info *);
 
/*
 * If we're an Application Processor, allocate a cpu_info
@@ -409,6 +410,7 @@ cpu_attach(struct device *parent, struct device *self, void 
*aux)
 #endif /* MTRR */
cpu_init(ci);
cpu_init_mwait(sc);
+   tsc_delay_init(ci);
break;
 
case CPU_ROLE_BP:
@@ -432,6 +434,7 @@ cpu_attach(struct device *parent, struct device *self, void 
*aux)
ioapic_bsp_id = caa->cpu_number;
 #endif
cpu_init_mwait(sc);
+   tsc_delay_init(ci);
break;
 
case CPU_ROLE_AP:
diff --git a/sys/arch/amd64/amd64/tsc.c b/sys/arch/amd64/amd64/tsc.c
new file mode 100644
index 000..15242ca
--- /dev/null
+++ b/sys/arch/amd64/amd64/tsc.c
@@ -0,0 +1,68 @@
+/*
+ * Copyright (c) 2016 Masao Uebayashi 
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+void tsc_delay_init(struct cpu_info *);
+void tsc_delay(int);
+uint64_t tsc2usec(uint64_t n);
+
+int64_t tsc_delay_mult;
+
+void
+tsc_delay_init(struct cpu_info *ci)
+{
+#ifdef DIAGNOSTIC
+   KASSERT(ci->ci_tsc_freq != 0);
+#endif
+   if ((ci->ci_flags & CPUF_CONST_TSC) == 0)
+   return;
+
+   tsc_delay_mult = ci->ci_tsc_freq / 100;
+   delay_func = tsc_delay;
+}
+
+void
+tsc_delay(int usec)
+{
+   int64_t n;
+   uint64_t now, prev;
+
+   n = tsc_delay_mult * usec;
+   prev = rdtsc();
+   while (n > 0) {
+   CPU_BUSY_CYCLE();
+   now = rdtsc();
+   if (now < prev)
+   n -= UINT64_MAX - (prev - now);
+   else
+   n -= now - prev;
+   prev = now;
+   }
+}
+
+uint64_t
+tsc2usec(uint64_t n)
+{
+   struct cpu_info *ci = curcpu();
+
+   return n / ci->ci_tsc_freq * 100;
+}
diff --git a/sys/arch/amd64/conf/files.amd64 b/sys/arch/amd64/conf/files.amd64
index 5d58b34..d101cf2 100644
--- a/sys/arch/amd64/conf/files.amd64
+++ b/sys/arch/amd64/conf/files.amd64
@@ -97,6 +97,7 @@ definecpu {[apid = -1]}
 device cpu
 attach cpu at mainbus
 file   arch/amd64/amd64/cpu.c  cpu
+file   arch/amd64/amd64/tsc.c  cpu
 
 
 define lapic

axen improvements

[Brandon Mercer]

I've recently acquired a usb3.0->gigabit ethernet adapter. It did not
attach reliably, pass traffic reliably, and it made my machine panic
when I unplugged it. Takahiro HAYASHI suggested that the reset
code doesn't do anything and that it should initialize the chip. Indeed
that does seem to help. I also adopted a change that netbsd made to
lock the mii before trying to write to it during initialization. 

It appears that the eeprom code is going to be left to rot, so I deleted
that as well. I've only been able to test this on my device. Feedback is
welcomed. 

Index: dev/usb/if_axen.c
===
RCS file: /home/bmercer/cvs/src/sys/dev/usb/if_axen.c,v
retrieving revision 1.20
diff -u -p -u -p -r1.20 if_axen.c
--- dev/usb/if_axen.c   25 Nov 2015 03:10:00 -  1.20
+++ dev/usb/if_axen.c   19 Mar 2016 20:31:13 -
@@ -115,10 +115,6 @@ intaxen_cmd(struct axen_softc *, int, i
 intaxen_ifmedia_upd(struct ifnet *);
 void   axen_ifmedia_sts(struct ifnet *, struct ifmediareq *);
 void   axen_reset(struct axen_softc *sc);
-#if 0 /* not used */
-intaxen_ax88179_eeprom(struct axen_softc *, void *);
-#endif
-
 void   axen_iff(struct axen_softc *);
 void   axen_lock_mii(struct axen_softc *sc);
 void   axen_unlock_mii(struct axen_softc *sc);
@@ -399,69 +395,13 @@ axen_reset(struct axen_softc *sc)
if (usbd_is_dying(sc->axen_udev))
return;
/* XXX What to reset? */
+   axen_ax88179_init(sc);
 
/* Wait a little while for the chip to get its brains in order. */
DELAY(1000);
return;
 }
 
-#if 0 /* not used */
-#define AXEN_GPIO_WRITE(x,y) do {\
-   axen_cmd(sc, AXEN_CMD_WRITE_GPIO, 0, (x), NULL);  \
-   usbd_delay_ms(sc->axen_udev, (y));  \
-} while (0)
-
-int
-axen_ax88179_eeprom(struct axen_softc *sc, void *addr)
-{
-   int i, retry;
-   uWord   buf;
-   uint8_t eeprom[20];
-   uint16_tcsum;
-
-   for (i = 0; i < 6; i++) {
-   /* set eeprom address */
-   USETW(buf, i);
-   axen_cmd(sc, AXEN_CMD_MAC_WRITE, 1, AXEN_MAC_EEPROM_ADDR, buf);
-
-   /* set eeprom command */
-   USETW(buf, AXEN_EEPROM_READ);
-   axen_cmd(sc, AXEN_CMD_MAC_WRITE, 1, AXEN_MAC_EEPROM_CMD, buf);
-
-   /* check the value is ready */
-   retry = 3;
-   do {
-   USETW(buf, AXEN_EEPROM_READ);
-   usbd_delay_ms(sc->axen_udev, 10);
-   axen_cmd(sc, AXEN_CMD_MAC_READ, 1, AXEN_MAC_EEPROM_CMD,
-   buf);
-   retry--;
-   if (retry < 0)
-   return EINVAL;
-   } while ((UGETW(buf) & 0xff) & AXEN_EEPROM_BUSY);
-
-   /* read data */
-   axen_cmd(sc, AXEN_CMD_MAC_READ2, 2, AXEN_EEPROM_READ, 
-   [i * 2]);
-
-   /* sanity check */
-   if ((i == 0) && (eeprom[0] == 0xff))
-   return EINVAL;
-   }
-
-   /* check checksum */
-   csum = eeprom[6] + eeprom[7] + eeprom[8] + eeprom[9];
-   csum = (csum >> 8) + (csum & 0xff) + eeprom[10];
-   if (csum != 0xff) {
-   printf("eeprom checksum mismatchi(0x%02x)\n", csum);
-   return EINVAL;
-   }
-
-   memcpy(addr, eeprom, ETHER_ADDR_LEN);
-   return 0;
-}
-#endif
-
 void
 axen_ax88179_init(struct axen_softc *sc)
 {
@@ -720,16 +660,10 @@ axen_attach(struct device *parent, struc
/*
 * Get station address.
 */
-#if 0 /* read from eeprom */
-   if (axen_ax88179_eeprom(sc, )) {
-   printf("EEPROM checksum error\n");
-   return;
-   }
-#else /* use MAC command */
+   /* use MAC command */
axen_lock_mii(sc);
axen_cmd(sc, AXEN_CMD_MAC_READ_ETHER, 6, AXEN_CMD_MAC_NODE_ID, );
axen_unlock_mii(sc);
-#endif
 
axen_ax88179_init(sc);
 
@@ -1321,7 +1255,9 @@ axen_init(void *xsc)
 
/* XXX: ? */
bval = 0x01;
+   axen_lock_mii(sc);
axen_cmd(sc, AXEN_CMD_MAC_WRITE, 1, AXEN_UNK_28, );
+   axen_unlock_mii(sc);
 
/* Init RX ring. */
if (axen_rx_list_init(sc) == ENOBUFS) {

Re: Implement delay() using TSC

[Mike Larkin]

On Thu, Mar 17, 2016 at 03:38:20PM +0900, Masao Uebayashi wrote:
> On Wed, Mar 16, 2016 at 11:25:11PM -0700, Mike Larkin wrote:
> > On Thu, Mar 17, 2016 at 09:44:22AM +0900, Masao Uebayashi wrote:
> > > Implement delay() using TSC
> > > 
> > > - Calculate delay using 64-bit RDTSC instruction
> > > - Enable tsc_delay() as delay(9) backend
> > > - Use tsc_delay() only when TSC is invariant
> > > - Configure tsc_delay() after primary CPU is identified
> > > - Assume all CPUs are identical
> > 
> > Why is this needed, or wanted? There is no explanation given above
> > aside from "let's make things different". Are you claiming that
> > delay(9) is somehow inaccurate or incorrect without this?
> 
> I think LAPIC delay() is just fine.  Accuracy is not a problem for me.
> 
> In the long run, I want to use LAPIC for per-CPU one-shot timer.  This
> will come later ... but it'd be nice for me to know if using TSC for
> delay() is not a problem.
> 

So are you asking people to just test this to see if there are side
effects (in order to switch to this "in the long run"), or are you
asking for oks?

The way the diff is written, it looks like if it were committed, it
would force every machine to use TSC. Is that what you want?

-ml

> > -ml
> > 
> > > 
> > > diff --git a/sys/arch/amd64/amd64/cpu.c b/sys/arch/amd64/amd64/cpu.c
> > > index df6c623..0863306 100644
> > > --- a/sys/arch/amd64/amd64/cpu.c
> > > +++ b/sys/arch/amd64/amd64/cpu.c
> > > @@ -330,6 +330,7 @@ cpu_attach(struct device *parent, struct device 
> > > *self, void *aux)
> > >   vaddr_t kstack;
> > >   struct pcb *pcb;
> > >  #endif
> > > + void tsc_delay_init(struct cpu_info *);
> > >  
> > >   /*
> > >* If we're an Application Processor, allocate a cpu_info
> > > @@ -409,6 +410,7 @@ cpu_attach(struct device *parent, struct device 
> > > *self, void *aux)
> > >  #endif /* MTRR */
> > >   cpu_init(ci);
> > >   cpu_init_mwait(sc);
> > > + tsc_delay_init(ci);
> > >   break;
> > >  
> > >   case CPU_ROLE_BP:
> > > @@ -432,6 +434,7 @@ cpu_attach(struct device *parent, struct device 
> > > *self, void *aux)
> > >   ioapic_bsp_id = caa->cpu_number;
> > >  #endif
> > >   cpu_init_mwait(sc);
> > > + tsc_delay_init(ci);
> > >   break;
> > >  
> > >   case CPU_ROLE_AP:
> > > diff --git a/sys/arch/amd64/amd64/tsc.c b/sys/arch/amd64/amd64/tsc.c
> > > new file mode 100644
> > > index 000..15242ca
> > > --- /dev/null
> > > +++ b/sys/arch/amd64/amd64/tsc.c
> > > @@ -0,0 +1,68 @@
> > > +/*
> > > + * Copyright (c) 2016 Masao Uebayashi 
> > > + *
> > > + * Permission to use, copy, modify, and distribute this software for any
> > > + * purpose with or without fee is hereby granted, provided that the above
> > > + * copyright notice and this permission notice appear in all copies.
> > > + *
> > > + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL 
> > > WARRANTIES
> > > + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> > > + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE 
> > > FOR
> > > + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> > > + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> > > + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT 
> > > OF
> > > + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +#include 
> > > +#include 
> > > +
> > > +void tsc_delay_init(struct cpu_info *);
> > > +void tsc_delay(int);
> > > +uint64_t tsc2usec(uint64_t n);
> > > +
> > > +int64_t tsc_delay_mult;
> > > +
> > > +void
> > > +tsc_delay_init(struct cpu_info *ci)
> > > +{
> > > +#ifdef DIAGNOSTIC
> > > + KASSERT(ci->ci_tsc_freq != 0);
> > > +#endif
> > > + if ((ci->ci_flags & CPUF_CONST_TSC) == 0)
> > > + return;
> > > +
> > > + tsc_delay_mult = ci->ci_tsc_freq / 100;
> > > + delay_func = tsc_delay;
> > > +}
> > > +
> > > +void
> > > +tsc_delay(int usec)
> > > +{
> > > + int64_t n;
> > > + uint64_t now, prev;
> > > +
> > > + n = tsc_delay_mult * usec;
> > > + prev = rdtsc();
> > > + while (n > 0) {
> > > + CPU_BUSY_CYCLE();
> > > + now = rdtsc();
> > > + if (now < prev)
> > > + n -= UINT64_MAX - (prev - now);
> > > + else
> > > + n -= now - prev;
> > > + prev = now;
> > > + }
> > > +}
> > > +
> > > +uint64_t
> > > +tsc2usec(uint64_t n)
> > > +{
> > > + struct cpu_info *ci = curcpu();
> > > +
> > > + return n / ci->ci_tsc_freq * 100;
> > > +}
> > > diff --git a/sys/arch/amd64/conf/files.amd64 
> > > b/sys/arch/amd64/conf/files.amd64
> > > index 5d58b34..d101cf2 100644
> > > --- a/sys/arch/amd64/conf/files.amd64
> > > +++ b/sys/arch/amd64/conf/files.amd64
> > > @@ -97,6 +97,7 @@ define  cpu {[apid = -1]}
> > >  device   cpu
> > >  attach   cpu at mainbus
> > >  file 

Re: Scheduler hack for multi-threaded processes

[Christian Schulte]

s/approves/improves/g

Rename the global variable ``ticks''

[Martin Pieuchot]

``ticks'' is in my opinion a really badly named global variable.  But we
all know that finding names is hard ;)

Since its popularity seems to be really high lately, I'd suggest to
rename it.  I chose ``hcticks'' for "hardclock ticks".  I believe this
would help auditing the possible existing and/or future conditions
leading to overflow.

As a bonus this diff removes all the "extern hcticks;" declaration and
include  instead.

Opinions?

PS: I missed 4 conversions in my previous diff, can you find them?

diff --git sys/dev/atapiscsi/atapiscsi.c sys/dev/atapiscsi/atapiscsi.c
index df5c45b..be164ea 100644
--- sys/dev/atapiscsi/atapiscsi.c
+++ sys/dev/atapiscsi/atapiscsi.c
@@ -613,7 +613,6 @@ wdc_atapi_the_machine(struct channel_softc *chp, struct 
wdc_xfer *xfer,
 enum atapi_context ctxt)
 {
int idx = 0;
-   extern int ticks;
int timeout_delay = hz / 10;
 
if (xfer->c_flags & C_POLL) {
@@ -637,7 +636,7 @@ wdc_atapi_the_machine(struct channel_softc *chp, struct 
wdc_xfer *xfer,
struct atapi_return_args retargs = ARGS_INIT;
 
(xfer->next)(chp, xfer,
-   xfer->endticks && (ticks - xfer->endticks >= 0),
+   xfer->endticks && (hcticks - xfer->endticks >= 0),
);
 
if (retargs.timeout != -1)
@@ -646,7 +645,7 @@ wdc_atapi_the_machine(struct channel_softc *chp, struct 
wdc_xfer *xfer,
 * can be just microseconds before the tick changes.
 */
xfer->endticks =
-   max((retargs.timeout * hz) / 1000, 1) + 1 + ticks;
+   max((retargs.timeout * hz) / 1000, 1) + 1 + hcticks;
 
if (xfer->next == NULL) {
if (xfer->c_flags & C_POLL_MACHINE)
@@ -661,7 +660,7 @@ wdc_atapi_the_machine(struct channel_softc *chp, struct 
wdc_xfer *xfer,
if (retargs.expect_irq) {
int timeout_period;
chp->ch_flags |= WDCF_IRQ_WAIT;
-   timeout_period =  xfer->endticks - ticks;
+   timeout_period =  xfer->endticks - hcticks;
if (timeout_period < 1)
timeout_period = 1;
timeout_add(>ch_timo, timeout_period);
diff --git sys/dev/ic/ar5008.c sys/dev/ic/ar5008.c
index d3ad6c9..fa1c1e9 100644
--- sys/dev/ic/ar5008.c
+++ sys/dev/ic/ar5008.c
@@ -2381,8 +2381,7 @@ ar5008_hw_init(struct athn_softc *sc, struct 
ieee80211_channel *c,
ar5008_init_chains(sc);
 
if (sc->flags & ATHN_FLAG_OLPC) {
-   extern int ticks;
-   sc->olpc_ticks = ticks;
+   sc->olpc_ticks = hcticks;
ops->olpc_init(sc);
}
 
diff --git sys/dev/ic/athn.c sys/dev/ic/athn.c
index 03460ef..df2b9b1 100644
--- sys/dev/ic/athn.c
+++ sys/dev/ic/athn.c
@@ -1218,7 +1218,6 @@ athn_iter_func(void *arg, struct ieee80211_node *ni)
 void
 athn_calib_to(void *arg)
 {
-   extern int ticks;
struct athn_softc *sc = arg;
struct athn_ops *ops = >ops;
struct ieee80211com *ic = >sc_ic;
@@ -1229,8 +1228,8 @@ athn_calib_to(void *arg)
/* Do periodic (every 4 minutes) PA calibration. */
if (AR_SREV_9285_11_OR_LATER(sc) &&
!AR_SREV_9380_10_OR_LATER(sc) &&
-   (ticks - (sc->pa_calib_ticks + 240 * hz)) >= 0) {
-   sc->pa_calib_ticks = ticks;
+   (hcticks - (sc->pa_calib_ticks + 240 * hz)) >= 0) {
+   sc->pa_calib_ticks = hcticks;
if (AR_SREV_9271(sc))
ar9271_pa_calib(sc);
else
@@ -1239,8 +1238,8 @@ athn_calib_to(void *arg)
 
/* Do periodic (every 30 seconds) temperature compensation. */
if ((sc->flags & ATHN_FLAG_OLPC) &&
-   ticks >= sc->olpc_ticks + 30 * hz) {
-   sc->olpc_ticks = ticks;
+   hcticks >= sc->olpc_ticks + 30 * hz) {
+   sc->olpc_ticks = hcticks;
ops->olpc_temp_compensation(sc);
}
 
@@ -1279,8 +1278,7 @@ athn_init_calib(struct athn_softc *sc, struct 
ieee80211_channel *c,
if (!AR_SREV_9380_10_OR_LATER(sc)) {
/* Do PA calibration. */
if (AR_SREV_9285_11_OR_LATER(sc)) {
-   extern int ticks;
-   sc->pa_calib_ticks = ticks;
+   sc->pa_calib_ticks = hcticks;
if (AR_SREV_9271(sc))
ar9271_pa_calib(sc);
else
diff --git sys/dev/ic/bwi.c sys/dev/ic/bwi.c
index d612db3..7514e29 100644
--- sys/dev/ic/bwi.c
+++ sys/dev/ic/bwi.c
@@ -97,8 +97,6 @@ int bwi_debug = 1;
 
 #define __unused __attribute__((__unused__))
 
-extern int ticks;
-
 /* XXX end porting goop */
 
 /* MAC */
@@ -6509,11 +6507,11 @@ bwi_led_event(struct bwi_softc *sc, int event)
if (event == 

Re: Implement delay() using TSC

[Mike Larkin]

On Thu, Mar 17, 2016 at 04:03:25PM +0900, Masao Uebayashi wrote:
> On Wed, Mar 16, 2016 at 11:49:32PM -0700, Mike Larkin wrote:
> > On Thu, Mar 17, 2016 at 03:38:20PM +0900, Masao Uebayashi wrote:
> > > On Wed, Mar 16, 2016 at 11:25:11PM -0700, Mike Larkin wrote:
> > > > On Thu, Mar 17, 2016 at 09:44:22AM +0900, Masao Uebayashi wrote:
> > > > > Implement delay() using TSC
> > > > > 
> > > > > - Calculate delay using 64-bit RDTSC instruction
> > > > > - Enable tsc_delay() as delay(9) backend
> > > > > - Use tsc_delay() only when TSC is invariant
> > > > > - Configure tsc_delay() after primary CPU is identified
> > > > > - Assume all CPUs are identical
> > > > 
> > > > Why is this needed, or wanted? There is no explanation given above
> > > > aside from "let's make things different". Are you claiming that
> > > > delay(9) is somehow inaccurate or incorrect without this?
> > > 
> > > I think LAPIC delay() is just fine.  Accuracy is not a problem for me.
> > > 
> > > In the long run, I want to use LAPIC for per-CPU one-shot timer.  This
> > > will come later ... but it'd be nice for me to know if using TSC for
> > > delay() is not a problem.
> > > 
> > 
> > So are you asking people to just test this to see if there are side
> > effects (in order to switch to this "in the long run"), or are you
> > asking for oks?
> > 
> > The way the diff is written, it looks like if it were committed, it
> > would force every machine to use TSC. Is that what you want?
> 
> I don't need this to be committed & enabled for everyone right now, but
> tests and feedbacks are really appreciated.

I'll put it on a few machines and let you know.

-ml

> 
> (Unfortunately using TSC for delay() itself has nothing visible or
> beneficial for users.)
> 
> > -ml
> > 
> > > > -ml
> > > > 
> > > > > 
> > > > > diff --git a/sys/arch/amd64/amd64/cpu.c b/sys/arch/amd64/amd64/cpu.c
> > > > > index df6c623..0863306 100644
> > > > > --- a/sys/arch/amd64/amd64/cpu.c
> > > > > +++ b/sys/arch/amd64/amd64/cpu.c
> > > > > @@ -330,6 +330,7 @@ cpu_attach(struct device *parent, struct device 
> > > > > *self, void *aux)
> > > > >   vaddr_t kstack;
> > > > >   struct pcb *pcb;
> > > > >  #endif
> > > > > + void tsc_delay_init(struct cpu_info *);
> > > > >  
> > > > >   /*
> > > > >* If we're an Application Processor, allocate a cpu_info
> > > > > @@ -409,6 +410,7 @@ cpu_attach(struct device *parent, struct device 
> > > > > *self, void *aux)
> > > > >  #endif /* MTRR */
> > > > >   cpu_init(ci);
> > > > >   cpu_init_mwait(sc);
> > > > > + tsc_delay_init(ci);
> > > > >   break;
> > > > >  
> > > > >   case CPU_ROLE_BP:
> > > > > @@ -432,6 +434,7 @@ cpu_attach(struct device *parent, struct device 
> > > > > *self, void *aux)
> > > > >   ioapic_bsp_id = caa->cpu_number;
> > > > >  #endif
> > > > >   cpu_init_mwait(sc);
> > > > > + tsc_delay_init(ci);
> > > > >   break;
> > > > >  
> > > > >   case CPU_ROLE_AP:
> > > > > diff --git a/sys/arch/amd64/amd64/tsc.c b/sys/arch/amd64/amd64/tsc.c
> > > > > new file mode 100644
> > > > > index 000..15242ca
> > > > > --- /dev/null
> > > > > +++ b/sys/arch/amd64/amd64/tsc.c
> > > > > @@ -0,0 +1,68 @@
> > > > > +/*
> > > > > + * Copyright (c) 2016 Masao Uebayashi 
> > > > > + *
> > > > > + * Permission to use, copy, modify, and distribute this software for 
> > > > > any
> > > > > + * purpose with or without fee is hereby granted, provided that the 
> > > > > above
> > > > > + * copyright notice and this permission notice appear in all copies.
> > > > > + *
> > > > > + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL 
> > > > > WARRANTIES
> > > > > + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> > > > > + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE 
> > > > > LIABLE FOR
> > > > > + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY 
> > > > > DAMAGES
> > > > > + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER 
> > > > > IN AN
> > > > > + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING 
> > > > > OUT OF
> > > > > + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> > > > > + */
> > > > > +
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +
> > > > > +#include 
> > > > > +#include 
> > > > > +
> > > > > +void tsc_delay_init(struct cpu_info *);
> > > > > +void tsc_delay(int);
> > > > > +uint64_t tsc2usec(uint64_t n);
> > > > > +
> > > > > +int64_t tsc_delay_mult;
> > > > > +
> > > > > +void
> > > > > +tsc_delay_init(struct cpu_info *ci)
> > > > > +{
> > > > > +#ifdef DIAGNOSTIC
> > > > > + KASSERT(ci->ci_tsc_freq != 0);
> > > > > +#endif
> > > > > + if ((ci->ci_flags & CPUF_CONST_TSC) == 0)
> > > > > + return;
> > > > > +
> > > > > + tsc_delay_mult = ci->ci_tsc_freq / 100;
> > > > > + delay_func 

Re: New scheduler for OpenBSD

[Chris Cappuccio]

Michal Mazurek [akf...@jasminek.net] wrote:
> On 16:28:33, 14.03.16, Martin Pieuchot wrote:
> > > The number of calls to yield() dropped to 4,576.
> > 
> > This is really similar to what I observed with Firefox and Chrome.
> > 
> > > This is where I get stuck, I don't know how to replace the call to
> > > sched_yield(), or whether it is a good idea to do so. Any advice?
> > 
> > I'd assume the problem is not in the _spinlock() implementation itself
> > but rather on the code calling this lock.  Do you know which code is
> > triggering this?
> > 
> > See r1.13 of lib/librthread/rthread_libc.c, this is an example where a
> > the use of a spinlock created similar symptoms.
> 
> I don't know how to fix it, but in the meanwhile here is a workaround so
> I can continue working on the scheduler. In yield():
> 
> + tmp = p->p_rrticks;
> + sched_deadline(p);
> + p->p_rrticks = tmp;
> 
> So penalise a process calling yield() by giving it the worst deadline,
> i.e. make it go to the end of the run queue.
> 
> Other than this, no changes.
> 
> Chrome still isn't smooth.
> 

On a frankenstein 5.9 kernel with bob beck's latest NOWAIT vfs_biomem buffer 
alloc and this, I'm getting very smooth action on chrome, with video, even on
an old x201. I don't remember the last time it could re-open 20 tabs without
constantly pausing most of itself, or the last time youtube videos would
play on this laptop in chrome, without random and frequenty stuttering.

Octeon II usb

[Jonathan Matthew]

I've had this sitting around for a while and I figure it's time to get it in
the tree.  Octeon II sensibly got rid of the DWC USB controller and put in ehci
and ohci compliant controllers instead, so all we need to do here is set up a
few registers in the usb controller interface and attach the standard drivers.
The diff below adds octuctl, a driver for the usb controller interface, and 
octehci and octohci, which are attachments for ehci and ohci.

I've tested this on a Lanner MR326b, where it allows me to boot off a usb
stick, and on an Edgerouter Lite, where it makes no difference at all.

ok?

Index: conf/GENERIC
===
RCS file: /cvs/src/sys/arch/octeon/conf/GENERIC,v
retrieving revision 1.24
diff -u -p -u -p -r1.24 GENERIC
--- conf/GENERIC14 Jan 2016 17:20:34 -  1.24
+++ conf/GENERIC17 Mar 2016 01:43:51 -
@@ -64,9 +64,14 @@ wd*  at pciide? flags 0x
 
 # USB Controllers
 dwctwo0at iobus? irq 56
+octuctl0   at iobus? irq 56
+ehci0  at octuctl?
+ohci0  at octuctl?
 
 # USB bus support
 usb*   at dwctwo?
+usb*   at ehci?
+usb*   at ohci?
 
 # USB devices
 uhub*  at usb? # USB Hubs
Index: conf/RAMDISK
===
RCS file: /cvs/src/sys/arch/octeon/conf/RAMDISK,v
retrieving revision 1.23
diff -u -p -u -p -r1.23 RAMDISK
--- conf/RAMDISK14 Jan 2016 17:20:34 -  1.23
+++ conf/RAMDISK17 Mar 2016 01:43:51 -
@@ -55,7 +55,14 @@ pciide*  at pci? flags 0x
 wd*at pciide? flags 0x
 
 dwctwo0at iobus0 irq 56
+octuctl0   at iobus0 irq 56
+ehci0  at octuctl?
+ohci0  at octuctl?
+
 usb*   at dwctwo?
+usb*   at ehci?
+usb*   at ohci?
+
 uhub*  at usb?
 uhub*  at uhub?
 umass* at uhub?
Index: conf/files.octeon
===
RCS file: /cvs/src/sys/arch/octeon/conf/files.octeon,v
retrieving revision 1.28
diff -u -p -u -p -r1.28 files.octeon
--- conf/files.octeon   14 Jan 2016 17:20:34 -  1.28
+++ conf/files.octeon   17 Mar 2016 01:43:51 -
@@ -71,6 +71,14 @@ file arch/octeon/dev/cn30xxsmi.c iobus
 attach dwctwo at iobus with octdwctwo
 file   arch/octeon/dev/octdwctwo.c octdwctwo   
needs-flag
 
+device octuctl {}
+attach octuctl at iobus
+file   arch/octeon/dev/octuctl.c   octuctl 
needs-flag
+attach ehci at octuctl with octehci
+file   arch/octeon/dev/octehci.c   octehci
+attach ohci at octuctl with octohci
+file   arch/octeon/dev/octohci.c   octohci
+
 # On-board CF
 device octcf: disk
 attach octcf at iobus
Index: dev/octehci.c
===
RCS file: dev/octehci.c
diff -N dev/octehci.c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ dev/octehci.c   17 Mar 2016 01:43:52 -
@@ -0,0 +1,118 @@
+/* $OpenBSD$ */
+
+/*
+ * Copyright (c) 2015 Jonathan Matthew  
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+struct octehci_softc {
+   struct ehci_softc   sc_ehci;
+
+   void*sc_ih;
+};
+
+intoctehci_match(struct device *, void *, void *);
+void   octehci_attach(struct device *, struct device *, void *);
+
+const struct cfattach octehci_ca = {
+   sizeof(struct octehci_softc), octehci_match, octehci_attach,
+};
+
+struct cfdriver octehci_cd = {
+   NULL, "ehci", DV_DULL
+};
+
+int
+octehci_match(struct device *parent, void *match, void *aux)
+{
+   struct octuctl_attach_args *aa = aux;
+
+   if (strcmp(aa->aa_name, "ehci") != 0)
+   return (0);
+
+   return (1);
+}
+
+void
+octehci_attach(struct device *parent, struct device *self, void *aux)
+{
+   struct octehci_softc *sc = (struct octehci_softc *)self;
+   struct octuctl_attach_args *aa = aux;
+   

Re: Scheduler hack for multi-threaded processes

[Christian Schulte]

The java based Netbeans IDE performs a lot of things in the background
using threads like indexing sources, downloading artifacts, unpacking
archives, compiling sources in addition to the normal java background
tasks like JIT compiling. This change approves UI responsiveness on my T60.

Re: stty header cleanup

[Michael McConville]

ok mmcc@

Edgar Pettijohn wrote:
> Index: cchar.c
> ===
> RCS file: /cvs/src/bin/stty/cchar.c,v
> retrieving revision 1.11
> diff -u -p -u -r1.11 cchar.c
> --- cchar.c27 Oct 2009 23:59:22 -1.11
> +++ cchar.c16 Mar 2016 23:53:58 -
> @@ -30,6 +30,7 @@
>   * SUCH DAMAGE.
>   */
> 
> +#include 
>  #include 
> 
>  #include 
> @@ -37,6 +38,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include "stty.h"
>  #include "extern.h"
> Index: gfmt.c
> ===
> RCS file: /cvs/src/bin/stty/gfmt.c,v
> retrieving revision 1.8
> diff -u -p -u -r1.8 gfmt.c
> --- gfmt.c28 Oct 2009 07:12:59 -1.8
> +++ gfmt.c16 Mar 2016 23:54:29 -
> @@ -35,6 +35,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include "stty.h"
>  #include "extern.h"
> Index: key.c
> ===
> RCS file: /cvs/src/bin/stty/key.c,v
> retrieving revision 1.16
> diff -u -p -u -r1.16 key.c
> --- key.c20 Nov 2015 15:57:39 -1.16
> +++ key.c16 Mar 2016 23:55:51 -
> @@ -30,14 +30,16 @@
>   * SUCH DAMAGE.
>   */
> 
> +#include 
>  #include 
> 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
> +#include 
>  #include 
> +#include 
> 
>  #include "stty.h"
>  #include "extern.h"
> Index: modes.c
> ===
> RCS file: /cvs/src/bin/stty/modes.c,v
> retrieving revision 1.10
> diff -u -p -u -r1.10 modes.c
> --- modes.c27 Oct 2009 23:59:22 -1.10
> +++ modes.c16 Mar 2016 23:56:40 -
> @@ -31,8 +31,11 @@
>   */
> 
>  #include 
> +
>  #include 
>  #include 
> +#include 
> +
>  #include "stty.h"
>  #include "extern.h"
> 
> Index: print.c
> ===
> RCS file: /cvs/src/bin/stty/print.c,v
> retrieving revision 1.13
> diff -u -p -u -r1.13 print.c
> --- print.c27 Oct 2009 23:59:22 -1.13
> +++ print.c16 Mar 2016 23:57:24 -
> @@ -35,6 +35,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include "stty.h"
>  #include "extern.h"
> Index: stty.c
> ===
> RCS file: /cvs/src/bin/stty/stty.c,v
> retrieving revision 1.18
> diff -u -p -u -r1.18 stty.c
> --- stty.c20 Nov 2015 15:58:28 -1.18
> +++ stty.c16 Mar 2016 23:58:14 -
> @@ -30,16 +30,18 @@
>   * SUCH DAMAGE.
>   */
> 
> +#include 
>  #include 
> 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> -#include 
>  #include 
> +#include 
>  #include 
> 
>  #include "stty.h"
> Index: stty.h
> ===
> RCS file: /cvs/src/bin/stty/stty.h,v
> retrieving revision 1.4
> diff -u -p -u -r1.4 stty.h
> --- stty.h2 Jun 2003 23:32:09 -1.4
> +++ stty.h16 Mar 2016 23:52:41 -
> @@ -32,9 +32,6 @@
>   *@(#)stty.h8.1 (Berkeley) 5/31/93
>   */
> 
> -#include 
> -#include 
> -
>  struct info {
>  int fd;/* file descriptor */
>  int ldisc;/* line discipline */
> 

Re: Scheduler hack for multi-threaded processes

[Daniel Bolgheroni]

On Sat, Mar 19, 2016 at 01:53:07PM +0100, Martin Pieuchot wrote:
> I experimented with various values for "p_priority" and this one is
> the one that generates fewer # IPIs when watching a HD video on firefox. 
> Because yes, with this diff, now I can.

YouTube on Firefox on ThinkPad T420: It's definitely better than before.
There is still very occasional, very very little image stuttering, but
doesn't break the audio or the flow anymore, which was very annoying.
Full screen works also.

Not related specifically to this patch, because it was happening before,
but: pausing a video does not work. The YouTube loading icon kicks in,
and even if the video returns, it's completely out of sync.

Re: ed header cleanup

[Michael McConville]

ok mmcc@

Edgar Pettijohn wrote:
> Index: buf.c
> ===
> RCS file: /cvs/src/bin/ed/buf.c,v
> retrieving revision 1.22
> diff -u -p -u -r1.22 buf.c
> --- buf.c9 Oct 2015 19:47:02 -1.22
> +++ buf.c16 Mar 2016 23:23:53 -
> @@ -30,6 +30,15 @@
>   */
> 
>  #include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> 
>  #include "ed.h"
> 
> Index: ed.h
> ===
> RCS file: /cvs/src/bin/ed/ed.h,v
> retrieving revision 1.21
> diff -u -p -u -r1.21 ed.h
> --- ed.h9 Oct 2015 21:24:05 -1.21
> +++ ed.h16 Mar 2016 23:11:41 -
> @@ -30,16 +30,6 @@
>   *@(#)ed.h,v 1.5 1994/02/01 00:34:39 alm Exp
>   */
> 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
>  #define ERR(-2)
>  #define EMOD(-3)
>  #define FATAL(-4)
> Index: glbl.c
> ===
> RCS file: /cvs/src/bin/ed/glbl.c,v
> retrieving revision 1.17
> diff -u -p -u -r1.17 glbl.c
> --- glbl.c9 Oct 2015 20:27:28 -1.17
> +++ glbl.c16 Mar 2016 23:26:10 -
> @@ -32,6 +32,12 @@
>  #include 
>  #include 
> 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
>  #include "ed.h"
> 
>  static int set_active_node(line_t *);
> Index: io.c
> ===
> RCS file: /cvs/src/bin/ed/io.c,v
> retrieving revision 1.18
> diff -u -p -u -r1.18 io.c
> --- io.c9 Oct 2015 20:27:28 -1.18
> +++ io.c16 Mar 2016 23:28:09 -
> @@ -28,6 +28,12 @@
>   * SUCH DAMAGE.
>   */
> 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
>  #include "ed.h"
> 
>  static int read_stream(FILE *, int);
> Index: main.c
> ===
> RCS file: /cvs/src/bin/ed/main.c,v
> retrieving revision 1.56
> diff -u -p -u -r1.56 main.c
> --- main.c20 Nov 2015 08:53:28 -1.56
> +++ main.c16 Mar 2016 23:31:16 -
> @@ -44,11 +44,19 @@
>  #include 
>  #include 
>  #include 
> +
>  #include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
>  #include 
> +#include 
> +#include 
> +#include 
> +#include 
>  #include 
> -#include 
> -#include 
> 
>  #include "ed.h"
> 
> Index: re.c
> ===
> RCS file: /cvs/src/bin/ed/re.c,v
> retrieving revision 1.16
> diff -u -p -u -r1.16 re.c
> --- re.c9 Oct 2015 21:24:05 -1.16
> +++ re.c16 Mar 2016 23:34:46 -
> @@ -29,6 +29,12 @@
>   * SUCH DAMAGE.
>   */
> 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
>  #include "ed.h"
> 
>  static char *extract_pattern(int);
> Index: sub.c
> ===
> RCS file: /cvs/src/bin/ed/sub.c,v
> retrieving revision 1.14
> diff -u -p -u -r1.14 sub.c
> --- sub.c9 Oct 2015 20:27:28 -1.14
> +++ sub.c16 Mar 2016 23:36:29 -
> @@ -29,6 +29,13 @@
>   * SUCH DAMAGE.
>   */
> 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
>  #include "ed.h"
> 
>  static char *extract_subst_template(void);
> Index: undo.c
> ===
> RCS file: /cvs/src/bin/ed/undo.c,v
> retrieving revision 1.13
> diff -u -p -u -r1.13 undo.c
> --- undo.c9 Oct 2015 19:47:02 -1.13
> +++ undo.c16 Mar 2016 23:37:46 -
> @@ -28,8 +28,12 @@
>   * SUCH DAMAGE.
>   */
> 
> -#include "ed.h"
> +#include 
> +#include 
> +#include 
> +#include 
> 
> +#include "ed.h"
> 
>  #define USIZE 100/* undo stack size */
>  static undo_t *ustack = NULL;/* undo stack */
> 

IB700 watchdog

[Masao Uebayashi]

This tiny driver is only meant for a backup watchdog configuration on
QEMU, whose ICH watchdog, supported by ichwdt(4), seems broken.

ib700wdt(4) supports only 0-30 second timeouts but in practice it should
be good enough.

diff --git a/sys/arch/amd64/conf/GENERIC b/sys/arch/amd64/conf/GENERIC
index fee3c2a..82e7de0 100644
--- a/sys/arch/amd64/conf/GENERIC
+++ b/sys/arch/amd64/conf/GENERIC
@@ -608,6 +608,7 @@ bktr0   at pci?
 radio* at bktr?
 
 #wdt0  at pci? # Ind Computer Source PCI-WDT50x driver
+#ib700wdt* at isa? port 0x441  # iBase 700 (IB700) Watchdog Timer
 
 # crypto support
 hifn*  at pci? # Hi/fn 7751 crypto card
diff --git a/sys/arch/i386/conf/GENERIC b/sys/arch/i386/conf/GENERIC
index 0984e5b..dbb7df6 100644
--- a/sys/arch/i386/conf/GENERIC
+++ b/sys/arch/i386/conf/GENERIC
@@ -108,6 +108,7 @@ geodesc* at pci?# Geode SC1100/SCx200 IAOC
 wdt0   at pci? # Ind Computer Source PCI-WDT50x driver
 berkwdt0 at pci?   # Berkshire PCI-PC Watchdog driver
 pwdog0 at pci? # Quancom PWDOG1 watchdog timer
+#ib700wdt* at isa? port 0x441  # iBase 700 (IB700) Watchdog Timer
 
 # National Semiconductor LM7[89] and compatible hardware monitors
 lm0at isa? port 0x290
diff --git a/sys/dev/isa/files.isa b/sys/dev/isa/files.isa
index 863d11c..92a9ecc 100644
--- a/sys/dev/isa/files.isa
+++ b/sys/dev/isa/files.isa
@@ -380,3 +380,8 @@ filedev/isa/isagpio.c   isagpio
 #file  dev/isa/pcmcia_pcic.c   pcic | pcicmaster
 
 #file  dev/isa/pcmcia_isa.cpcmcia
+
+# iBase 700 (IB700) Watchdog Timer
+device ib700wdt
+attach ib700wdt at isa
+file   dev/isa/ib700wdt.c  ib700wdt
diff --git a/sys/dev/isa/ib700wdt.c b/sys/dev/isa/ib700wdt.c
new file mode 100644
index 000..cdad79f
--- /dev/null
+++ b/sys/dev/isa/ib700wdt.c
@@ -0,0 +1,142 @@
+/*
+ * Copyright (c) 2016 Masao Uebayashi 
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/*
+ * IB700 USER'S MANUAL
+ * Version 1.0B
+ * p28
+ * Watchdog Timer Configuration
+ */
+
+#defineIB700WDT_BASE   0x441
+#defineIB700WDT_SIZE   3
+#defineIB700WDT_DIS0   /* 0x441 */
+#defineIB700WDT_ENA2   /* 0x443 */
+#defineIB700WDT_SEC_MIN0
+#defineIB700WDT_SEC_MAX30
+
+static inline uint8_t
+ib700wdt_sec2val(int sec)
+{
+   /* 0/1sec = 0xf, 2/3sec = 0xe, ..., 28/29 = 0x1, 30sec = 0x0 */
+   return (0xf - (sec * 0xf / 30));
+}
+
+/*
+ * Driver for iBase 700 Watchdog Timer
+ * Mainly meant for QEMU's "ib700" watchdog device
+ * Can't handle immediate reset (sec=0)
+ */
+
+struct ib700wdt_softc {
+   struct device sc_dev;
+   bus_space_tag_t sc_iot;
+   bus_space_handle_t sc_ioh;
+   int sc_period;
+};
+
+intib700wdt_match(struct device *, void *, void *);
+void   ib700wdt_attach(struct device *, struct device *, void *);
+intib700wdt_activate(struct device *, int);
+
+intib700wdt_cb(void *, int);
+
+struct cfattach ib700wdt_ca = {
+   sizeof(struct ib700wdt_softc),
+   ib700wdt_match, ib700wdt_attach, NULL, ib700wdt_activate
+};
+
+struct cfdriver ib700wdt_cd = {
+   NULL, "ib700wdt", DV_DULL
+};
+
+int
+ib700wdt_match(struct device *parent, void *match, void *aux)
+{
+   struct isa_attach_args *ia = aux;
+
+   ia->ia_iosize = IB700WDT_SIZE;
+   ia->ia_msize = 0;
+
+   return (1);
+}
+
+void
+ib700wdt_attach(struct device *parent, struct device *self, void *aux)
+{
+   struct ib700wdt_softc *sc = (struct ib700wdt_softc *)self;
+   struct isa_attach_args *ia = aux;
+
+   sc->sc_iot = ia->ia_iot;
+
+   if (bus_space_map(sc->sc_iot, ia->ia_iobase, IB700WDT_SIZE, 0, 
>sc_ioh))
+   return;
+
+   printf("\n");
+
+   wdog_register(ib700wdt_cb, sc);
+}
+
+int
+ib700wdt_activate(struct device *self, int act)
+{
+   switch (act) {
+   case DVACT_POWERDOWN:
+   wdog_shutdown(self);
+   break;
+   }
+
+   return (0);
+}
+
+int
+ib700wdt_cb(void *arg, int period)
+{
+   struct ib700wdt_softc *sc = arg;
+   uint8_t val;
+
+   if (period == 

CPUID in amd64/i386 boot code

[Masao Uebayashi]

Factor out CPUID code in mdrandom(), invoke it once, then save the
result.  I'll use it to switch behavior depending on HV or not.

efiboot is not tested.

Comments?
>From 104cb04bbbd0f7e40758938cc3103b2370a2285c Mon Sep 17 00:00:00 2001
From: Masao Uebayashi 
Date: Thu, 10 Mar 2016 21:03:07 +0900
Subject: [PATCH 1/3] Factor out CPUID instruction in amd64 boot code

---
 sys/arch/amd64/stand/boot/Makefile   |  1 +
 sys/arch/amd64/stand/boot/srt0.S |  1 +
 sys/arch/amd64/stand/cdboot/Makefile |  1 +
 sys/arch/amd64/stand/cdboot/srt0.S   |  2 +
 sys/arch/amd64/stand/libsa/cpuid.S   | 69 
 sys/arch/amd64/stand/libsa/libsa.h   |  7 
 sys/arch/amd64/stand/libsa/random_i386.S | 22 +-
 sys/arch/amd64/stand/pxeboot/Makefile|  1 +
 sys/arch/amd64/stand/pxeboot/srt0.S  |  2 +
 9 files changed, 86 insertions(+), 20 deletions(-)
 create mode 100644 sys/arch/amd64/stand/libsa/cpuid.S

diff --git a/sys/arch/amd64/stand/boot/Makefile 
b/sys/arch/amd64/stand/boot/Makefile
index 359ea31..5811646 100644
--- a/sys/arch/amd64/stand/boot/Makefile
+++ b/sys/arch/amd64/stand/boot/Makefile
@@ -26,6 +26,7 @@ SRCS+=boot.c bootarg.c cmd.c vars.c
 
 .PATH: ${SADIR}/libsa
 SRCS+= gidt.S random_i386.S
+SRCS+= cpuid.S
 SRCS+= cmd_i386.c dev_i386.c exec_i386.c gateA20.c machdep.c
 SRCS+= bioscons.c biosdev.c diskprobe.c memprobe.c time.c
 .if ${SOFTRAID:L} == "yes"
diff --git a/sys/arch/amd64/stand/boot/srt0.S b/sys/arch/amd64/stand/boot/srt0.S
index 9e1ede6..c2a5b2a 100644
--- a/sys/arch/amd64/stand/boot/srt0.S
+++ b/sys/arch/amd64/stand/boot/srt0.S
@@ -87,6 +87,7 @@ _start:
rep;stosb
 
call_ASM_LABEL(pmm_init)
+   call_C_LABEL(initcpuid)
call_C_LABEL(boot)
 
jmp _C_LABEL(_rtt)
diff --git a/sys/arch/amd64/stand/cdboot/Makefile 
b/sys/arch/amd64/stand/cdboot/Makefile
index 23a261f..04ba1e9 100644
--- a/sys/arch/amd64/stand/cdboot/Makefile
+++ b/sys/arch/amd64/stand/cdboot/Makefile
@@ -19,6 +19,7 @@ BINMODE=644
 SRCS+= machdep.c dev_i386.c exec_i386.c cmd_i386.c
 SRCS+= gidt.S random_i386.S biosdev.c bioscons.c gateA20.c \
memprobe.c diskprobe.c time.c
+SRCS+= cpuid.S
 SRCS+= softraid.c
 
 .PATH: ${S}/stand/boot
diff --git a/sys/arch/amd64/stand/cdboot/srt0.S 
b/sys/arch/amd64/stand/cdboot/srt0.S
index 82ff009..abe40d4 100644
--- a/sys/arch/amd64/stand/cdboot/srt0.S
+++ b/sys/arch/amd64/stand/cdboot/srt0.S
@@ -177,6 +177,8 @@ relocated:
movl%eax, _C_LABEL(bios_bootdev)
movl%eax, _C_LABEL(bios_cddev)
 
+   call_C_LABEL(initcpuid)
+
/*
 * Now call "main()".
 *
diff --git a/sys/arch/amd64/stand/libsa/cpuid.S 
b/sys/arch/amd64/stand/libsa/cpuid.S
new file mode 100644
index 000..c3ca1ac
--- /dev/null
+++ b/sys/arch/amd64/stand/libsa/cpuid.S
@@ -0,0 +1,69 @@
+/* $OpenBSD$   */
+
+/*
+ * Copyright (c) 2016 Masao Uebayashi 
+ * Copyright (c) 2013 Joel Sing 
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+   .data
+
+   .globl  _C_LABEL(cpu_id)
+   .globl  _C_LABEL(cpu_feature)
+   .globl  _C_LABEL(cpu_ebxfeature)
+   .globl  _C_LABEL(cpu_ecxfeature)
+
+_C_LABEL(cpu_id):  .long   0
+_C_LABEL(cpu_feature): .long   0
+_C_LABEL(cpu_ebxfeature):  .long   0
+_C_LABEL(cpu_ecxfeature):  .long   0
+
+   .text
+
+ENTRY(initcpuid)
+   pushal
+
+   // See if we have CPU identification.
+   pushfl
+   popl%eax
+   movl%eax, %ecx
+   orl $PSL_ID, %eax
+   pushl   %eax
+   popfl
+   pushfl
+   popl%eax
+   pushl   %ecx
+   popfl
+   andl$PSL_ID, %eax
+   jz  done
+
+   // CPUID leaf = 1, subleaf = 0
+   movl$1, %eax
+   movl$0, %ecx
+   cpuid
+
+   movl%eax, _C_LABEL(cpu_id)
+   movl%ebx, _C_LABEL(cpu_ebxfeature)
+   movl%ecx, _C_LABEL(cpu_ecxfeature)
+   movl%edx, _C_LABEL(cpu_feature)
+
+done:
+   popal
+   ret
+END(initcpuid)
diff --git a/sys/arch/amd64/stand/libsa/libsa.h 
b/sys/arch/amd64/stand/libsa/libsa.h
index fc65c6f..1934078 100644
--- 

Re: New scheduler for OpenBSD

[Chris Cappuccio]

Bob Beck [b...@openbsd.org] wrote:
> this is cool .. but
> 
> I would be interested in someone comparing server workloads, as
> opposed to interactive GUI response, using this.
> 
> I wouldn't be surprised that inspiriation from BFS would produce
> better interactive response, my bigger concern
> would be does this adversely impact how we deal with non-interactive 
> workloads.

I've been testing it on my heavily loaded Zabbix server, which regularly
get dozens of variables from over 5,000 devices. I get mixed results, the
load avg is higher, and the idle cpu time is generally higher, I regularly
see 1 second (top 's 1') CPU idle of 50-70% where I regularly saw 20-50% 
with the old scheduler. This is in top with all cpus collasped into 1 (top
'1'). I suspect if I averaged it over time, the difference could be less   
dramatic.

I'm using Postgres, there is no heavily threaded stuff, so I have
no idea why the idle CPU seems to be higher. The load avg is a bit higher,
it seems to stay up around 48 longer with the new scheduler, and also
shoots up and down more quickly. None of this is particularly well measured,
just a weird observation. With the old scheduler the load avg would fluctuate
from 32-42, and seemed to stay at a particular value for a longer period
of time (whatever that means.)

Zabbix is a horrible pig, and my polling confiuguration is not fine-tuned 
to top it off. The box is a "Xeon E2-1230 v3 @ 3.30GHz" with 16GB RAM and
two Samsung 845DC SSDs in softraid raid1. We use Postgres as a time-series
database, I'm looking at alternatives using collectd and graphite and
whatever, I really want to get away from Zabbix + Postgres.

Since this scheduler has a hack to help spinning threaded apps, that
explains why there is less CPU usage during video playback, but I don't
know how to explain my Zabbix results. It takes at least 2 minutes after
boot before the Zabbix box stabilizes to the levels I'm describing
here. 

If I set top to .1 second (top 's .1') then the new scheduler seems to
drive all CPUs to 0% idle for shorter periods of time, but more
frequently.

These are really rough observations. This box spawns lots of dirty
perl processes and also lots of fping processes for monitoring. I've
not spent the time to optimize this area at all. I was curious if this
scheduler or other OS level optmizations might take away some of the
costs here. With this rather stupid polling architecture, perhaps
copy-on-write is still the biggest win...

Chris

Re: New scheduler for OpenBSD

[Alexandre Ratchov]

On Tue, Mar 15, 2016 at 03:05:47PM +0100, Michal Mazurek wrote:
> 
> Please test, and let me know if the performance of something else
> degrades.
> 

With your diff firefox consumes twice less cpu (watched the same
video with and without the diff).  This suggests firefox spins
somewhere and your diff makes it spin less.

When audio device is using small blocks it stutters more with your
diff though; according to device counters the stuttering is caused
by sndiod not getting the cpu fast enough.

Re: IB700 watchdog

[Mike Larkin]

On Fri, Mar 18, 2016 at 08:18:30PM +0100, Mark Kettenis wrote:
> > Date: Thu, 17 Mar 2016 14:28:04 +0900
> > From: Masao Uebayashi 
> > 
> > This tiny driver is only meant for a backup watchdog configuration on
> > QEMU, whose ICH watchdog, supported by ichwdt(4), seems broken.
> > 
> > ib700wdt(4) supports only 0-30 second timeouts but in practice it should
> > be good enough.
> 

Wait. So we're saying "let's write an entirely new driver because qemu
has broken emulation somewhere else"? Why not just ask (nicely) the qemu
folks to fix the root cause, upstream?

I had a pretty good exchange with some of their devs in the past - can't
speak for all of them but the team I was working with before seemed very
receptive to accepting changes.

Writing a new device for this (nevermind the concerns kettenis and theo
are also mentioning) seems like the wrong approach.

-ml

> The problem is that isa-style probes like this are dangerous.  That is
> probably why you didn't enable this driver by default.  But if you
> don't enable the code, it will rot.
> 
> Is there a better way to detect this "device"?  For example in the
> acpi device tree?
> 
> > diff --git a/sys/arch/amd64/conf/GENERIC b/sys/arch/amd64/conf/GENERIC
> > index fee3c2a..82e7de0 100644
> > --- a/sys/arch/amd64/conf/GENERIC
> > +++ b/sys/arch/amd64/conf/GENERIC
> > @@ -608,6 +608,7 @@ bktr0   at pci?
> >  radio* at bktr?
> >  
> >  #wdt0  at pci? # Ind Computer Source PCI-WDT50x driver
> > +#ib700wdt* at isa? port 0x441  # iBase 700 (IB700) Watchdog Timer
> >  
> >  # crypto support
> >  hifn*  at pci? # Hi/fn 7751 crypto card
> > diff --git a/sys/arch/i386/conf/GENERIC b/sys/arch/i386/conf/GENERIC
> > index 0984e5b..dbb7df6 100644
> > --- a/sys/arch/i386/conf/GENERIC
> > +++ b/sys/arch/i386/conf/GENERIC
> > @@ -108,6 +108,7 @@ geodesc* at pci?# Geode SC1100/SCx200 
> > IAOC
> >  wdt0   at pci? # Ind Computer Source PCI-WDT50x driver
> >  berkwdt0 at pci?   # Berkshire PCI-PC Watchdog driver
> >  pwdog0 at pci? # Quancom PWDOG1 watchdog timer
> > +#ib700wdt* at isa? port 0x441  # iBase 700 (IB700) Watchdog Timer
> >  
> >  # National Semiconductor LM7[89] and compatible hardware monitors
> >  lm0at isa? port 0x290
> > diff --git a/sys/dev/isa/files.isa b/sys/dev/isa/files.isa
> > index 863d11c..92a9ecc 100644
> > --- a/sys/dev/isa/files.isa
> > +++ b/sys/dev/isa/files.isa
> > @@ -380,3 +380,8 @@ filedev/isa/isagpio.c   isagpio
> >  #file  dev/isa/pcmcia_pcic.c   pcic | pcicmaster
> >  
> >  #file  dev/isa/pcmcia_isa.cpcmcia
> > +
> > +# iBase 700 (IB700) Watchdog Timer
> > +device ib700wdt
> > +attach ib700wdt at isa
> > +file   dev/isa/ib700wdt.c  ib700wdt
> > diff --git a/sys/dev/isa/ib700wdt.c b/sys/dev/isa/ib700wdt.c
> > new file mode 100644
> > index 000..cdad79f
> > --- /dev/null
> > +++ b/sys/dev/isa/ib700wdt.c
> > @@ -0,0 +1,142 @@
> > +/*
> > + * Copyright (c) 2016 Masao Uebayashi 
> > + *
> > + * Permission to use, copy, modify, and distribute this software for any
> > + * purpose with or without fee is hereby granted, provided that the above
> > + * copyright notice and this permission notice appear in all copies.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> > + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> > + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> > + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> > + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> > + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> > + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +
> > +/*
> > + * IB700 USER'S MANUAL
> > + * Version 1.0B
> > + * p28
> > + * Watchdog Timer Configuration
> > + */
> > +
> > +#defineIB700WDT_BASE   0x441
> > +#defineIB700WDT_SIZE   3
> > +#defineIB700WDT_DIS0   /* 0x441 */
> > +#defineIB700WDT_ENA2   /* 0x443 */
> > +#defineIB700WDT_SEC_MIN0
> > +#defineIB700WDT_SEC_MAX30
> > +
> > +static inline uint8_t
> > +ib700wdt_sec2val(int sec)
> > +{
> > +   /* 0/1sec = 0xf, 2/3sec = 0xe, ..., 28/29 = 0x1, 30sec = 0x0 */
> > +   return (0xf - (sec * 0xf / 30));
> > +}
> > +
> > +/*
> > + * Driver for iBase 700 Watchdog Timer
> > + * Mainly meant for QEMU's "ib700" watchdog device
> > + * Can't handle immediate reset (sec=0)
> > + */
> > +
> > +struct ib700wdt_softc {
> > +   struct device sc_dev;
> > +   bus_space_tag_t sc_iot;
> > +   bus_space_handle_t sc_ioh;
> > +   int sc_period;
> > +};
> > +
> > +int 

Re: IB700 watchdog

[Martin Pieuchot]

On 17/03/16(Thu) 14:28, Masao Uebayashi wrote:
> This tiny driver is only meant for a backup watchdog configuration on
> QEMU, whose ICH watchdog, supported by ichwdt(4), seems broken.

What's the problem?  Is it in our code or in QEMU?

Re: New scheduler for OpenBSD

[Michael McConville]

Edd Barrett wrote:
> On Sat, Mar 19, 2016 at 09:06:26AM +0100, Alexandre Ratchov wrote:
> > The browsers problems seem caused by the way pthreads behave;
> > browsers appear to spin.  With the proposed scheduler they spin
> > less.  But the real question is why they spin at all?
> 
> Inspired by this comment, I set out to see if I could find *where* the
> browsers are spinning. "Just build the browsers with profiling
> instrumentation and look where the time goes when playing a youtube
> video" I thought. "Easy" I thought.
> 
> Well no. We build our chrome and firefox with clang, which doesn't
> support gprof style profiling.
> 
> Clang does have this -fprofile-instr-generate flag, which throws out
> some profiling data at runtime, but it appears it is designed to be
> used by the compiler itself as compile-time optimisation hints[1].
> It's not even clear if there is any timing data in there.
> 
> There's another clang profiling mode which depends upon Linux perf,
> which is obviously not an option for us.
> 
> Nevertheless, I decided to try it on the off-chance that clang's
> profiling data could be useful (and I'm totally accepting that, if it
> is, I will probably have to write a python script to make sense of the
> output). Sadly I stumbled at the first hurdle:

I've also been meaning to try something like this:

http://poormansprofiler.org/

Seems applicable here.

uvm amap: Remove redundant check

[Stefan Kempf]

The compiler is also smart enough to recognize that this is redundant.
The resulting code on amd64 is basically equivalent (slightly different
register allocation and instruction scheduling).

ok?

Index: uvm/uvm_amap.c
===
RCS file: /cvs/src/sys/uvm/uvm_amap.c,v
retrieving revision 1.61
diff -u -p -r1.61 uvm_amap.c
--- uvm/uvm_amap.c  15 Mar 2016 18:16:21 -  1.61
+++ uvm/uvm_amap.c  16 Mar 2016 16:33:52 -
@@ -917,10 +917,6 @@ amap_swap_off(int startslot, int endslot
LIST_INSERT_BEFORE(am, _prev, am_list);
LIST_INSERT_AFTER(am, _next, am_list);
 
-   if (am->am_nused <= 0) {
-   goto next;
-   }
-
for (i = 0; i < am->am_nused; i++) {
int slot;
int swslot;
@@ -950,7 +946,6 @@ amap_swap_off(int startslot, int endslot
i = 0;
}
 
-next:
KASSERT(LIST_NEXT(_prev, am_list) == _next ||
LIST_NEXT(LIST_NEXT(_prev, am_list), am_list) ==
_next);

Re: CPUID in amd64/i386 boot code

[Mike Larkin]

On Thu, Mar 17, 2016 at 03:15:07PM +0900, Masao Uebayashi wrote:
> This is the intended use, avoid busy-polling of BIOS PC console if
> running on HV.  Avoid 100% CPU usage at boot prompt on hypervisors.
> 

Which hypervisors have you tested this on?

-ml

> Originally I unconditionally reverted the polling part, which was
> introduced only for Intel Mac Mini.  After brief discussion with mikeb@,
> I decided to leave that hack by checking HV bit in CPUID (cpu_ecxfeature).
> 
> diff --git a/sys/arch/amd64/stand/libsa/bioscons.c 
> b/sys/arch/amd64/stand/libsa/bioscons.c
> index bdff9a4..fa42751 100644
> --- a/sys/arch/amd64/stand/libsa/bioscons.c
> +++ b/sys/arch/amd64/stand/libsa/bioscons.c
> @@ -30,6 +30,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -37,7 +38,7 @@
>  #include 
>  #include 
>  
> -#include 
> +#include 
>  
>  #include "biosdev.h"
>  
> @@ -82,14 +83,17 @@ pc_getc(dev_t dev)
>   return (rv & 0xff);
>   }
>  
> - /*
> -  * Wait for a character to actually become available.  Appears to
> -  * be necessary on (at least) the Intel Mac Mini.
> -  */
> - do {
> - __asm volatile(DOINT(0x16) "; setnz %b0" : "=a" (rv) :
> - "0" (0x100) : "%ecx", "%edx", "cc" );
> - } while ((rv & 0xff) == 0);
> + if ((cpu_ecxfeature & CPUIDECX_HV) == 0) {
> + /*
> + * Wait for a character to actually become available.
> + * Appears to be necessary on (at least) the Intel Mac
> + * Mini.
> +  */
> + do {
> + __asm volatile(DOINT(0x16) "; setnz %b0" : "=a" (rv) :
> + "0" (0x100) : "%ecx", "%edx", "cc" );
> + } while ((rv & 0xff) == 0);
> + }
>  
>   __asm volatile(DOINT(0x16) : "=a" (rv) : "0" (0x000) :
>   "%ecx", "%edx", "cc" );
> diff --git a/sys/arch/i386/stand/libsa/bioscons.c 
> b/sys/arch/i386/stand/libsa/bioscons.c
> index 028bef3..b53abcf 100644
> --- a/sys/arch/i386/stand/libsa/bioscons.c
> +++ b/sys/arch/i386/stand/libsa/bioscons.c
> @@ -27,15 +27,20 @@
>   */
>  
>  #include 
> +
>  #include 
>  #include 
> +#include 
> +
>  #include 
>  #include 
>  #include 
>  #include 
>  /* #include  */
>  #include 
> -#include 
> +
> +#include 
> +
>  #include "debug.h"
>  #include "biosdev.h"
>  
> @@ -80,14 +85,17 @@ pc_getc(dev_t dev)
>   return (rv & 0xff);
>   }
>  
> - /*
> -  * Wait for a character to actually become available.  Appears to
> -  * be necessary on (at least) the Intel Mac Mini.
> -  */
> - do {
> - __asm volatile(DOINT(0x16) "; setnz %b0" : "=a" (rv) :
> - "0" (0x100) : "%ecx", "%edx", "cc" );
> - } while ((rv & 0xff) == 0);
> + if ((cpu_ecxfeature & CPUIDECX_HV) == 0) {
> + /*
> + * Wait for a character to actually become available.
> + * Appears to be necessary on (at least) the Intel Mac
> + * Mini.
> +  */
> + do {
> + __asm volatile(DOINT(0x16) "; setnz %b0" : "=a" (rv) :
> + "0" (0x100) : "%ecx", "%edx", "cc" );
> + } while ((rv & 0xff) == 0);
> + }
>  
>   __asm volatile(DOINT(0x16) : "=a" (rv) : "0" (0x000) :
>   "%ecx", "%edx", "cc" );
> 
> On Thu, Mar 17, 2016 at 02:58:58PM +0900, Masao Uebayashi wrote:
> > Factor out CPUID code in mdrandom(), invoke it once, then save the
> > result.  I'll use it to switch behavior depending on HV or not.
> > 
> > efiboot is not tested.
> > 
> > Comments?
> 
> > >From 104cb04bbbd0f7e40758938cc3103b2370a2285c Mon Sep 17 00:00:00 2001
> > From: Masao Uebayashi 
> > Date: Thu, 10 Mar 2016 21:03:07 +0900
> > Subject: [PATCH 1/3] Factor out CPUID instruction in amd64 boot code
> > 
> > ---
> >  sys/arch/amd64/stand/boot/Makefile   |  1 +
> >  sys/arch/amd64/stand/boot/srt0.S |  1 +
> >  sys/arch/amd64/stand/cdboot/Makefile |  1 +
> >  sys/arch/amd64/stand/cdboot/srt0.S   |  2 +
> >  sys/arch/amd64/stand/libsa/cpuid.S   | 69 
> > 
> >  sys/arch/amd64/stand/libsa/libsa.h   |  7 
> >  sys/arch/amd64/stand/libsa/random_i386.S | 22 +-
> >  sys/arch/amd64/stand/pxeboot/Makefile|  1 +
> >  sys/arch/amd64/stand/pxeboot/srt0.S  |  2 +
> >  9 files changed, 86 insertions(+), 20 deletions(-)
> >  create mode 100644 sys/arch/amd64/stand/libsa/cpuid.S
> > 
> > diff --git a/sys/arch/amd64/stand/boot/Makefile 
> > b/sys/arch/amd64/stand/boot/Makefile
> > index 359ea31..5811646 100644
> > --- a/sys/arch/amd64/stand/boot/Makefile
> > +++ b/sys/arch/amd64/stand/boot/Makefile
> > @@ -26,6 +26,7 @@ SRCS+=boot.c bootarg.c cmd.c vars.c
> >  
> >  .PATH: ${SADIR}/libsa
> >  SRCS+= gidt.S random_i386.S
> > +SRCS+= cpuid.S
> >  SRCS+= cmd_i386.c dev_i386.c exec_i386.c 

Re: add EdgeRouter Pro to www/octeon.html

[Jasper Lievisse Adriaanse]

On Fri, Mar 18, 2016 at 08:44:11AM +0100, Marcus MERIGHI wrote:
> Hello,
> 
> "The patch seems to work fine on an EdgeRouter Pro.
> OK visa@"
> (http://marc.info/?l=openbsd-tech=145822792814191)
> 
> EdgeRouter Pro is not on octeon.html, put it there?
> 
> Bye, Marcus
Last time I checked the ethernet wasn't working either, so while we can boot on
it, I'm not too sure if we should list it yet.

> Index: octeon.html
> ===
> RCS file: /cvs/www/octeon.html,v
> retrieving revision 1.27
> diff -u -p -u -r1.27 octeon.html
> --- octeon.html   13 Jan 2016 14:25:49 -  1.27
> +++ octeon.html   18 Mar 2016 07:39:28 -
> @@ -70,7 +70,8 @@ Portwell CAM-0100
>  http://www.ubnt.com/edgemax/edgerouter-lite/;>Ubiquiti Networks
>  EdgeRouter LITE
>  http://www.ubnt.com/edgemax/edgerouter-poe/;>Ubiquiti Networks
> -EdgeRouter PoE
> +http://www.ubnt.com/edgemax/edgerouter-pro/;>Ubiquiti Networks
> +EdgeRouter Pro
>  
>  
>  
> 

-- 
jasper

Reduce local ``ticks'' declarations

[Martin Pieuchot]

A recent diff from dlg@ made me looks at where the global variable
``ticks'' is used and how.  I find this *really* difficult because
there's a lot of noise.  In order to reduce the noise and help for
this audit here's a first diff. It renames all the local variables
from ``ticks'' to ``nticks'' where this was not already the case.

This should make grepping easier, ok?

Index: arch/alpha/alpha/lock_machdep.c
===
RCS file: /cvs/src/sys/arch/alpha/alpha/lock_machdep.c,v
retrieving revision 1.3
diff -u -p -r1.3 lock_machdep.c
--- arch/alpha/alpha/lock_machdep.c 11 Feb 2015 03:56:00 -  1.3
+++ arch/alpha/alpha/lock_machdep.c 17 Mar 2016 18:46:17 -
@@ -71,14 +71,14 @@ __mp_lock_spin(struct __mp_lock *mpl)
while (mpl->mpl_count != 0)
SPINLOCK_SPIN_HOOK;
 #else
-   int ticks = __mp_lock_spinout;
-   if (!CPU_IS_PRIMARY(curcpu()))  /* XXX */
-   ticks += ticks; /* XXX */
+   int nticks = __mp_lock_spinout;
+   if (!CPU_IS_PRIMARY(curcpu()))
+   nticks += nticks;
 
-   while (mpl->mpl_count != 0 && --ticks > 0)
+   while (mpl->mpl_count != 0 && --nticks > 0)
SPINLOCK_SPIN_HOOK;
 
-   if (ticks == 0) {
+   if (nticks == 0) {
db_printf("__mp_lock(%p): lock spun out", mpl);
Debugger();
}
Index: arch/amd64/amd64/lock_machdep.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/lock_machdep.c,v
retrieving revision 1.9
diff -u -p -r1.9 lock_machdep.c
--- arch/amd64/amd64/lock_machdep.c 25 Jun 2015 00:58:49 -  1.9
+++ arch/amd64/amd64/lock_machdep.c 17 Mar 2016 18:46:21 -
@@ -50,12 +50,12 @@ __mp_lock_spin(struct __mp_lock *mpl, u_
while (mpl->mpl_ticket != me)
SPINLOCK_SPIN_HOOK;
 #else
-   int ticks = __mp_lock_spinout;
+   int nticks = __mp_lock_spinout;
 
-   while (mpl->mpl_ticket != me && --ticks > 0)
+   while (mpl->mpl_ticket != me && --nticks > 0)
SPINLOCK_SPIN_HOOK;
 
-   if (ticks == 0) {
+   if (nticks == 0) {
db_printf("__mp_lock(%p): lock spun out", mpl);
Debugger();
}
Index: arch/hppa/hppa/lock_machdep.c
===
RCS file: /cvs/src/sys/arch/hppa/hppa/lock_machdep.c,v
retrieving revision 1.8
diff -u -p -r1.8 lock_machdep.c
--- arch/hppa/hppa/lock_machdep.c   11 Feb 2015 01:58:57 -  1.8
+++ arch/hppa/hppa/lock_machdep.c   17 Mar 2016 18:46:27 -
@@ -81,12 +81,12 @@ __mp_lock_spin(struct __mp_lock *mpl)
while (mpl->mpl_count != 0)
SPINLOCK_SPIN_HOOK;
 #else
-   int ticks = __mp_lock_spinout;
+   int nticks = __mp_lock_spinout;
 
-   while (mpl->mpl_count != 0 && --ticks > 0)
+   while (mpl->mpl_count != 0 && --nticks > 0)
SPINLOCK_SPIN_HOOK;
 
-   if (ticks == 0) {
+   if (nticks == 0) {
db_printf("__mp_lock(%p): lock spun out", mpl);
Debugger();
}
Index: arch/i386/i386/lock_machdep.c
===
RCS file: /cvs/src/sys/arch/i386/i386/lock_machdep.c,v
retrieving revision 1.18
diff -u -p -r1.18 lock_machdep.c
--- arch/i386/i386/lock_machdep.c   30 May 2015 08:41:30 -  1.18
+++ arch/i386/i386/lock_machdep.c   17 Mar 2016 18:46:31 -
@@ -80,12 +80,12 @@ __mp_lock_spin(struct __mp_lock *mpl, u_
while (mpl->mpl_ticket != me)
SPINLOCK_SPIN_HOOK;
 #else
-   int ticks = __mp_lock_spinout;
+   int nticks = __mp_lock_spinout;
 
-   while (mpl->mpl_ticket != me && --ticks > 0)
+   while (mpl->mpl_ticket != me && --nticks > 0)
SPINLOCK_SPIN_HOOK;
 
-   if (ticks == 0) {
+   if (nticks == 0) {
db_printf("__mp_lock(%p): lock spun out", mpl);
Debugger();
}
Index: arch/m88k/m88k/mplock.c
===
RCS file: /cvs/src/sys/arch/m88k/m88k/mplock.c,v
retrieving revision 1.3
diff -u -p -r1.3 mplock.c
--- arch/m88k/m88k/mplock.c 11 Feb 2015 07:05:39 -  1.3
+++ arch/m88k/m88k/mplock.c 17 Mar 2016 18:46:34 -
@@ -50,12 +50,12 @@ __mp_lock_spin(struct __mp_lock *mpl)
while (mpl->mpl_count != 0)
SPINLOCK_SPIN_HOOK;
 #else
-   int ticks = __mp_lock_spinout;
+   int nticks = __mp_lock_spinout;
 
-   while (mpl->mpl_count != 0 && ticks-- > 0)
+   while (mpl->mpl_count != 0 && nticks-- > 0)
SPINLOCK_SPIN_HOOK;
 
-   if (ticks == 0) {
+   if (nticks == 0) {
db_printf("__mp_lock(0x%x): lock spun out", mpl);
Debugger();
}
Index: arch/mips64/mips64/mutex.c

Re: arm: only (re)set specific bits in sctlr

[Patrick Wildt]

On Sun, Mar 20, 2016 at 03:36:45AM +1100, Jonathan Gray wrote:
> On Wed, Mar 02, 2016 at 03:31:57PM +0100, Patrick Wildt wrote:
> > Hi,
> > 
> > currently we have a rather big list of bits that we remove and set in
> > the System Control Register.  Those differ per processor, so not every
> > armv7/armv8 processor has the same bits, although they tend to be
> > rather similar.
> > 
> > I think we should only reset and set a few specific ones that we really
> > really care about.  The SYST bit for instance is reserved on the A7
> > and enables something completely else (SETEND instruction) on the A53.
> > 
> > This is basically the same set as FreeBSD had before they removed the
> > armv7_setup code, as they now do that stuff in their locore.S.
> > 
> > Additionally this diff removes unused code and adds a TODO comment.
> > What we will need to do is set up the Auxiliary Control Register
> > to allow us to use e.g. instructions for atomic operations on
> > ARMv7.  Then we can replace those interrupt disable/enable hacks
> > with proper atomics.
> > 
> > Patrick
> 
> This diff is effectively
> 
> -   cpuctrl = | CPU_CONTROL_SYST_ENABLE
> 
> -   cpuctrlmask = | CPU_CONTROL_SYST_ENABLE
> -   | CPU_CONTROL_ROM_ENABLE 
> -   | CPU_CONTROL_BEND_ENABLE 
> -   | CPU_CONTROL_ROUNDROBIN | CPU_CONTROL_CPCLK
> -   | CPU_CONTROL_FI | CPU_CONTROL_VE
> -   | CPU_CONTROL_TRE | CPU_CONTROL_AFE;
> 
> Almost all of these do indeed appear to be reserved for v7.
> 
> Shouldn't the TRE/AFE v7 bits continue to be masked though?
> 
> CPU_CONTROL_TRE (TEX remap enable)
> CPU_CONTROL_AFE (Access Flag Enable)

That's a very good question.  In my opinion I would say, don't mask
them.

These bits are tightly coupled with pmap.  In our pmap the assumption
is that we do not use TEX remap and do not use the Access Flag.  I think
we should make the pmap control those bits.  Then it can decide itself
if it wants to make use of those bits or prefers to leave them disabled.
Also it would enable us to run two pmap more easily.  Like, the current
pmap and a rewrite.

Though, maybe this is out of scope for this diff and we should leave
those bits in the mask for now.  For the future I would prefer to have
the pmap take control over those.

> 
> > 
> > diff --git sys/arch/arm/arm/cpufunc.c sys/arch/arm/arm/cpufunc.c
> > index aab8bc6..2ca5329 100644
> > --- sys/arch/arm/arm/cpufunc.c
> > +++ sys/arch/arm/arm/cpufunc.c
> > @@ -1342,16 +1342,18 @@ armv7_setup()
> >  {
> > int cpuctrl, cpuctrlmask;
> >  
> > -   cpuctrl = CPU_CONTROL_MMU_ENABLE | CPU_CONTROL_SYST_ENABLE
> > -   | CPU_CONTROL_IC_ENABLE | CPU_CONTROL_DC_ENABLE
> > -   | CPU_CONTROL_BPRD_ENABLE | CPU_CONTROL_AFLT_ENABLE;
> > -   cpuctrlmask = CPU_CONTROL_MMU_ENABLE | CPU_CONTROL_SYST_ENABLE
> > -   | CPU_CONTROL_IC_ENABLE | CPU_CONTROL_DC_ENABLE
> > -   | CPU_CONTROL_ROM_ENABLE | CPU_CONTROL_BPRD_ENABLE
> > -   | CPU_CONTROL_BEND_ENABLE | CPU_CONTROL_AFLT_ENABLE
> > -   | CPU_CONTROL_ROUNDROBIN | CPU_CONTROL_CPCLK
> > -   | CPU_CONTROL_VECRELOC | CPU_CONTROL_FI | CPU_CONTROL_VE
> > -   | CPU_CONTROL_TRE | CPU_CONTROL_AFE;
> > +   cpuctrlmask = CPU_CONTROL_MMU_ENABLE
> > +   | CPU_CONTROL_AFLT_ENABLE
> > +   | CPU_CONTROL_DC_ENABLE
> > +   | CPU_CONTROL_BPRD_ENABLE
> > +   | CPU_CONTROL_IC_ENABLE
> > +   | CPU_CONTROL_VECRELOC;
> > +
> > +   cpuctrl = CPU_CONTROL_MMU_ENABLE
> > +   | CPU_CONTROL_AFLT_ENABLE
> > +   | CPU_CONTROL_DC_ENABLE
> > +   | CPU_CONTROL_BPRD_ENABLE
> > +   | CPU_CONTROL_IC_ENABLE;
> >  
> > if (vector_page == ARM_VECTORS_HIGH)
> > cpuctrl |= CPU_CONTROL_VECRELOC;
> > @@ -1359,16 +1361,12 @@ armv7_setup()
> > /* Clear out the cache */
> > cpu_idcache_wbinv_all();
> >  
> > -   /* Now really make sure they are clean.  */
> > -   /* XXX */
> > -   /*
> > -   asm volatile ("mcr\tp15, 0, r0, c7, c7, 0" : : );
> > -   */
> > -
> > /* Set the control register */
> > curcpu()->ci_ctrl = cpuctrl;
> > cpu_control(cpuctrlmask, cpuctrl);
> >  
> > +   /* TODO: Set ACTLR to e.g. allow LDREX/STREX. */
> > +
> > /* And again. */
> > cpu_idcache_wbinv_all();
> >  }
> > 
> 

Re: multitouch support in wsmouse 1/3

[Ulf Brosziewski]

It isn't possible to leave all of the existing code intact,
at least not for touchpads, which form the most complex and
critical case here. Either all of them run with the modified
synaptics driver, or they don't. I don't see a reasonable
solution in between (wsconscomm.c might become a little monster
otherwise).

This leaves the option of running mouse and touch panel
drivers with wsmouse_input, as before, and restrict the changes
to the touchpad drivers. This could provide a kind of "fallback"
in case of serious regressions, and the trivial parts of
the "drivers" diff could be removed. If this is what you want,
I could prepare it, but it would take a few days.


On 03/17/2016 01:58 PM, Martin Pieuchot wrote:

On 13/03/16(Sun) 18:37, Ulf Brosziewski wrote:

The diffs below are a rewrite of the input-processing part of wsmouse. It
adds support for multitouch input.

I have split the set of diffs into three parts and I will post part 2 and 3
in separate messages. Part 1 below contains all patches for wscons, part 2
is for the hardware drivers, part 3 is a patch for the synaptics driver in
xenocara (compiling that driver will require the modified version of
wsconsio.h in /usr/include/dev/wscons).


I'm really afraid because this is just a single diff split in 3, they
are not independent.  Plus since your original mails included a broken
diff I doubt anybody tried it.

That said you've done some great work and I like it a lot.

Could you prepare a diff with all the new stuff that does do change
anything in the existing code?  This could go in directly.

Which hardware still need to be tested?

Re: Scheduler hack for multi-threaded processes

[Philip Guenther]

On Sat, Mar 19, 2016 at 9:18 AM, Miod Vallat  wrote:
>
>> I'd like to know if dereferencing ``p_p'' is safe without holding the
>> KERNEL_LOCK.
>
> SCHED_LOCK is enough to access p_p->ps_threads,

Uh, not quite.

p_p itself is immutable for the life of a thread and can be
dereferenced without locks.

p_p->ps_threads (and p_thr_link) can only be modified by threads in
this process.  The result is that the test here can't claim the
process is single-threaded when it's multi-threaded.  (An "is MT"
result can go stale if there's no locking and the only other thread in
the process exits, but that's generally not an issue.)

If you really need to walk the p_p->ps_threads list, then you
currently need the kernel lock to keep the threads in it from
disappearing.


> The construct used to decide whether the process is multi-threaded
> already appears twice in sys/kern¸ and your diff adds a third
> instance. It is probably worth turning into a macro or an inline
> function¸ to make sure there is no risk of the copies becoming
> out-of-sync over time.

I like this idea.  Note that it should be a "am the only thread" or
"do I have sibling threads" kind of predicate and not an "is this
arbitrary process singled/multi-threaded?" test.


Philip Guenther

Re: CPUID in amd64/i386 boot code

[Mike Belopuhov]

On Wed, Mar 16, 2016 at 23:47 -0700, Mike Larkin wrote:
> On Thu, Mar 17, 2016 at 03:31:45PM +0900, Masao Uebayashi wrote:
> > On Wed, Mar 16, 2016 at 11:26:39PM -0700, Mike Larkin wrote:
> > > On Thu, Mar 17, 2016 at 03:15:07PM +0900, Masao Uebayashi wrote:
> > > > This is the intended use, avoid busy-polling of BIOS PC console if
> > > > running on HV.  Avoid 100% CPU usage at boot prompt on hypervisors.
> > > > 
> > > 
> > > Which hypervisors have you tested this on?
> > 
> > VMware ESXi
> > KVM
> > QEMU
> 
> While I share some of Theo's concerns about testing this, this particular
> diff seems ok to me. You probably at least need to get someone to test on
> Hyper-V, and run these new bootblocks on a variety of machines (especially
> older non-Intel/AMD i386 machines).
> 
> -ml
>

I've tested the diff and with a small adjustment to the
efiboot/bootia32/Makefile below, I was able to rebuild
stand/ and test the thing (with the follow up diff to
the bioscons.c).

As I've mentioned on ICB, Xen exposes this issue, while
Hyper-V doesn't.  The change doesn't help or harm Xen, no
change on Hyper-V.  But I think it's still useful if this
helps KVM and VMware.

> > 
> > > -ml
> > > 
> > > > Originally I unconditionally reverted the polling part, which was
> > > > introduced only for Intel Mac Mini.  After brief discussion with mikeb@,
> > > > I decided to leave that hack by checking HV bit in CPUID 
> > > > (cpu_ecxfeature).
> > > > 
> > > > diff --git a/sys/arch/amd64/stand/libsa/bioscons.c 
> > > > b/sys/arch/amd64/stand/libsa/bioscons.c
> > > > index bdff9a4..fa42751 100644
> > > > --- a/sys/arch/amd64/stand/libsa/bioscons.c
> > > > +++ b/sys/arch/amd64/stand/libsa/bioscons.c
> > > > @@ -30,6 +30,7 @@
> > > >  
> > > >  #include 
> > > >  #include 
> > > > +#include 
> > > >  
> > > >  #include 
> > > >  #include 
> > > > @@ -37,7 +38,7 @@
> > > >  #include 
> > > >  #include 
> > > >  
> > > > -#include 
> > > > +#include 
> > > >  
> > > >  #include "biosdev.h"
> > > >  
> > > > @@ -82,14 +83,17 @@ pc_getc(dev_t dev)
> > > > return (rv & 0xff);
> > > > }
> > > >  
> > > > -   /*
> > > > -* Wait for a character to actually become available.  Appears 
> > > > to
> > > > -* be necessary on (at least) the Intel Mac Mini.
> > > > -*/
> > > > -   do {
> > > > -   __asm volatile(DOINT(0x16) "; setnz %b0" : "=a" (rv) :
> > > > -   "0" (0x100) : "%ecx", "%edx", "cc" );
> > > > -   } while ((rv & 0xff) == 0);
> > > > +   if ((cpu_ecxfeature & CPUIDECX_HV) == 0) {
> > > > +   /*
> > > > + * Wait for a character to actually become available.
> > > > + * Appears to be necessary on (at least) the Intel Mac
> > > > + * Mini.
> > > > +*/
> > > > +   do {
> > > > +   __asm volatile(DOINT(0x16) "; setnz %b0" : "=a" 
> > > > (rv) :
> > > > +   "0" (0x100) : "%ecx", "%edx", "cc" );
> > > > +   } while ((rv & 0xff) == 0);
> > > > +   }
> > > >  
> > > > __asm volatile(DOINT(0x16) : "=a" (rv) : "0" (0x000) :
> > > > "%ecx", "%edx", "cc" );
> > > > diff --git a/sys/arch/i386/stand/libsa/bioscons.c 
> > > > b/sys/arch/i386/stand/libsa/bioscons.c
> > > > index 028bef3..b53abcf 100644
> > > > --- a/sys/arch/i386/stand/libsa/bioscons.c
> > > > +++ b/sys/arch/i386/stand/libsa/bioscons.c
> > > > @@ -27,15 +27,20 @@
> > > >   */
> > > >  
> > > >  #include 
> > > > +
> > > >  #include 
> > > >  #include 
> > > > +#include 
> > > > +
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > >  /* #include  */
> > > >  #include 
> > > > -#include 
> > > > +
> > > > +#include 
> > > > +
> > > >  #include "debug.h"
> > > >  #include "biosdev.h"
> > > >  
> > > > @@ -80,14 +85,17 @@ pc_getc(dev_t dev)
> > > > return (rv & 0xff);
> > > > }
> > > >  
> > > > -   /*
> > > > -* Wait for a character to actually become available.  Appears 
> > > > to
> > > > -* be necessary on (at least) the Intel Mac Mini.
> > > > -*/
> > > > -   do {
> > > > -   __asm volatile(DOINT(0x16) "; setnz %b0" : "=a" (rv) :
> > > > -   "0" (0x100) : "%ecx", "%edx", "cc" );
> > > > -   } while ((rv & 0xff) == 0);
> > > > +   if ((cpu_ecxfeature & CPUIDECX_HV) == 0) {
> > > > +   /*
> > > > + * Wait for a character to actually become available.
> > > > + * Appears to be necessary on (at least) the Intel Mac
> > > > + * Mini.
> > > > +*/
> > > > +   do {
> > > > +   __asm volatile(DOINT(0x16) "; setnz %b0" : "=a" 
> > > > (rv) :
> > > > +   "0" (0x100) : "%ecx", "%edx", "cc" );
> > > > +   } while ((rv & 0xff) == 0);
> > > > +   }
> > > >  
> > > > 

Re: New scheduler for OpenBSD

[Norman Golisz]

Hi Michal,

On Fri Mar 18 2016 10:03, Edd Barrett wrote:
> On Thu, Mar 17, 2016 at 09:26:08PM +0100, Henrik Friedrichsen wrote:
> > On Tue, Mar 15, 2016 at 03:05:47PM +0100, Michal Mazurek wrote:
> > > Chrome still isn't smooth.
> > > 
> > > Please test, and let me know if the performance of something else
> > > degrades.
> > 
> > While Chrome may not be 100% smooth yet, the system is a lot more
> > interactive. I can now play YouTube videos without stutters while doing
> > other things.
> 
> I can't vouch for the code, but this makes video playback in firefox
> usable on my x240t. Before it would stutter beyond belief.
> 
> I'll run with this for a while and let you know if anything comes up.

I can also confirm this patch makes a HUGE difference in video playback
performance in firefox and minitube on my T400.

This is the first time I can watch videos without stuttering (even in
HD/full screen).

And it seems to improve "GUI responsiveness" in general, too.

Thank you for working on this!

Remove build machinery for non-UTF-8 charsets

[Jeremie Courreges-Anglas]

What's the plan regarding this?  libc and locale(1) don't use
LOCALE_CHARSETS anymore, we only support UTF-8 and I doubt that we'll
change our mind about that.

The diff below removes support for non-UTF-8 LC_CTYPE files.  It
survived make release.

Thoughts?

Index: lib/libc/locale/Makefile.inc
===
RCS file: /cvs/src/lib/libc/locale/Makefile.inc,v
retrieving revision 1.20
diff -u -p -r1.20 Makefile.inc
--- lib/libc/locale/Makefile.inc3 Jul 2015 11:15:19 -   1.20
+++ lib/libc/locale/Makefile.inc17 Mar 2016 22:36:13 -
@@ -3,9 +3,6 @@
 # locale sources
 .PATH: ${LIBCSRCDIR}/locale
 
-# for LOCALECHARSETS
-.include "${.CURDIR}/../../share/locale/ctype/Makefile.inc"
-
 SRCS+= btowc.c _def_messages.c _def_monetary.c _def_numeric.c _def_time.c \
localeconv.c nl_langinfo.c setlocale.c iswctype.c __mb_cur_max.c \
mblen.c mbrlen.c mbstowcs.c mbtowc.c multibyte_citrus.c wcscoll.c \
@@ -43,4 +40,3 @@ MLINKS+=setlocale.3 localeconv.3 \
wcsrtombs.3 wcsnrtombs.3
 
 CFLAGS+=-I${.CURDIR} -I${LIBCSRCDIR}/citrus
-CFLAGS+=-DLOCALE_CHARSETS="\"${LOCALECHARSETS}\""
Index: share/locale/ctype/Makefile
===
RCS file: /cvs/src/share/locale/ctype/Makefile,v
retrieving revision 1.10
diff -u -p -r1.10 Makefile
--- share/locale/ctype/Makefile 1 Jul 2013 00:36:12 -   1.10
+++ share/locale/ctype/Makefile 17 Mar 2016 22:34:44 -
@@ -6,53 +6,18 @@ NOMAN=# defined
 # pull LOCALEDIR and other declarations
 .include 
 
-# pull in LOCALECHARSETS
-.include "${.CURDIR}/Makefile.inc"
+all: UTF-8.out
 
-LOCALESRC_ARMSCII-8 = hy_AM.ARMSCII-8
-LOCALESRC_CP1251 = bg_BG.CP1251
-LOCALESRC_CP866 = ru_RU.CP866
-LOCALESRC_ISO8859-1 = en_US.ISO_8859-1
-LOCALESRC_ISO8859-2 = en_US.ISO_8859-2
-LOCALESRC_ISO8859-4 = en_US.ISO_8859-4
-LOCALESRC_ISO8859-5 = ru_RU.ISO_8859-5
-LOCALESRC_ISO8859-7 = el_GR.ISO8859-7
-LOCALESRC_ISO8859-9 = tr_TR.ISO8859-9
-LOCALESRC_ISO8859-13 = lt_LT.ISO8859-13
-LOCALESRC_ISO8859-15 = en_US.DIS_8859-15
-LOCALESRC_KOI8-R = ru_RU.KOI8-R
-LOCALESRC_KOI8-U = uk_UA.KOI8-U
-LOCALESRC_UTF-8 = en_US.UTF-8
-
-all: ${LOCALECHARSETS:S/$/.out/g}
-realall: ${LOCALECHARSETS:S/$/.out/g}
-
-CLEANFILES+=   ${LOCALECHARSETS:S/$/.out/g}
+UTF-8.out: en_US.UTF-8.src
+   ${CPP} < ${.CURDIR}/en_US.UTF-8.src | \
+   sed -e '/^#/d' | mklocale -o ${.TARGET}
 
-FILES= ${LOCALECHARSETS:S/$/.out/g}
-.for locale in ${LOCALECHARSETS}
-FILESDIR_${locale}.out=${LOCALEDIR}/${locale}
-FILESNAME_${locale}.out=   LC_CTYPE
-.endfor
+CLEANFILES+=   UTF-8.out
 
 install:
-.for locale in ${LOCALECHARSETS}
install -o ${LOCALEOWN} -g ${LOCALEGRP} -m ${DIRMODE} -d \
-   ${DESTDIR}${LOCALEDIR}/${locale}
+   ${DESTDIR}${LOCALEDIR}/UTF-8
install -o ${LOCALEOWN} -g ${LOCALEGRP} -m ${LOCALEMODE} \
-   ${locale}.out ${DESTDIR}${LOCALEDIR}/${locale}/LC_CTYPE
-.endfor
-
-.for locale in ${LOCALECHARSETS}
-${locale}.out: ${LOCALESRC_${locale}}.src
-   ${CPP} -I${.CURDIR} < ${.CURDIR}/${LOCALESRC_${locale}}.src | \
-   sed -e '/^#/d' | mklocale -o ${.TARGET}
-.endfor
-
-.SUFFIXES: .src .out
-.src.out:
-   ${CPP} -I${.CURDIR} < ${.IMPSRC} | sed -e '/^#/d' | \
-mklocale -o ${.TARGET}
-
+   UTF-8.out ${DESTDIR}${LOCALEDIR}/UTF-8/LC_CTYPE
 
 .include 
Index: share/locale/ctype/Makefile.inc
===
RCS file: share/locale/ctype/Makefile.inc
diff -N share/locale/ctype/Makefile.inc
--- share/locale/ctype/Makefile.inc 1 Jul 2013 00:35:22 -   1.2
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,6 +0,0 @@
-# $OpenBSD: Makefile.inc,v 1.2 2013/07/01 00:35:22 fgsch Exp $
-
-# Charsets supported by LC_CTYPE locale
-LOCALECHARSETS=ARMSCII-8 CP1251 CP866 ISO8859-1 ISO8859-13 ISO8859-15 \
-   ISO8859-2 ISO8859-4 ISO8859-5 ISO8859-7 ISO8859-9 KOI8-R \
-   KOI8-U UTF-8
Index: usr.bin/locale/Makefile
===
RCS file: /cvs/src/usr.bin/locale/Makefile,v
retrieving revision 1.1
diff -u -p -r1.1 Makefile
--- usr.bin/locale/Makefile 3 Jun 2013 14:27:50 -   1.1
+++ usr.bin/locale/Makefile 17 Mar 2016 22:36:13 -
@@ -1,9 +1,5 @@
 #  $OpenBSD: Makefile,v 1.1 2013/06/03 14:27:50 stsp Exp $
 
-# for LOCALECHARSETS
-.include "${.CURDIR}/../../share/locale/ctype/Makefile.inc"
-
 PROG=  locale
-CFLAGS+=   -DLOCALE_CHARSETS="\"${LOCALECHARSETS}\""
 
 .include 


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

Re: SSLv3 and Internet Printing Protocol requirements problem

[Chris Bennett]

On Fri, Mar 18, 2016 at 08:31:36AM -0600, Bob Beck wrote:
> > But it officially requires support for IPP version 1.0, which used
> > SSLv3.
> > I assume that there are printers, perhaps many were sold, which did use
> > version 1.0. That version used SSLv3 for encrypted communication. Which
> > is now gone.
> 
> Almost certainly.
> 
> >
> > How should we deal with this problem?
> 
> Here's a nickel kid - buy a better printer?
> 

That makes sense. Any big operation is going to be replacing printers
regularly due to hwavy use. Any small operation probably won't have much
in the way of security needs.

I don't know much about OpenSSL, "nice" to know that crap is still
buildable for those "special" needs.

Chris

> Seriously. we just won't be conformant. These protocols are designed
> by industry consortiums who want to sell product at lowest cost, not
> care about security.   If you seriously must have insecure stuff,
> well, that's why OpenSSL still exists, you can always build with that.

Re: arm: only (re)set specific bits in sctlr

[Jonathan Gray]

On Wed, Mar 02, 2016 at 03:31:57PM +0100, Patrick Wildt wrote:
> Hi,
> 
> currently we have a rather big list of bits that we remove and set in
> the System Control Register.  Those differ per processor, so not every
> armv7/armv8 processor has the same bits, although they tend to be
> rather similar.
> 
> I think we should only reset and set a few specific ones that we really
> really care about.  The SYST bit for instance is reserved on the A7
> and enables something completely else (SETEND instruction) on the A53.
> 
> This is basically the same set as FreeBSD had before they removed the
> armv7_setup code, as they now do that stuff in their locore.S.
> 
> Additionally this diff removes unused code and adds a TODO comment.
> What we will need to do is set up the Auxiliary Control Register
> to allow us to use e.g. instructions for atomic operations on
> ARMv7.  Then we can replace those interrupt disable/enable hacks
> with proper atomics.
> 
> Patrick

This diff is effectively

-   cpuctrl = | CPU_CONTROL_SYST_ENABLE

-   cpuctrlmask = | CPU_CONTROL_SYST_ENABLE
-   | CPU_CONTROL_ROM_ENABLE 
-   | CPU_CONTROL_BEND_ENABLE 
-   | CPU_CONTROL_ROUNDROBIN | CPU_CONTROL_CPCLK
-   | CPU_CONTROL_FI | CPU_CONTROL_VE
-   | CPU_CONTROL_TRE | CPU_CONTROL_AFE;

Almost all of these do indeed appear to be reserved for v7.

Shouldn't the TRE/AFE v7 bits continue to be masked though?

CPU_CONTROL_TRE (TEX remap enable)
CPU_CONTROL_AFE (Access Flag Enable)

> 
> diff --git sys/arch/arm/arm/cpufunc.c sys/arch/arm/arm/cpufunc.c
> index aab8bc6..2ca5329 100644
> --- sys/arch/arm/arm/cpufunc.c
> +++ sys/arch/arm/arm/cpufunc.c
> @@ -1342,16 +1342,18 @@ armv7_setup()
>  {
>   int cpuctrl, cpuctrlmask;
>  
> - cpuctrl = CPU_CONTROL_MMU_ENABLE | CPU_CONTROL_SYST_ENABLE
> - | CPU_CONTROL_IC_ENABLE | CPU_CONTROL_DC_ENABLE
> - | CPU_CONTROL_BPRD_ENABLE | CPU_CONTROL_AFLT_ENABLE;
> - cpuctrlmask = CPU_CONTROL_MMU_ENABLE | CPU_CONTROL_SYST_ENABLE
> - | CPU_CONTROL_IC_ENABLE | CPU_CONTROL_DC_ENABLE
> - | CPU_CONTROL_ROM_ENABLE | CPU_CONTROL_BPRD_ENABLE
> - | CPU_CONTROL_BEND_ENABLE | CPU_CONTROL_AFLT_ENABLE
> - | CPU_CONTROL_ROUNDROBIN | CPU_CONTROL_CPCLK
> - | CPU_CONTROL_VECRELOC | CPU_CONTROL_FI | CPU_CONTROL_VE
> - | CPU_CONTROL_TRE | CPU_CONTROL_AFE;
> + cpuctrlmask = CPU_CONTROL_MMU_ENABLE
> + | CPU_CONTROL_AFLT_ENABLE
> + | CPU_CONTROL_DC_ENABLE
> + | CPU_CONTROL_BPRD_ENABLE
> + | CPU_CONTROL_IC_ENABLE
> + | CPU_CONTROL_VECRELOC;
> +
> + cpuctrl = CPU_CONTROL_MMU_ENABLE
> + | CPU_CONTROL_AFLT_ENABLE
> + | CPU_CONTROL_DC_ENABLE
> + | CPU_CONTROL_BPRD_ENABLE
> + | CPU_CONTROL_IC_ENABLE;
>  
>   if (vector_page == ARM_VECTORS_HIGH)
>   cpuctrl |= CPU_CONTROL_VECRELOC;
> @@ -1359,16 +1361,12 @@ armv7_setup()
>   /* Clear out the cache */
>   cpu_idcache_wbinv_all();
>  
> - /* Now really make sure they are clean.  */
> - /* XXX */
> - /*
> - asm volatile ("mcr\tp15, 0, r0, c7, c7, 0" : : );
> - */
> -
>   /* Set the control register */
>   curcpu()->ci_ctrl = cpuctrl;
>   cpu_control(cpuctrlmask, cpuctrl);
>  
> + /* TODO: Set ACTLR to e.g. allow LDREX/STREX. */
> +
>   /* And again. */
>   cpu_idcache_wbinv_all();
>  }
> 

Re: Scheduler hack for multi-threaded processes

[Miod Vallat]

> I'd like to know if dereferencing ``p_p'' is safe without holding the
> KERNEL_LOCK.

SCHED_LOCK is enough to access p_p->ps_threads,

The construct used to decide whether the process is multi-threaded
already appears twice in sys/kern¸ and your diff adds a third
instance. It is probably worth turning into a macro or an inline
function¸ to make sure there is no risk of the copies becoming
out-of-sync over time.

Re: fan control on macppc G5 smu

[Sevan Janiyan]

On 18/03/2016 12:02, Martin Pieuchot wrote:

Could you test the diff below and tell me if it also helps?  It is
adapted from a submission from Dominic Marks:
https://marc.info/?l=openbsd-ppc=142836014007157=2


It definitely helps here.
As the kernel works its way through probing various devices, the fans 
slow down gradually but continue to run at a much slower rate.

System is a first gen iMac G5.



Sevan


Before:
[ using 560540 bytes of bsd ELF symbol table ]
console out [NVDA,Display-A] console in [keyboard], using USB
using parent NVDA,Parent:: memaddr a000, size 1000 : consaddr 
a0008000 : ioaddr 9100, size 100: width 1440 linebytes 1536 
height 900 depth 8

Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2016 OpenBSD. All rights reserved. 
http://www.OpenBSD.org


OpenBSD 5.9 (GENERIC) #913: Fri Feb 26 03:34:07 MST 2016
dera...@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/GENERIC
real mem = 2147483648 (2048MB)
avail mem = 2055131136 (1959MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root: model PowerMac8,1
cpu0 at mainbus0: 970FX (Revision 0x300): 1800 MHz
mem0 at mainbus0
spdmem0 at mem0: 1GB DDR SDRAM non-parity PC3200CL3.0
spdmem1 at mem0: 1GB DDR SDRAM non-parity PC3200CL3.0
memc0 at mainbus0: u3 rev 0x39
kiic0 at memc0 offset 0xf8001000
iic0 at kiic0
"dart" at memc0 offset 0xf8033000 not configured
"mpic" at memc0 offset 0xf804 not configured
mpcpcibr0 at mainbus0 pci: u3-agp
pci0 at mpcpcibr0 bus 0
pchb0 at pci0 dev 11 function 0 "Apple U3L AGP" rev 0x00
appleagp0 at pchb0
agp0 at appleagp0: aperture at 0x0, size 0x1000
vgafb0 at pci0 dev 16 function 0 "NVIDIA GeForce FX Go 5200" rev 0xa1
wsdisplay0 at vgafb0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
ht0 at mainbus0: u3-ht, 4 devices
pci1 at ht0 bus 0
hpb0 at pci1 dev 1 function 0 "Apple Shasta PCI" rev 0x00: 85 sources
pci2 at hpb0 bus 3
gem0 at pci2 dev 15 function 0 "Apple Shasta GMAC" rev 0x00: irq 40, 
address 00:0d:93:

bmtphy0 at gem0 phy 0: BCM5221 100baseTX PHY, rev. 4
ppb0 at pci1 dev 2 function 0 "Apple Shasta PCI" rev 0x00
pci3 at ppb0 bus 1
macobio0 at pci3 dev 7 function 0 "Apple Shasta" rev 0x00
openpic0 at macobio0 offset 0x4: version 0x4614 feature 7b0302 LE
macgpio0 at macobio0 offset 0x50
"smu-doorbell" at macgpio0 offset 0x12 not configured
"smu-interrupt" at macgpio0 offset 0xd not configured
"programmer-switch" at macgpio0 offset 0xc not configured
"modem-reset" at macgpio0 offset 0x8 not configured
"modem-power" at macgpio0 offset 0x16 not configured
"slewing-done" at macgpio0 offset 0x38 not configured
"amp-mute" at macgpio0 offset 0x30 not configured
"combo-out-sense" at macgpio0 offset 0x29 not configured
"hw-reset" at macgpio0 offset 0x34 not configured
"linein-detect" at macgpio0 offset 0x2a not configured
"lineout-detect" at macgpio0 offset 0x28 not configured
"lineout-mute" at macgpio0 offset 0x2e not configured
"internal-speaker-id" at macgpio0 offset 0x33 not configured
"escc-legacy" at macobio0 offset 0x12000 not configured
zs0 at macobio0 offset 0x13000: irq 23,24
zstty0 at zs0 channel 0
zstty1 at zs0 channel 1
kiic1 at macobio0 offset 0x18000
iic1 at kiic1
onyx0 at macobio0 offset 0x0: irq 28,11,12
"timer" at macobio0 offset 0x15000 not configured
"backlight" at macobio0 offset 0xf300 not configured
audio0 at onyx0
bwi0 at pci3 dev 1 function 0 "Broadcom BCM4306" rev 0x03: irq 60, 
address 00:0a:95:

ohci0 at pci3 dev 11 function 0 "NEC USB" rev 0x43: irq 70, version 1.0
ohci1 at pci3 dev 11 function 1 "NEC USB" rev 0x43: irq 70, version 1.0
ehci0 at pci3 dev 11 function 2 "NEC USB" rev 0x04: irq 70
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "NEC EHCI root hub" rev 2.00/1.00 addr 1
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 "NEC OHCI root hub" rev 1.00/1.00 addr 1
usb2 at ohci1: USB revision 1.0
uhub2 at usb2 "NEC OHCI root hub" rev 1.00/1.00 addr 1
ppb1 at pci1 dev 3 function 0 "Apple Shasta PCI" rev 0x00
pci4 at ppb1 bus 2
pciide0 at pci4 dev 12 function 0 "ServerWorks K2 SATA" rev 0x00: DMA
pciide0: using irq 10 for native-PCI interrupt
pciide0: port 0: 1.5Gb/s
wd0 at pciide0 channel 0 drive 0: 
wd0: 16-sector PIO, LBA48, 305244MB, 625140335 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 6
pciide0: port 1: PHY offline
kauaiata0 at pci4 dev 13 function 0 "Apple Shasta ATA" rev 0x00
wdc0 at kauaiata0 irq 38: DMA
atapiscsi0 at wdc0 channel 0 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0:  ATAPI 
5/cdrom removable

cd0(wdc0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 4
"Apple Shasta Firewire" rev 0x00 at pci4 dev 14 function 0 not configured
smu0 at mainbus0
iic2 at smu0
lmtemp0 at iic2 addr 0x49: lm75
"smu-pulsar" at iic2 addr 0x6a not configured
uhub3 at uhub0 port 1 "Apple, Inc. Keyboard Hub" rev 2.00/95.15 addr 2
uhidev0 at 

Insufficient checks in IPv6 socket binding and UDP IPv6 option processing missing in OpenSBD_5_9 cvs tree

[Ian Mcwilliam]

http://ftp.openbsd.org/pub/OpenBSD/patches/5.9/common/002_in6bind.patch.sig

002: SECURITY FIX: March 16, 2016   All architectures
Insufficient checks in IPv6 socket binding and UDP IPv6 option processing allow 
a local user to send UDP packets with a source (IPv6 address + port) already 
reserved by another user. 

This hasn't been committed to OpenBSD_5_9. Maybe an oversight.

Ian McWilliam

Re: SSLv3 and Internet Printing Protocol requirements problem

[Bob Beck]

> But it officially requires support for IPP version 1.0, which used
> SSLv3.
> I assume that there are printers, perhaps many were sold, which did use
> version 1.0. That version used SSLv3 for encrypted communication. Which
> is now gone.

Almost certainly.

>
> How should we deal with this problem?

Here's a nickel kid - buy a better printer?

Seriously. we just won't be conformant. These protocols are designed
by industry consortiums who want to sell product at lowest cost, not
care about security.   If you seriously must have insecure stuff,
well, that's why OpenSSL still exists, you can always build with that.

Re: dwctwo(4) matching on Octeon

[Masao Uebayashi]

OK uebayasi@

On Sat, Mar 19, 2016 at 02:51:56PM +, Visa Hankala wrote:
> dwctwo(4) should be attached only on those Octeon models that have the
> DWC2 controller. The list below is not complete but it covers every
> model that has any chance of working with cnmac(4).
> 
> OK?
> 
> Index: arch/octeon/dev/octdwctwo.c
> ===
> RCS file: src/sys/arch/octeon/dev/octdwctwo.c,v
> retrieving revision 1.9
> diff -u -p -r1.9 octdwctwo.c
> --- arch/octeon/dev/octdwctwo.c   1 Sep 2015 14:45:24 -   1.9
> +++ arch/octeon/dev/octdwctwo.c   19 Mar 2016 14:22:47 -
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -123,7 +124,17 @@ bus_space_t octdwctwo_tag = {
>  int
>  octdwctwo_match(struct device *parent, void *match, void *aux)
>  {
> - return (1);
> + int id;
> +
> + id = octeon_get_chipid();
> + switch (octeon_model_family(id)) {
> + case OCTEON_MODEL_FAMILY_CN30XX:
> + case OCTEON_MODEL_FAMILY_CN31XX:
> + case OCTEON_MODEL_FAMILY_CN50XX:
> + return (1);
> + default:
> + return (0);
> + }
>  }
>  
>  void
> 

Re: New scheduler for OpenBSD

[lists]

Fri, 18 Mar 2016 13:04:49 -0600 Theo de Raadt 
> > So I'm skeptical about this BFS scheduler.  Don't get me wrong; I do
> > think the scheduler needs attention.  But I'm not sure a scheduler
> > designed for interactive desktop use is the best option for OpenBSD.
> > I'm willing to be proven wrong.  But that means we need careful
> > benchmarking on a wide variety of workloads and hardware.  
> 
> I don't think this scheduler is making things better because of
> it's scheduling behaviour.
> 
> I think the scheduling choices it makes are hiding a poor-performing
> artifact we have elsewhere.

One can recommend the proposing entity to be able to devise multiple
schedulers and compare these, before qualifying for justification of
decisions taken.  And to be available to maintain the work proposed.

dwctwo(4) matching on Octeon

[Visa Hankala]

dwctwo(4) should be attached only on those Octeon models that have the
DWC2 controller. The list below is not complete but it covers every
model that has any chance of working with cnmac(4).

OK?

Index: arch/octeon/dev/octdwctwo.c
===
RCS file: src/sys/arch/octeon/dev/octdwctwo.c,v
retrieving revision 1.9
diff -u -p -r1.9 octdwctwo.c
--- arch/octeon/dev/octdwctwo.c 1 Sep 2015 14:45:24 -   1.9
+++ arch/octeon/dev/octdwctwo.c 19 Mar 2016 14:22:47 -
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -123,7 +124,17 @@ bus_space_t octdwctwo_tag = {
 int
 octdwctwo_match(struct device *parent, void *match, void *aux)
 {
-   return (1);
+   int id;
+
+   id = octeon_get_chipid();
+   switch (octeon_model_family(id)) {
+   case OCTEON_MODEL_FAMILY_CN30XX:
+   case OCTEON_MODEL_FAMILY_CN31XX:
+   case OCTEON_MODEL_FAMILY_CN50XX:
+   return (1);
+   default:
+   return (0);
+   }
 }
 
 void

Re: Scheduler hack for multi-threaded processes

[Todd Mortimer]

On Sat, Mar 19, 2016 at 01:53:07PM +0100, Martin Pieuchot wrote:
> I experimented with various values for "p_priority" and this one is
> the one that generates fewer # IPIs when watching a HD video on firefox. 
> Because yes, with this diff, now I can.

Same result here: Video in firefox plays nicely with this patch, where
before it was choppy. Running amd64 in a 2xCPU VMware box. 

Todd

rtwn chip id

[Stefan Sperling]

The common part of rtwn(4) needs help from attachment drivers to
determine the chip type. The PCI/USB driver parts must detect the
chip type based on PCI/USB vendor and device IDs. There seems to be no
other way of doing this. Even the Linux vendor driver does it this way.

The common part is still responsible for details of a particular chip type,
such as the amount of transmit and receive chains provided by the chip.

This paves the way for future 8188EE chip support in ic/rtwn.c.

Tested on 8188CE (RTWN_CHIP_88C, PCI).

Index: ic/rtwn.c
===
RCS file: /cvs/src/sys/dev/ic/rtwn.c,v
retrieving revision 1.5
diff -u -p -r1.5 rtwn.c
--- ic/rtwn.c   15 Mar 2016 10:28:31 -  1.5
+++ ic/rtwn.c   19 Mar 2016 13:30:03 -
@@ -84,7 +84,7 @@ uint32_t  rtwn_rf_read(struct rtwn_softc 
 void   rtwn_cam_write(struct rtwn_softc *, uint32_t, uint32_t);
 uint8_trtwn_efuse_read_1(struct rtwn_softc *, uint16_t);
 void   rtwn_efuse_read(struct rtwn_softc *);
-intrtwn_read_chipid(struct rtwn_softc *);
+intrtwn_read_chipid(struct rtwn_softc *, uint32_t);
 void   rtwn_read_rom(struct rtwn_softc *);
 intrtwn_media_change(struct ifnet *);
 intrtwn_ra_init(struct rtwn_softc *);
@@ -140,7 +140,7 @@ voidrtwn_stop(struct ifnet *);
 #define rtwn_bb_read   rtwn_read_4
 
 int
-rtwn_attach(struct device *pdev, struct rtwn_softc *sc)
+rtwn_attach(struct device *pdev, struct rtwn_softc *sc, uint32_t chip_type)
 {
struct ieee80211com *ic = >sc_ic;
struct ifnet *ifp = >ic_if;
@@ -150,17 +150,21 @@ rtwn_attach(struct device *pdev, struct 
 
task_set(>init_task, rtwn_init_task, sc);
 
-   error = rtwn_read_chipid(sc);
+   error = rtwn_read_chipid(sc, chip_type);
if (error != 0) {
printf("%s: unsupported test chip\n", sc->sc_pdev->dv_xname);
return (ENXIO);
}
+   if (sc->chip == 0) {
+   printf("%s: could not read chip ID\n", sc->sc_pdev->dv_xname);
+   return (ENXIO);
+   }
 
/* Determine number of Tx/Rx chains. */
if (sc->chip & RTWN_CHIP_92C) {
sc->ntxchains = (sc->chip & RTWN_CHIP_92C_1T2R) ? 1 : 2;
sc->nrxchains = 2;
-   } else {
+   } else if (sc->chip & RTWN_CHIP_88C) {
sc->ntxchains = 1;
sc->nrxchains = 1;
}
@@ -475,9 +479,8 @@ rtwn_efuse_read(struct rtwn_softc *sc)
 #endif
 }
 
-/* rtwn_read_chipid: reg=0x40073b chipid=0x0 */
 int
-rtwn_read_chipid(struct rtwn_softc *sc)
+rtwn_read_chipid(struct rtwn_softc *sc, uint32_t chip_type)
 {
uint32_t reg;
 
@@ -486,18 +489,22 @@ rtwn_read_chipid(struct rtwn_softc *sc)
/* Unsupported test chip. */
return (EIO);
 
-   if (reg & R92C_SYS_CFG_TYPE_92C) {
-   sc->chip |= RTWN_CHIP_92C;
-   /* Check if it is a castrated 8192C. */
-   if (MS(rtwn_read_4(sc, R92C_HPON_FSM),
-   R92C_HPON_FSM_CHIP_BONDING_ID) ==
-   R92C_HPON_FSM_CHIP_BONDING_ID_92C_1T2R)
-   sc->chip |= RTWN_CHIP_92C_1T2R;
-   }
-   if (reg & R92C_SYS_CFG_VENDOR_UMC) {
-   sc->chip |= RTWN_CHIP_UMC;
-   if (MS(reg, R92C_SYS_CFG_CHIP_VER_RTL) == 0)
-   sc->chip |= RTWN_CHIP_UMC_A_CUT;
+   if ((chip_type & (RTWN_CHIP_92C | RTWN_CHIP_88C)) != 0) {
+   if (reg & R92C_SYS_CFG_TYPE_92C) {
+   sc->chip = RTWN_CHIP_92C;
+   /* Check if it is a castrated 8192C. */
+   if (MS(rtwn_read_4(sc, R92C_HPON_FSM),
+   R92C_HPON_FSM_CHIP_BONDING_ID) ==
+   R92C_HPON_FSM_CHIP_BONDING_ID_92C_1T2R)
+   sc->chip |= RTWN_CHIP_92C_1T2R;
+   } else
+   sc->chip = RTWN_CHIP_88C;
+
+   if (reg & R92C_SYS_CFG_VENDOR_UMC) {
+   sc->chip |= RTWN_CHIP_UMC;
+   if (MS(reg, R92C_SYS_CFG_CHIP_VER_RTL) == 0)
+   sc->chip |= RTWN_CHIP_UMC_A_CUT;
+   }
}
return (0);
 }
Index: ic/rtwnvar.h
===
RCS file: /cvs/src/sys/dev/ic/rtwnvar.h,v
retrieving revision 1.4
diff -u -p -r1.4 rtwnvar.h
--- ic/rtwnvar.h15 Mar 2016 10:28:31 -  1.4
+++ ic/rtwnvar.h19 Mar 2016 12:14:43 -
@@ -49,16 +49,17 @@ struct rtwn_softc {
enum ieee80211_state, int);
struct task init_task;
int ac2idx[EDCA_NUM_AC];
-   u_int   sc_flags;
+   uint32_tsc_flags;
 #define RTWN_FLAG_CCK_HIPWR0x01
 #define 

Re: Scheduler hack for multi-threaded processes

[Edd Barrett]

On Sat, Mar 19, 2016 at 01:53:07PM +0100, Martin Pieuchot wrote:
> I experimented with various values for "p_priority" and this one is
> the one that generates fewer # IPIs when watching a HD video on firefox. 
> Because yes, with this diff, now I can.

Works well here in firefox too.

Will run this diff for a few days and let you know if anything bad
happens.

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

vnet(4) memory leak

[Stefan Sperling]

A sparc64 machine of mine crashes every few weeks because the kernel
runs out of memory.

The crash usually happens in a malloc call in the vnet(4) ioctl code path.
I have a cronjob which downs/up vnet interfaces in case they get stuck in
OACTIVE (another bug which, AFAIK, is not solved yet). So this machine runs
vnet's ioctl code path every now and then.

Yesterday it crashed again. The machine was still running a snap from Feb 2.
kettenis@ has fixed one memory leak in vnet since. I believe I may have
found another leak, which is addresssed by the diff below.

Is this diff correct? My machine is now running with it.

Index: vnet.c
===
RCS file: /cvs/src/sys/arch/sparc64/dev/vnet.c,v
retrieving revision 1.54
diff -u -p -r1.54 vnet.c
--- vnet.c  26 Feb 2016 13:41:51 -  1.54
+++ vnet.c  19 Mar 2016 10:42:06 -
@@ -169,6 +169,7 @@ struct vnet_softc {
struct ldc_map  *sc_lm;
struct vnet_dring *sc_vd;
struct vnet_soft_desc *sc_vsd;
+#define VNET_NUM_SOFT_DESC 128
 
size_t  sc_peer_desc_size;
struct ldc_cookie sc_peer_dring_cookie;
@@ -1399,10 +1400,10 @@ vnet_init(struct ifnet *ifp)
return;
}
 
-   sc->sc_vd = vnet_dring_alloc(sc->sc_dmatag, 128);
+   sc->sc_vd = vnet_dring_alloc(sc->sc_dmatag, VNET_NUM_SOFT_DESC);
if (sc->sc_vd == NULL)
return;
-   sc->sc_vsd = malloc(128 * sizeof(*sc->sc_vsd), M_DEVBUF,
+   sc->sc_vsd = malloc(VNET_NUM_SOFT_DESC * sizeof(*sc->sc_vsd), M_DEVBUF,
M_NOWAIT|M_ZERO);
if (sc->sc_vsd == NULL)
return;
@@ -1453,6 +1454,8 @@ vnet_stop(struct ifnet *ifp)
lc->lc_state = 0;
lc->lc_tx_state = lc->lc_rx_state = LDC_CHANNEL_DOWN;
vnet_ldc_reset(lc);
+
+   free(sc->sc_vsd, M_DEVBUF, VNET_NUM_SOFT_DESC * sizeof(*sc->sc_vsd));
 
vnet_dring_free(sc->sc_dmatag, sc->sc_vd);
 

Re: New scheduler for OpenBSD

[Theo de Raadt]

> So I'm skeptical about this BFS scheduler.  Don't get me wrong; I do
> think the scheduler needs attention.  But I'm not sure a scheduler
> designed for interactive desktop use is the best option for OpenBSD.
> I'm willing to be proven wrong.  But that means we need careful
> benchmarking on a wide variety of workloads and hardware.

I don't think this scheduler is making things better because of
it's scheduling behaviour.

I think the scheduling choices it makes are hiding a poor-performing
artifact we have elsewhere.

Re: New scheduler for OpenBSD

[Edd Barrett]

On Thu, Mar 17, 2016 at 09:26:08PM +0100, Henrik Friedrichsen wrote:
> On Tue, Mar 15, 2016 at 03:05:47PM +0100, Michal Mazurek wrote:
> > Chrome still isn't smooth.
> > 
> > Please test, and let me know if the performance of something else
> > degrades.
> 
> While Chrome may not be 100% smooth yet, the system is a lot more
> interactive. I can now play YouTube videos without stutters while doing
> other things.

I can't vouch for the code, but this makes video playback in firefox
usable on my x240t. Before it would stutter beyond belief.

I'll run with this for a while and let you know if anything comes up.

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: CPUID in amd64/i386 boot code

[Theo de Raadt]

> Factor out CPUID code in mdrandom(), invoke it once, then save the
> result.  I'll use it to switch behavior depending on HV or not.
> 
> efiboot is not tested.
> 
> Comments?

I don't understand the purpose of the refactoring.

Scheduler hack for multi-threaded processes

[Martin Pieuchot]

Applications using multiple threads often call sched_yield(2) to
indicate that one of the threads cannot make any progress because
it is waiting for a resource held by another one.

One example of this scenario is the _spinlock() implementation of
our librthread.  But if you look on https://codesearch.debian.net
you can find much more use cases, notably MySQL, PostgreSQL, JDK,
libreoffice, etc.

Now the problem with our current scheduler is that the priority of
a thread decreases when it is the "curproc" of a CPU.  So the threads
that don't run and sched_yield(2) end up having a higher priority than
the thread holding the resource.  Which means that it's really hard for
such multi-threaded applications to make progress, resulting in a lot of
IPIs numbers.
That'd also explain why if you have a more CPUs, let's say 4 instead
of 2, your application will more likely make some progress and you'll
see less sluttering/freezing.

So what the diff below does is that it penalizes the threads from
multi-threaded applications such that progress can be made.  It is
inspired from the recent scheduler work done by Michal Mazurek on
tech@.

I experimented with various values for "p_priority" and this one is
the one that generates fewer # IPIs when watching a HD video on firefox. 
Because yes, with this diff, now I can.

I'd like to know if dereferencing ``p_p'' is safe without holding the
KERNEL_LOCK.

I'm also interested in hearing from more people using multi-threaded
applications.

Index: kern/sched_bsd.c
===
RCS file: /cvs/src/sys/kern/sched_bsd.c,v
retrieving revision 1.43
diff -u -p -r1.43 sched_bsd.c
--- kern/sched_bsd.c9 Mar 2016 13:38:50 -   1.43
+++ kern/sched_bsd.c19 Mar 2016 12:21:36 -
@@ -298,7 +298,16 @@ yield(void)
int s;
 
SCHED_LOCK(s);
-   p->p_priority = p->p_usrpri;
+   /*
+* If one of the threads of a multi-threaded process called
+* sched_yield(2), drop its priority to ensure its siblings
+* can make some progress.
+*/
+   if (TAILQ_FIRST(>p_p->ps_threads) == p &&
+   TAILQ_NEXT(p, p_thr_link) == NULL)
+   p->p_priority = p->p_usrpri;
+   else
+   p->p_priority = min(MAXPRI, p->p_usrpri * 2);
p->p_stat = SRUN;
setrunqueue(p);
p->p_ru.ru_nvcsw++;

Re: New scheduler for OpenBSD

[Edd Barrett]

On Sat, Mar 19, 2016 at 09:06:26AM +0100, Alexandre Ratchov wrote:
> The browsers problems seem caused by the way pthreads behave;
> browsers appear to spin.  With the proposed scheduler they spin
> less.  But the real question is why they spin at all?

Inspired by this comment, I set out to see if I could find *where* the browsers
are spinning. "Just build the browsers with profiling instrumentation and look
where the time goes when playing a youtube video" I thought. "Easy" I thought.

Well no. We build our chrome and firefox with clang, which doesn't
support gprof style profiling.

Clang does have this -fprofile-instr-generate flag, which throws out some
profiling data at runtime, but it appears it is designed to be used by the
compiler itself as compile-time optimisation hints[1]. It's not even clear if
there is any timing data in there.

There's another clang profiling mode which depends upon Linux perf, which is
obviously not an option for us.

Nevertheless, I decided to try it on the off-chance that clang's profiling data
could be useful (and I'm totally accepting that, if it is, I will probably have
to write a python script to make sense of the output). Sadly I stumbled at the
first hurdle:

---8<---
$ cat a.c
#include 
#include 

int
main(int argc, char **argv)
{
return (EXIT_SUCCESS);
}
$clang -fprofile-instr-generate a.c -lclang
/usr/local/lib/libclang.so.2.0: warning: warning: sprintf() is often misused, 
please use snprintf()
/tmp/a-f91c15.o: In function `__llvm_profile_register_functions':
a.c:(.text+0x3c): undefined reference to `__llvm_profile_register_function'
/tmp/a-f91c15.o: In function `__llvm_profile_runtime_user':
a.c:(.text+0x53): undefined reference to `__llvm_profile_runtime'
clang-3.7: error: linker command failed with exit code 1 (use -v to see 
invocation)
--->8---

Any clang afficionados know what is missing here? Or is there a better way to
find the spinning code? There has to be a better way.

A potential option would be to port and use the profiling portion of [2].

[1] http://clang.llvm.org/docs/UsersManual.html#profile-guided-optimization
[2] https://github.com/gperftools/gperftools

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk

Re: Octeon II usb

[Visa Hankala]

On Thu, Mar 17, 2016 at 11:51:19AM +1000, Jonathan Matthew wrote:
> I've had this sitting around for a while and I figure it's time to get it in
> the tree.  Octeon II sensibly got rid of the DWC USB controller and put in 
> ehci
> and ohci compliant controllers instead, so all we need to do here is set up a
> few registers in the usb controller interface and attach the standard drivers.
> The diff below adds octuctl, a driver for the usb controller interface, and 
> octehci and octohci, which are attachments for ehci and ohci.
> 
> I've tested this on a Lanner MR326b, where it allows me to boot off a usb
> stick, and on an Edgerouter Lite, where it makes no difference at all.
> 
> ok?

The patch seems to work fine on an EdgeRouter Pro.

OK visa@

> Index: conf/GENERIC
> ===
> RCS file: /cvs/src/sys/arch/octeon/conf/GENERIC,v
> retrieving revision 1.24
> diff -u -p -u -p -r1.24 GENERIC
> --- conf/GENERIC  14 Jan 2016 17:20:34 -  1.24
> +++ conf/GENERIC  17 Mar 2016 01:43:51 -
> @@ -64,9 +64,14 @@ wd*at pciide? flags 0x
>  
>  # USB Controllers
>  dwctwo0  at iobus? irq 56
> +octuctl0 at iobus? irq 56
> +ehci0at octuctl?
> +ohci0at octuctl?
>  
>  # USB bus support
>  usb* at dwctwo?
> +usb* at ehci?
> +usb* at ohci?
>  
>  # USB devices
>  uhub*at usb? # USB Hubs
> Index: conf/RAMDISK
> ===
> RCS file: /cvs/src/sys/arch/octeon/conf/RAMDISK,v
> retrieving revision 1.23
> diff -u -p -u -p -r1.23 RAMDISK
> --- conf/RAMDISK  14 Jan 2016 17:20:34 -  1.23
> +++ conf/RAMDISK  17 Mar 2016 01:43:51 -
> @@ -55,7 +55,14 @@ pciide*at pci? flags 0x
>  wd*  at pciide? flags 0x
>  
>  dwctwo0  at iobus0 irq 56
> +octuctl0 at iobus0 irq 56
> +ehci0at octuctl?
> +ohci0at octuctl?
> +
>  usb* at dwctwo?
> +usb* at ehci?
> +usb* at ohci?
> +
>  uhub*at usb?
>  uhub*at uhub?
>  umass*   at uhub?
> Index: conf/files.octeon
> ===
> RCS file: /cvs/src/sys/arch/octeon/conf/files.octeon,v
> retrieving revision 1.28
> diff -u -p -u -p -r1.28 files.octeon
> --- conf/files.octeon 14 Jan 2016 17:20:34 -  1.28
> +++ conf/files.octeon 17 Mar 2016 01:43:51 -
> @@ -71,6 +71,14 @@ file   arch/octeon/dev/cn30xxsmi.c 
> iobus
>  attach   dwctwo at iobus with octdwctwo
>  file arch/octeon/dev/octdwctwo.c octdwctwo   
> needs-flag
>  
> +device   octuctl {}
> +attach   octuctl at iobus
> +file arch/octeon/dev/octuctl.c   octuctl 
> needs-flag
> +attach   ehci at octuctl with octehci
> +file arch/octeon/dev/octehci.c   octehci
> +attach   ohci at octuctl with octohci
> +file arch/octeon/dev/octohci.c   octohci
> +
>  # On-board CF
>  device   octcf: disk
>  attach   octcf at iobus
> Index: dev/octehci.c
> ===
> RCS file: dev/octehci.c
> diff -N dev/octehci.c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ dev/octehci.c 17 Mar 2016 01:43:52 -
> @@ -0,0 +1,118 @@
> +/*   $OpenBSD$ */
> +
> +/*
> + * Copyright (c) 2015 Jonathan Matthew  
> + *
> + * Permission to use, copy, modify, and/or distribute this software for any
> + * purpose with or without fee is hereby granted, provided that the above
> + * copyright notice and this permission notice appear in all copies.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +struct octehci_softc {
> + struct ehci_softc   sc_ehci;
> +
> + void*sc_ih;
> +};
> +
> +int  octehci_match(struct device *, void *, void *);
> +void octehci_attach(struct device *, struct device *, void *);
> +
> +const struct cfattach octehci_ca = {
> + sizeof(struct octehci_softc), octehci_match, octehci_attach,
> +};
> +
> +struct cfdriver octehci_cd = {
> +

Re: Rename the global variable ``ticks''

[Mark Kettenis]

> Date: Thu, 17 Mar 2016 21:02:03 +0100
> From: Martin Pieuchot 
> 
> ``ticks'' is in my opinion a really badly named global variable.  But we
> all know that finding names is hard ;)
> 
> Since its popularity seems to be really high lately, I'd suggest to
> rename it.  I chose ``hcticks'' for "hardclock ticks".  I believe this
> would help auditing the possible existing and/or future conditions
> leading to overflow.
> 
> As a bonus this diff removes all the "extern hcticks;" declaration and
> include  instead.
> 
> Opinions?

I don't like this kind of reshuffling.  I don't think there is
anything wrong with the current name.

> PS: I missed 4 conversions in my previous diff, can you find them?
> 
> diff --git sys/dev/atapiscsi/atapiscsi.c sys/dev/atapiscsi/atapiscsi.c
> index df5c45b..be164ea 100644
> --- sys/dev/atapiscsi/atapiscsi.c
> +++ sys/dev/atapiscsi/atapiscsi.c
> @@ -613,7 +613,6 @@ wdc_atapi_the_machine(struct channel_softc *chp, struct 
> wdc_xfer *xfer,
>  enum atapi_context ctxt)
>  {
>   int idx = 0;
> - extern int ticks;
>   int timeout_delay = hz / 10;
>  
>   if (xfer->c_flags & C_POLL) {
> @@ -637,7 +636,7 @@ wdc_atapi_the_machine(struct channel_softc *chp, struct 
> wdc_xfer *xfer,
>   struct atapi_return_args retargs = ARGS_INIT;
>  
>   (xfer->next)(chp, xfer,
> - xfer->endticks && (ticks - xfer->endticks >= 0),
> + xfer->endticks && (hcticks - xfer->endticks >= 0),
>   );
>  
>   if (retargs.timeout != -1)
> @@ -646,7 +645,7 @@ wdc_atapi_the_machine(struct channel_softc *chp, struct 
> wdc_xfer *xfer,
>* can be just microseconds before the tick changes.
>*/
>   xfer->endticks =
> - max((retargs.timeout * hz) / 1000, 1) + 1 + ticks;
> + max((retargs.timeout * hz) / 1000, 1) + 1 + hcticks;
>  
>   if (xfer->next == NULL) {
>   if (xfer->c_flags & C_POLL_MACHINE)
> @@ -661,7 +660,7 @@ wdc_atapi_the_machine(struct channel_softc *chp, struct 
> wdc_xfer *xfer,
>   if (retargs.expect_irq) {
>   int timeout_period;
>   chp->ch_flags |= WDCF_IRQ_WAIT;
> - timeout_period =  xfer->endticks - ticks;
> + timeout_period =  xfer->endticks - hcticks;
>   if (timeout_period < 1)
>   timeout_period = 1;
>   timeout_add(>ch_timo, timeout_period);
> diff --git sys/dev/ic/ar5008.c sys/dev/ic/ar5008.c
> index d3ad6c9..fa1c1e9 100644
> --- sys/dev/ic/ar5008.c
> +++ sys/dev/ic/ar5008.c
> @@ -2381,8 +2381,7 @@ ar5008_hw_init(struct athn_softc *sc, struct 
> ieee80211_channel *c,
>   ar5008_init_chains(sc);
>  
>   if (sc->flags & ATHN_FLAG_OLPC) {
> - extern int ticks;
> - sc->olpc_ticks = ticks;
> + sc->olpc_ticks = hcticks;
>   ops->olpc_init(sc);
>   }
>  
> diff --git sys/dev/ic/athn.c sys/dev/ic/athn.c
> index 03460ef..df2b9b1 100644
> --- sys/dev/ic/athn.c
> +++ sys/dev/ic/athn.c
> @@ -1218,7 +1218,6 @@ athn_iter_func(void *arg, struct ieee80211_node *ni)
>  void
>  athn_calib_to(void *arg)
>  {
> - extern int ticks;
>   struct athn_softc *sc = arg;
>   struct athn_ops *ops = >ops;
>   struct ieee80211com *ic = >sc_ic;
> @@ -1229,8 +1228,8 @@ athn_calib_to(void *arg)
>   /* Do periodic (every 4 minutes) PA calibration. */
>   if (AR_SREV_9285_11_OR_LATER(sc) &&
>   !AR_SREV_9380_10_OR_LATER(sc) &&
> - (ticks - (sc->pa_calib_ticks + 240 * hz)) >= 0) {
> - sc->pa_calib_ticks = ticks;
> + (hcticks - (sc->pa_calib_ticks + 240 * hz)) >= 0) {
> + sc->pa_calib_ticks = hcticks;
>   if (AR_SREV_9271(sc))
>   ar9271_pa_calib(sc);
>   else
> @@ -1239,8 +1238,8 @@ athn_calib_to(void *arg)
>  
>   /* Do periodic (every 30 seconds) temperature compensation. */
>   if ((sc->flags & ATHN_FLAG_OLPC) &&
> - ticks >= sc->olpc_ticks + 30 * hz) {
> - sc->olpc_ticks = ticks;
> + hcticks >= sc->olpc_ticks + 30 * hz) {
> + sc->olpc_ticks = hcticks;
>   ops->olpc_temp_compensation(sc);
>   }
>  
> @@ -1279,8 +1278,7 @@ athn_init_calib(struct athn_softc *sc, struct 
> ieee80211_channel *c,
>   if (!AR_SREV_9380_10_OR_LATER(sc)) {
>   /* Do PA calibration. */
>   if (AR_SREV_9285_11_OR_LATER(sc)) {
> - extern int ticks;
> - sc->pa_calib_ticks = ticks;
> + sc->pa_calib_ticks = hcticks;
>   if (AR_SREV_9271(sc))
>   ar9271_pa_calib(sc);
>   else
> diff --git sys/dev/ic/bwi.c sys/dev/ic/bwi.c
> index d612db3..7514e29 

Re: CPUID in amd64/i386 boot code

[Theo de Raadt]

The process I see here the submission of 2 seperate diffs to
the bootblocks, requiring people to take two steps.

Then readers of tech@ will realize that the proposition is to
test their bootblocks right away, many will balk.

The diffs also do not come with a report as to what machines were
tested, only a description of the problem it is purposed to solve,
that is scary, so even more people will shy from participating.
Anyone left?

What path do you propose forward to getting this tested?  This
submission format I see here, is rather unlikely to move forward
without a more guidance

Re: fan control on macppc G5 smu

[Martin Pieuchot]

On 31/01/16(Sun) 23:47, Olivier Cherrier wrote:
>   Hi,
> 
> It may not be the proper solution to control the fans on macppc smu (G5)
> but the following patch allows me to work with my iMac G5 without
> losing my hearing capacity ...
> 
> 
> 
> $ sysctl hw.sensors
> hw.sensors.smu0.temp0=44.72 degC (CPU T-Diode)
> hw.sensors.smu0.fan0=1530 RPM (System Fan)
> hw.sensors.smu0.fan1=1530 RPM (CPU fan)
> hw.sensors.smu0.fan2=1530 RPM (Hard Drive)
> hw.sensors.smu0.volt0=11.87 VDC (CPU Voltage)
> hw.sensors.smu0.current0=0.63 A (CPU Current)
> hw.sensors.lmtemp0.temp0=51.00 degC
> $
> 
> The fan range are:
>   smu0 at mainbus0
>   system: min-value: 1000
>   system: max-value: 4000
>   system: unmanage-value: 4000
>   cpu: min-value: 1500
>   cpu: max-value: 4400
>   cpu: unmanage-value: 4400
>   hd: min-value: 1800
>   hd: max-value: 6000
>   hd: unmanage-value: 6000

Could you test the diff below and tell me if it also helps?  It is
adapted from a submission from Dominic Marks:
https://marc.info/?l=openbsd-ppc=142836014007157=2

Index: dev/smu.c
===
RCS file: /cvs/src/sys/arch/macppc/dev/smu.c,v
retrieving revision 1.27
diff -u -p -r1.27 smu.c
--- dev/smu.c   4 Jun 2015 18:01:44 -   1.27
+++ dev/smu.c   18 Mar 2016 11:58:23 -
@@ -54,6 +54,13 @@ struct smu_sensor {
struct ksensor  sensor;
 };
 
+/* SMU CPU T-Diode sensor. */
+#define SMU_CPU_TEMP   0
+
+/* CPU temperature boundaries in muK. */
+#define CPU_TEMP_MAX   (80 * 100 + 27315) 
+#define CPU_TEMP_MIN   (30 * 100 + 27315) 
+
 struct smu_softc {
 struct device   sc_dev;
 
@@ -145,8 +152,9 @@ int smu_time_write(time_t);
 intsmu_get_datablock(struct smu_softc *sc, u_int8_t, u_int8_t *, size_t);
 intsmu_fan_set_rpm(struct smu_softc *, struct smu_fan *, u_int16_t);
 intsmu_fan_refresh(struct smu_softc *, struct smu_fan *);
+intsmu_fan_adjust(struct smu_softc *, struct smu_fan *, u_int64_t);
 intsmu_sensor_refresh(struct smu_softc *, struct smu_sensor *);
-void   smu_refresh_sensors(void *);
+void   smu_refresh(void *);
 
 intsmu_i2c_acquire_bus(void *, int);
 void   smu_i2c_release_bus(void *, int);
@@ -365,7 +373,7 @@ smu_attach(struct device *parent, struct
sc->sc_slots_pow_scale = (data[4] << 8) + data[5];
sc->sc_slots_pow_offset = (data[6] << 8) + data[7];
 
-   sensor_task_register(sc, smu_refresh_sensors, 5);
+   sensor_task_register(sc, smu_refresh, 5);
 #endif /* !SMALL_KERNEL */
printf("\n");
 
@@ -643,9 +651,10 @@ smu_sensor_refresh(struct smu_softc *sc,
 }
 
 void
-smu_refresh_sensors(void *arg)
+smu_refresh(void *arg)
 {
struct smu_softc *sc = arg;
+   struct ksensor *ks;
int i;
 
rw_enter_write(>sc_lock);
@@ -653,6 +662,10 @@ smu_refresh_sensors(void *arg)
smu_sensor_refresh(sc, >sc_sensors[i]);
for (i = 0; i < sc->sc_num_fans; i++)
smu_fan_refresh(sc, >sc_fans[i]);
+   if (sensor_find(0, SENSOR_TEMP, SMU_CPU_TEMP, ) == 0) {
+   for (i = 0; i < sc->sc_num_fans; i++)
+   smu_fan_adjust(sc, >sc_fans[i], ks->value);
+   }
rw_exit_write(>sc_lock);
 }
 
@@ -754,4 +767,22 @@ smu_slew_voltage(u_int freq_scale)
smu_do_cmd(sc, 250);
 
rw_exit_write(>sc_lock);
+}
+
+int
+smu_fan_adjust(struct smu_softc *sc, struct smu_fan *fan, u_int64_t ctemp)
+{
+   u_int16_t rpm;;
+
+   if (ctemp < CPU_TEMP_MIN) {
+   rpm = fan->min_rpm;
+   } else if (ctemp < CPU_TEMP_MAX) {
+   rpm = fan->min_rpm + (ctemp - CPU_TEMP_MIN) *
+   (fan->max_rpm - fan->min_rpm) /
+   (CPU_TEMP_MAX - CPU_TEMP_MIN);
+   } else {
+   rpm = fan->max_rpm;
+   }
+
+   return smu_fan_set_rpm(sc, fan, rpm);
 }

Re: kern_sched.c: unused functions

[Mike Belopuhov]

On Wed, Mar 16, 2016 at 22:18 -0400, Michael McConville wrote:
> Michal Mazurek wrote:
> > On 17:19:39,  2.03.16, Martin Natano wrote:
> > > On Wed, Mar 02, 2016 at 05:07:21PM +0100, Michal Mazurek wrote:
> > > > kern_sched.c:
> > > > - remove unused functions
> > > > - mark static functions as static
> > > 
> > > Functions shouldn't be static in the kernel. "In userland,
> > > functions local to one source module should be declared ???static???.  
> > > This
> > > should not be done in kernel land since it makes it impossible to use the
> > > kernel debugger." -- style(8)
> > 
> > Oh, right.
> > 
> > Remove cpuset_clear(), cpuset_add_all() and cpuset_union(), and move
> > some declarations from proc.h to kern_sched.c.
> 
> ok mmcc@, pending an ok from someone who works with this code.
>

Art has implemented a complete API for sets (in a mathematical sense)
and I don't see how removing the set union operation helps anything.
The fact is that it's unused right now doesn't mean it's useless,
it just means that the cpuset API is complete in a way of simple
set operations.

I don't have any strong opinions on the rest of removed functions,
but cpuset_clear might be useful /in theory/.

Please don't remove cpuset_union.

> > Index: sys/kern/kern_sched.c
> > ===
> > RCS file: /cvs/src/sys/kern/kern_sched.c,v
> > retrieving revision 1.41
> > diff -u -p -r1.41 kern_sched.c
> > --- sys/kern/kern_sched.c   23 Dec 2015 14:51:17 -  1.41
> > +++ sys/kern/kern_sched.c   2 Mar 2016 16:37:18 -
> > @@ -28,11 +28,18 @@
> >  
> >  #include 
> >  
> > -void sched_kthreads_create(void *);
> > -
> > -int sched_proc_to_cpu_cost(struct cpu_info *ci, struct proc *p);
> > +voidsched_kthreads_create(void *);
> > +int sched_proc_to_cpu_cost(struct cpu_info *ci, struct proc *p);
> >  struct proc *sched_steal_proc(struct cpu_info *);
> >  
> > +voidcpuset_complement(struct cpuset *, struct cpuset *, struct 
> > cpuset *);
> > +voidcpuset_copy(struct cpuset *, struct cpuset *);
> > +struct cpu_info *cpuset_first(struct cpuset *);
> > +voidcpuset_del(struct cpuset *, struct cpu_info *);
> > +voidcpuset_init_cpu(struct cpu_info *);
> > +voidcpuset_intersection(struct cpuset *t, struct cpuset *,
> > +   struct cpuset *);
> > +
> >  /*
> >   * To help choosing which cpu should run which process we keep track
> >   * of cpus which are currently idle and which cpus have processes
> > @@ -717,12 +724,6 @@ cpuset_init_cpu(struct cpu_info *ci)
> >  }
> >  
> >  void
> > -cpuset_clear(struct cpuset *cs)
> > -{
> > -   memset(cs, 0, sizeof(*cs));
> > -}
> > -
> > -void
> >  cpuset_add(struct cpuset *cs, struct cpu_info *ci)
> >  {
> > unsigned int num = CPU_INFO_UNIT(ci);
> > @@ -744,12 +745,6 @@ cpuset_isset(struct cpuset *cs, struct c
> >  }
> >  
> >  void
> > -cpuset_add_all(struct cpuset *cs)
> > -{
> > -   cpuset_copy(cs, _all);
> > -}
> > -
> > -void
> >  cpuset_copy(struct cpuset *to, struct cpuset *from)
> >  {
> > memcpy(to, from, sizeof(*to));
> > @@ -765,15 +760,6 @@ cpuset_first(struct cpuset *cs)
> > return (cpuset_infos[i * 32 + ffs(cs->cs_set[i]) - 1]);
> >  
> > return (NULL);
> > -}
> > -
> > -void
> > -cpuset_union(struct cpuset *to, struct cpuset *a, struct cpuset *b)
> > -{
> > -   int i;
> > -
> > -   for (i = 0; i < CPUSET_ASIZE(ncpus); i++)
> > -   to->cs_set[i] = a->cs_set[i] | b->cs_set[i];
> >  }
> >  
> >  void
> > Index: sys/sys/proc.h
> > ===
> > RCS file: /cvs/src/sys/sys/proc.h,v
> > retrieving revision 1.213
> > diff -u -p -r1.213 proc.h
> > --- sys/sys/proc.h  6 Dec 2015 17:50:21 -   1.213
> > +++ sys/sys/proc.h  2 Mar 2016 15:56:33 -
> > @@ -205,9 +205,9 @@ struct process {
> >  
> > struct uprof {  /* profile arguments */
> > caddr_t pr_base;/* buffer base */
> > -   size_t  pr_size;/* buffer size */
> > +   size_t  pr_size;/* buffer size */
> > u_long  pr_off; /* pc offset */
> > -   u_int   pr_scale;   /* pc scaling */
> > +   u_int   pr_scale;   /* pc scaling */
> > } ps_prof;
> >  
> > u_short ps_acflag;  /* Accounting flags. */
> > @@ -215,8 +215,8 @@ struct process {
> > uint64_t ps_pledge;
> > struct whitepaths *ps_pledgepaths;
> >  
> > -   int64_t ps_kbind_cookie;
> > -   u_long  ps_kbind_addr;
> > +   int64_t ps_kbind_cookie;
> > +   u_long  ps_kbind_addr;
> >  
> >  /* End area that is copied on creation. */
> >  #define ps_endcopy ps_refcnt
> > @@ -255,7 +255,7 @@ struct process {
> >  #definePS_EMBRYO   0x0002  /* New process, not yet fledged 
> > */
> >  #definePS_ZOMBIE   0x0004  /* Dead and ready to be waited 
> > for */
> >  #definePS_NOBROADCASTKILL 0x0008   /* 

csh header cleanup

[Edgar Pettijohn]

Index: alloc.c
===
RCS file: /cvs/src/bin/csh/alloc.c,v
retrieving revision 1.17
diff -u -p -u -r1.17 alloc.c
--- alloc.c26 Dec 2015 13:48:38 -1.17
+++ alloc.c16 Mar 2016 22:47:56 -
@@ -30,12 +30,18 @@
  * SUCH DAMAGE.
  */

+#include 
 #include 
-#include 
-#include 
+
+#include 
+#include 
 #include 
+#include 
+#include 
+#include 

 #include "csh.h"
+#include "error.h"
 #include "extern.h"

 void *
Index: char.h
===
RCS file: /cvs/src/bin/csh/char.h,v
retrieving revision 1.5
diff -u -p -u -r1.5 char.h
--- char.h26 Oct 2015 15:01:15 -1.5
+++ char.h15 Mar 2016 02:20:05 -
@@ -32,8 +32,6 @@
  *@(#)char.h8.1 (Berkeley) 5/31/93
  */

-#include 
-
 extern unsigned short _cmap[];

 #define_QF0x0001/* '" (Forward quotes) */
Index: const.c
===
RCS file: /cvs/src/bin/csh/const.c,v
retrieving revision 1.8
diff -u -p -u -r1.8 const.c
--- const.c26 Oct 2015 16:27:04 -1.8
+++ const.c15 Mar 2016 01:56:33 -
@@ -34,6 +34,13 @@
  * tc.const.c: String constants for csh.
  */

+#include 
+#include 
+
+#include 
+#include 
+#include 
+
 #include "csh.h"

 Char STR0[]= { '0', '\0' };
Index: csh.c
===
RCS file: /cvs/src/bin/csh/csh.c,v
retrieving revision 1.37
diff -u -p -u -r1.37 csh.c
--- csh.c26 Dec 2015 13:48:38 -1.37
+++ csh.c16 Mar 2016 22:49:38 -
@@ -30,24 +30,33 @@
  * SUCH DAMAGE.
  */

-#include 
 #include 
+#include 
 #include 
-#include 
+#include 
+
 #include 
+#include 
+#include 
+#include 
+#include 
 #include 
+#include 
+#include 
+#include 
 #include 
+#include 
 #include 
-#include 
 #include 
-#include 
 #include 
-#include 

 #include "csh.h"
-#include "proc.h"
+#include "const.h"
+#include "dir.h"
+#include "error.h"
 #include "extern.h"
 #include "pathnames.h"
+#include "proc.h"

 /*
  * C Shell
Index: csh.h
===
RCS file: /cvs/src/bin/csh/csh.h,v
retrieving revision 1.28
diff -u -p -u -r1.28 csh.h
--- csh.h26 Dec 2015 13:48:38 -1.28
+++ csh.h15 Mar 2016 01:46:58 -
@@ -65,15 +65,10 @@ typedef short Char;

 typedef void *ioctl_t;/* Third arg of ioctl */

-#include "const.h"
-#include "char.h"
-#include "error.h"
-
 #define xmalloc(i)Malloc(i)
 #define xreallocarray(p, i, j)Reallocarray(p, i, j)
 #define xcalloc(n, s)Calloc(n, s)

-#include 
 FILE *cshin, *cshout, *csherr;

 #defineisdir(d)(S_ISDIR(d.st_mode))
@@ -118,10 +113,6 @@ Char   *ffile;/* Name of shell file f

 char   *seterr;/* Error message from scanner/parser */

-#include 
-#include 
-#include 
-
 struct timeval time0;/* Time at which the shell started */
 struct rusage ru0;

@@ -160,7 +151,6 @@ int   OLDSTD;/* Old standard input (d
  * Because of source commands and .cshrc we need nested error catches.
  */

-#include 
 jmp_buf reslab;
 int exitset;

@@ -172,7 +162,6 @@ int exitset;

 Char   *gointr;/* Label for an onintr transfer */

-#include 
 sig_t parintr;/* Parents interrupt catch */
 sig_t parterm;/* Parents terminate catch */

@@ -476,7 +465,6 @@ Char   *word_chars;

 Char   *STR_SHELLPATH;

-#include 
 Char   *STR_BSHELL;
 Char   *STR_WORD_CHARS;
 Char  **STR_environ;
Index: dir.c
===
RCS file: /cvs/src/bin/csh/dir.c,v
retrieving revision 1.21
diff -u -p -u -r1.21 dir.c
--- dir.c26 Dec 2015 13:48:38 -1.21
+++ dir.c16 Mar 2016 22:50:15 -
@@ -30,16 +30,25 @@
  * SUCH DAMAGE.
  */

+#include 
 #include 
+
+#include 
 #include 
+#include 
+#include 
+#include 
+#include 
 #include 
+#include 
 #include 
 #include 
-#include 
-#include 

 #include "csh.h"
+#include "char.h"
+#include "const.h"
 #include "dir.h"
+#include "error.h"
 #include "extern.h"

 /* Directory management. */
Index: dol.c
===
RCS file: /cvs/src/bin/csh/dol.c,v
retrieving revision 1.20
diff -u -p -u -r1.20 dol.c
--- dol.c26 Dec 2015 13:48:38 -1.20
+++ dol.c16 Mar 2016 22:50:51 -
@@ -30,15 +30,24 @@
  * SUCH DAMAGE.
  */

+#include 
 #include 
-#include 
+
+#include 
 #include 
+#include 
+#include 
+#include 
+#include 
 #include 
+#include 
 #include 
 #include 
-#include 

+#include "char.h"
 #include "csh.h"
+#include "const.h"
+#include "error.h"
 #include "extern.h"

 /*
Index: error.c
===
RCS file: /cvs/src/bin/csh/error.c,v
retrieving revision 1.12
diff -u -p -u -r1.12 error.c
--- error.c26 Dec 2015 13:48:38 -1.12
+++ error.c16 Mar 2016 22:51:14 -
@@ -30,12 

Re: New scheduler for OpenBSD

[Mike Belopuhov]

On 18 March 2016 at 18:02, Michal Mazurek  wrote:
> On 09:22:18, 18.03.16, Chris Cappuccio wrote:
>> These are really rough observations. This box spawns lots of dirty
>> perl processes and also lots of fping processes for monitoring.
>
> The next step I had planned was related to juggling processes between
> cpus. Right now that code is untouched, other than removing a line
> related to priority. One idea is to compare the deadline of the last
> element on every queue, and balance based on that. Maybe this will
> improve this use case?
>
> The original diff contains commented out code (grep for
> CPU_INFO_ITERATOR) that prints out the queues every second. When running
> tests with it I sometimes observe one cpu is 0.5-1 second behind another,
> so I think this is a good next step for this scheduler.
>
> BFS has one shared queue for all CPUs, maybe there is a very good reason
> for that, we'll see.
>
>
> I'd like to thank everyone for all the feedback.
>

Something else to consider: it would be nice if sched_bsd.c
wouldn't be changed and new code would be placed in sched_bfs.c
(or sched_deadline.c or whatever) and kern_sched.c would act as
an interface to that code so that we could switch schedulers
via a compile time option (SCHED_xxx).  I think this was the
intention behind splitting the code.

> --
> Michal Mazurek
>

Re: kern_sched.c: unused functions

[Mark Kettenis]

> Date: Wed, 16 Mar 2016 22:18:41 -0400
> From: Michael McConville 
> 
> Michal Mazurek wrote:
> > On 17:19:39,  2.03.16, Martin Natano wrote:
> > > On Wed, Mar 02, 2016 at 05:07:21PM +0100, Michal Mazurek wrote:
> > > > kern_sched.c:
> > > > - remove unused functions
> > > > - mark static functions as static
> > > 
> > > Functions shouldn't be static in the kernel. "In userland,
> > > functions local to one source module should be declared ???static???.  
> > > This
> > > should not be done in kernel land since it makes it impossible to use the
> > > kernel debugger." -- style(8)
> > 
> > Oh, right.
> > 
> > Remove cpuset_clear(), cpuset_add_all() and cpuset_union(), and move
> > some declarations from proc.h to kern_sched.c.
> 
> ok mmcc@, pending an ok from someone who works with this code.

Leave them alone.  It makes sense to have the complete set of
operations implemented, even if they aren't currently used.

> > Index: sys/kern/kern_sched.c
> > ===
> > RCS file: /cvs/src/sys/kern/kern_sched.c,v
> > retrieving revision 1.41
> > diff -u -p -r1.41 kern_sched.c
> > --- sys/kern/kern_sched.c   23 Dec 2015 14:51:17 -  1.41
> > +++ sys/kern/kern_sched.c   2 Mar 2016 16:37:18 -
> > @@ -28,11 +28,18 @@
> >  
> >  #include 
> >  
> > -void sched_kthreads_create(void *);
> > -
> > -int sched_proc_to_cpu_cost(struct cpu_info *ci, struct proc *p);
> > +voidsched_kthreads_create(void *);
> > +int sched_proc_to_cpu_cost(struct cpu_info *ci, struct proc *p);
> >  struct proc *sched_steal_proc(struct cpu_info *);
> >  
> > +voidcpuset_complement(struct cpuset *, struct cpuset *, struct 
> > cpuset *);
> > +voidcpuset_copy(struct cpuset *, struct cpuset *);
> > +struct cpu_info *cpuset_first(struct cpuset *);
> > +voidcpuset_del(struct cpuset *, struct cpu_info *);
> > +voidcpuset_init_cpu(struct cpu_info *);
> > +voidcpuset_intersection(struct cpuset *t, struct cpuset *,
> > +   struct cpuset *);
> > +
> >  /*
> >   * To help choosing which cpu should run which process we keep track
> >   * of cpus which are currently idle and which cpus have processes
> > @@ -717,12 +724,6 @@ cpuset_init_cpu(struct cpu_info *ci)
> >  }
> >  
> >  void
> > -cpuset_clear(struct cpuset *cs)
> > -{
> > -   memset(cs, 0, sizeof(*cs));
> > -}
> > -
> > -void
> >  cpuset_add(struct cpuset *cs, struct cpu_info *ci)
> >  {
> > unsigned int num = CPU_INFO_UNIT(ci);
> > @@ -744,12 +745,6 @@ cpuset_isset(struct cpuset *cs, struct c
> >  }
> >  
> >  void
> > -cpuset_add_all(struct cpuset *cs)
> > -{
> > -   cpuset_copy(cs, _all);
> > -}
> > -
> > -void
> >  cpuset_copy(struct cpuset *to, struct cpuset *from)
> >  {
> > memcpy(to, from, sizeof(*to));
> > @@ -765,15 +760,6 @@ cpuset_first(struct cpuset *cs)
> > return (cpuset_infos[i * 32 + ffs(cs->cs_set[i]) - 1]);
> >  
> > return (NULL);
> > -}
> > -
> > -void
> > -cpuset_union(struct cpuset *to, struct cpuset *a, struct cpuset *b)
> > -{
> > -   int i;
> > -
> > -   for (i = 0; i < CPUSET_ASIZE(ncpus); i++)
> > -   to->cs_set[i] = a->cs_set[i] | b->cs_set[i];
> >  }
> >  
> >  void
> > Index: sys/sys/proc.h
> > ===
> > RCS file: /cvs/src/sys/sys/proc.h,v
> > retrieving revision 1.213
> > diff -u -p -r1.213 proc.h
> > --- sys/sys/proc.h  6 Dec 2015 17:50:21 -   1.213
> > +++ sys/sys/proc.h  2 Mar 2016 15:56:33 -
> > @@ -205,9 +205,9 @@ struct process {
> >  
> > struct uprof {  /* profile arguments */
> > caddr_t pr_base;/* buffer base */
> > -   size_t  pr_size;/* buffer size */
> > +   size_t  pr_size;/* buffer size */
> > u_long  pr_off; /* pc offset */
> > -   u_int   pr_scale;   /* pc scaling */
> > +   u_int   pr_scale;   /* pc scaling */
> > } ps_prof;
> >  
> > u_short ps_acflag;  /* Accounting flags. */
> > @@ -215,8 +215,8 @@ struct process {
> > uint64_t ps_pledge;
> > struct whitepaths *ps_pledgepaths;
> >  
> > -   int64_t ps_kbind_cookie;
> > -   u_long  ps_kbind_addr;
> > +   int64_t ps_kbind_cookie;
> > +   u_long  ps_kbind_addr;
> >  
> >  /* End area that is copied on creation. */
> >  #define ps_endcopy ps_refcnt
> > @@ -255,7 +255,7 @@ struct process {
> >  #definePS_EMBRYO   0x0002  /* New process, not yet fledged 
> > */
> >  #definePS_ZOMBIE   0x0004  /* Dead and ready to be waited 
> > for */
> >  #definePS_NOBROADCASTKILL 0x0008   /* Process excluded from kill 
> > -1. */
> > -#define PS_PLEDGE  0x0010  /* Has called pledge(2) */
> > +#definePS_PLEDGE   0x0010  /* Has called pledge(2) */
> >  
> >  #definePS_BITS \
> >  ("\20" "\01CONTROLT" "\02EXEC" "\03INEXEC" "\04EXITING" "\05SUGID" \
> 

Re: A patch for allowing IPv6-only or IPv4-only bridges

[Martin Pieuchot]

On 16/03/16(Wed) 20:54, Momtchil Momtchev wrote:
> [..]
> Here is my patch that adds support for creating IPv6-only or IPv4-only
> bridges. This is different from simply blocking one of the protocols via PF
> - it allows you to create a setup where IPv4 is routed and IPv6 is bridged
> (or vice versa). Both of them being filtered by the same set of PF rules. It
> adds two new bridge port options to ifconfig - BLOCKIPV4 and BLOCKIPV6.
> BLOCKIPV4 also stops ARPs requests from "leaking" across the bridge -
> something I couldn't accomplish by PF alone.

Interesting.  It seems that some devs would have a use case for that.
However I wonder if it wouldn't make more sense to extend the rule
filtering to be able to filter on something else than the Ethernet src/dst.

Reyk, Goda what to you think?  Are you also interested in blocking IPv4
and/or IPv6?

Note that Ethernet Multicast/IP Multicast are also blocked in bridge(4)
via the link0 and link1 flags.  Do you think it would make sense to use
rules for that too?

> The patch breaks the binary compatibility of ifconfig - it must be
> rebuilt with the new kernel.

This is not a big deal.

> I don't know if anyone will find any use for it. For sure it is very
> useful with the second-biggest FTTH/ADSL operator in France who offers
> consumer-grade IPv6 access with an indivisible /64 network that must be
> bridged for firewalling (and a single IPv4/32 address that must be NATted).
> Patch is against -current, any comments are welcome.

Comments below, but let's see what Reyk and Goda think the right
approach is before sending a new one.

> Index: sbin/ifconfig/brconfig.c
> ===
> RCS file: /cvs/src/sbin/ifconfig/brconfig.c,v
> retrieving revision 1.9
> diff -u -p -u -r1.9 brconfig.c
> --- sbin/ifconfig/brconfig.c18 Jul 2015 06:50:24 -1.9
> +++ sbin/ifconfig/brconfig.c16 Mar 2016 19:37:44 -
> @@ -59,7 +59,7 @@ void bridge_showrule(struct ifbrlreq *);
> 
>  #defineIFBAFBITS"\020\1STATIC"
>  #defineIFBIFBITS\
> -"\020\1LEARNING\2DISCOVER\3BLOCKNONIP\4STP\5EDGE\6AUTOEDGE\7PTP\10AUTOPTP\11SPAN"
> +"\020\1LEARNING\2DISCOVER\3BLOCKNONIP\4STP\5EDGE\6AUTOEDGE\7PTP\10AUTOPTP\11BLOCKIPV4\12BLOCKIPV6\15SPAN"
> 
>  #definePV2ID(pv, epri, eaddr)do {\
>  epri = pv >> 48;\
> @@ -93,102 +93,28 @@ char *stproles[] = {
>  };
> 
> 
> -void
> -setdiscover(const char *val, int d)
> -{
> -bridge_ifsetflag(val, IFBIF_DISCOVER);
> -}
> -
> -void
> -unsetdiscover(const char *val, int d)
> -{
> -bridge_ifclrflag(val, IFBIF_DISCOVER);
> -}
> -
> -void
> -setblocknonip(const char *val, int d)
> -{
> -bridge_ifsetflag(val, IFBIF_BLOCKNONIP);
> -}
> -
> -void
> -unsetblocknonip(const char *val, int d)
> -{
> -bridge_ifclrflag(val, IFBIF_BLOCKNONIP);
> -}
> -
> -void
> -setlearn(const char *val, int d)
> -{
> -bridge_ifsetflag(val, IFBIF_LEARNING);
> -}
> -
> -void
> -unsetlearn(const char *val, int d)
> -{
> -bridge_ifclrflag(val, IFBIF_LEARNING);
> -}
> -
> -void
> -setstp(const char *val, int d)
> -{
> -bridge_ifsetflag(val, IFBIF_STP);
> -}
> -
> -void
> -unsetstp(const char *val, int d)
> -{
> -bridge_ifclrflag(val, IFBIF_STP);
> -}
> -
> -void
> -setedge(const char *val, int d)
> -{
> -bridge_ifsetflag(val, IFBIF_BSTP_EDGE);
> -}
> -
> -void
> -unsetedge(const char *val, int d)
> -{
> -bridge_ifclrflag(val, IFBIF_BSTP_EDGE);
> -}
> -
> -void
> -setautoedge(const char *val, int d)
> -{
> -bridge_ifsetflag(val, IFBIF_BSTP_AUTOEDGE);
> -}
> -
> -void
> -unsetautoedge(const char *val, int d)
> -{
> -bridge_ifclrflag(val, IFBIF_BSTP_AUTOEDGE);
> -}
> -
> -void
> -setptp(const char *val, int d)
> -{
> -bridge_ifsetflag(val, IFBIF_BSTP_PTP);
> -}
> -
> -void
> -unsetptp(const char *val, int d)
> -{
> -bridge_ifclrflag(val, IFBIF_BSTP_PTP);
> -}
> -
> -void
> -setautoptp(const char *val, int d)
> -{
> -bridge_ifsetflag(val, IFBIF_BSTP_AUTOPTP);
> -}
> -
> -void
> -unsetautoptp(const char *val, int d)
> -{
> -bridge_ifclrflag(val, IFBIF_BSTP_AUTOPTP);
> -}
> -
> +#define IFBIF_SETUNSET(NAME,FLAG) \
> +void \
> +set ## NAME (const char *val, int d) \
> +{ \
> +bridge_ifsetflag(val, FLAG); \
> +} \
> +void \
> +unset ## NAME (const char *val, int d) \
> +{ \
> +bridge_ifclrflag(val, FLAG); \
> +}

Please avoid mixing a refactoring and a new feature in the same diff.

Plus this kind of abstraction are questionable and might block or delay
your diff to go in ;)

> +IFBIF_SETUNSET(discover,IFBIF_DISCOVER)
> +IFBIF_SETUNSET(blocknonip,IFBIF_BLOCKNONIP)
> +IFBIF_SETUNSET(blockipv4,IFBIF_BLOCKIPV4)
> +IFBIF_SETUNSET(blockipv6,IFBIF_BLOCKIPV6)
> +IFBIF_SETUNSET(learn,IFBIF_LEARNING)
> +IFBIF_SETUNSET(stp,IFBIF_STP)
> +IFBIF_SETUNSET(edge,IFBIF_BSTP_EDGE)
> +IFBIF_SETUNSET(autoedge,IFBIF_BSTP_AUTOEDGE)
> 

Re: New scheduler for OpenBSD

[Karel Gardas]

On Fri, Mar 18, 2016 at 6:02 PM, Michal Mazurek  wrote:
> BFS has one shared queue for all CPUs, maybe there is a very good reason
> for that, we'll see.

Michal,

first of all congrats to optimistic results in interactive workloads.
Honestly I'm a little bit worried about your attempts since I think if
doing any scheduler modernization then it shall also consider to be
NUMA-aware or at least take NUMA into consideration. The problem is
that NUMA is no longer domain of high-cpu sockets boxes, but it's also
available or possibly to be available in 1 socket Haswell boxes when
configured right. Intel calls this "cluster-on-die" for your
information.
Anyway, although worried, I'm still curious about your hacking in
scheduler, so I keep my fingers crossed! Thanks, Karel

Re: multitouch support in wsmouse 1/3

[Ulf Brosziewski]

There are whitespace errors in the diffs. In case anyone
wants to test them, please use the new versions in the
attachment.

On 03/13/2016 06:37 PM, Ulf Brosziewski wrote:

The diffs below are a rewrite of the input-processing part of wsmouse. It
adds support for multitouch input.

[...]


mtsupport.tgz
Description: application/compressed-tar

puc(4): [WIP] TXIC TX382B UART controller support

[SASANO Takayoshi]

Hello,

Recently I bought a cheap PCIe UART adapter.
It uses ASMedia ASM1083 PCIe-PCI bridge and TXIC TX382B UART controller.
There is no details/datasheets about TX382B, but a Chinese seller
saids that it is similar to WCH351Q (aka WinChipHead's CH351Q). [1]

So I add new entry to pucdata.c like CH351.
TX382B may be compatible with 16550A but works with no FIFO
when my diff is applied.

Here is a dmesg.

  ppb1 at pci1 dev 0 function 0 "ASMedia ASM1083/1085 PCIE-PCI" rev 0x04
  pci2 at ppb1 bus 2
  puc0 at pci2 dev 0 function 0 "TXIC TX382B" rev 0x10: ports: 2 com
  com4 at puc0 port 0 apic 5 int 18: ns16550a, 16 byte fifo
  com4: probed fifo depth: 0 bytes
  com5 at puc0 port 1 apic 5 int 18: ns16550a, 16 byte fifo
  com5: probed fifo depth: 0 bytes

Is this problem occurs with WCH's CH351?

[1] http://www.mistertao.com/v2/pages/item/39360600316.html
This site is written in Chinese, use Google Translate.

Regards,
-- 
SASANO Takayoshi 

Index: pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1790
diff -u -p -r1.1790 pcidevs
--- pcidevs 15 Mar 2016 07:37:15 -  1.1790
+++ pcidevs 16 Mar 2016 03:04:27 -
@@ -340,6 +340,7 @@ vendor  AVANCE2 0x4005  Avance Logic
 vendor ADDTRON 0x4033  Addtron
 vendor NETXEN  0x4040  NetXen
 vendor WCH 0x4348  Nanjing QinHeng Electronics
+vendor TXIC0x4651  TXIC
 vendor INDCOMPSRC  0x494f  Industrial Computer Source
 vendor NETVIN  0x4a14  NetVin
 vendor GEMTEK  0x5046  Gemtek
@@ -5139,6 +5140,9 @@ product WCH CH352 0x3253  CH352
 product WCH2 CH351 0x2273  CH351
 product WCH2 CH382_1   0x3253  CH382
 product WCH2 CH382_2   0x3250  CH382
+
+/* TXIC */
+productTXIC TX382B 0x3273  TX382B
 
 /* National Datacomm Corp products */
 product NDC NCP130 0x0130  NCP130
Index: pcidevs.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs.h,v
retrieving revision 1.1784
diff -u -p -r1.1784 pcidevs.h
--- pcidevs.h   15 Mar 2016 07:37:36 -  1.1784
+++ pcidevs.h   16 Mar 2016 03:04:28 -
@@ -345,6 +345,7 @@
 #definePCI_VENDOR_ADDTRON  0x4033  /* Addtron */
 #definePCI_VENDOR_NETXEN   0x4040  /* NetXen */
 #definePCI_VENDOR_WCH  0x4348  /* Nanjing QinHeng Electronics 
*/
+#definePCI_VENDOR_TXIC 0x4651  /* TXIC */
 #definePCI_VENDOR_INDCOMPSRC   0x494f  /* Industrial Computer 
Source */
 #definePCI_VENDOR_NETVIN   0x4a14  /* NetVin */
 #definePCI_VENDOR_GEMTEK   0x5046  /* Gemtek */
@@ -5144,6 +5145,9 @@
 #definePCI_PRODUCT_WCH2_CH351  0x2273  /* CH351 */
 #definePCI_PRODUCT_WCH2_CH382_10x3253  /* CH382 */
 #definePCI_PRODUCT_WCH2_CH382_20x3250  /* CH382 */
+
+/* TXIC */
+#definePCI_PRODUCT_TXIC_TX382B 0x3273  /* TX382B */
 
 /* National Datacomm Corp products */
 #definePCI_PRODUCT_NDC_NCP130  0x0130  /* NCP130 */
Index: pcidevs_data.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs_data.h,v
retrieving revision 1.1779
diff -u -p -r1.1779 pcidevs_data.h
--- pcidevs_data.h  15 Mar 2016 07:37:36 -  1.1779
+++ pcidevs_data.h  16 Mar 2016 03:04:29 -
@@ -17760,6 +17760,10 @@ static const struct pci_known_product pc
"CH382",
},
{
+   PCI_VENDOR_TXIC, PCI_PRODUCT_TXIC_TX382B,
+   "TX382B",
+   },
+   {
PCI_VENDOR_NDC, PCI_PRODUCT_NDC_NCP130,
"NCP130",
},
@@ -26754,6 +26758,10 @@ static const struct pci_known_vendor pci
{
PCI_VENDOR_WCH,
"Nanjing QinHeng Electronics",
+   },
+   {
+   PCI_VENDOR_TXIC,
+   "TXIC",
},
{
PCI_VENDOR_INDCOMPSRC,
Index: pucdata.c
===
RCS file: /cvs/src/sys/dev/pci/pucdata.c,v
retrieving revision 1.102
diff -u -p -r1.102 pucdata.c
--- pucdata.c   15 Mar 2016 07:39:27 -  1.102
+++ pucdata.c   16 Mar 2016 03:04:29 -
@@ -2166,6 +2166,14 @@ const struct puc_device_description puc_
{ PUC_COM_POW2(0), 0x10, 0x00c8 },
},
},
+   {   /* "TXIC TX382B (2S)", */
+   {   PCI_VENDOR_TXIC, PCI_PRODUCT_TXIC_TX382B,   0, 0},
+   {   0x, 0x, 0, 0},
+   {
+   { PUC_COM_POW2(0), 0x10, 0x },
+   { PUC_COM_POW2(0), 0x14, 0x },
+   }
+   },
{   /* "NetMos NM9820 UART" */
{   PCI_VENDOR_NETMOS, PCI_PRODUCT_NETMOS_NM9820,   0, 0},
{   

Re: New scheduler for OpenBSD

[Michal Mazurek]

On 09:22:18, 18.03.16, Chris Cappuccio wrote:
> These are really rough observations. This box spawns lots of dirty
> perl processes and also lots of fping processes for monitoring.

The next step I had planned was related to juggling processes between
cpus. Right now that code is untouched, other than removing a line
related to priority. One idea is to compare the deadline of the last
element on every queue, and balance based on that. Maybe this will
improve this use case?

The original diff contains commented out code (grep for
CPU_INFO_ITERATOR) that prints out the queues every second. When running
tests with it I sometimes observe one cpu is 0.5-1 second behind another,
so I think this is a good next step for this scheduler.

BFS has one shared queue for all CPUs, maybe there is a very good reason
for that, we'll see.


I'd like to thank everyone for all the feedback.

-- 
Michal Mazurek

ed header cleanup

[Edgar Pettijohn]

Index: buf.c
===
RCS file: /cvs/src/bin/ed/buf.c,v
retrieving revision 1.22
diff -u -p -u -r1.22 buf.c
--- buf.c9 Oct 2015 19:47:02 -1.22
+++ buf.c16 Mar 2016 23:23:53 -
@@ -30,6 +30,15 @@
  */

 #include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 

 #include "ed.h"

Index: ed.h
===
RCS file: /cvs/src/bin/ed/ed.h,v
retrieving revision 1.21
diff -u -p -u -r1.21 ed.h
--- ed.h9 Oct 2015 21:24:05 -1.21
+++ ed.h16 Mar 2016 23:11:41 -
@@ -30,16 +30,6 @@
  *@(#)ed.h,v 1.5 1994/02/01 00:34:39 alm Exp
  */

-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
 #define ERR(-2)
 #define EMOD(-3)
 #define FATAL(-4)
Index: glbl.c
===
RCS file: /cvs/src/bin/ed/glbl.c,v
retrieving revision 1.17
diff -u -p -u -r1.17 glbl.c
--- glbl.c9 Oct 2015 20:27:28 -1.17
+++ glbl.c16 Mar 2016 23:26:10 -
@@ -32,6 +32,12 @@
 #include 
 #include 

+#include 
+#include 
+#include 
+#include 
+#include 
+
 #include "ed.h"

 static int set_active_node(line_t *);
Index: io.c
===
RCS file: /cvs/src/bin/ed/io.c,v
retrieving revision 1.18
diff -u -p -u -r1.18 io.c
--- io.c9 Oct 2015 20:27:28 -1.18
+++ io.c16 Mar 2016 23:28:09 -
@@ -28,6 +28,12 @@
  * SUCH DAMAGE.
  */

+#include 
+#include 
+#include 
+#include 
+#include 
+
 #include "ed.h"

 static int read_stream(FILE *, int);
Index: main.c
===
RCS file: /cvs/src/bin/ed/main.c,v
retrieving revision 1.56
diff -u -p -u -r1.56 main.c
--- main.c20 Nov 2015 08:53:28 -1.56
+++ main.c16 Mar 2016 23:31:16 -
@@ -44,11 +44,19 @@
 #include 
 #include 
 #include 
+
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include 
+#include 
+#include 
+#include 
+#include 
 #include 
-#include 
-#include 

 #include "ed.h"

Index: re.c
===
RCS file: /cvs/src/bin/ed/re.c,v
retrieving revision 1.16
diff -u -p -u -r1.16 re.c
--- re.c9 Oct 2015 21:24:05 -1.16
+++ re.c16 Mar 2016 23:34:46 -
@@ -29,6 +29,12 @@
  * SUCH DAMAGE.
  */

+#include 
+#include 
+#include 
+#include 
+#include 
+
 #include "ed.h"

 static char *extract_pattern(int);
Index: sub.c
===
RCS file: /cvs/src/bin/ed/sub.c,v
retrieving revision 1.14
diff -u -p -u -r1.14 sub.c
--- sub.c9 Oct 2015 20:27:28 -1.14
+++ sub.c16 Mar 2016 23:36:29 -
@@ -29,6 +29,13 @@
  * SUCH DAMAGE.
  */

+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
 #include "ed.h"

 static char *extract_subst_template(void);
Index: undo.c
===
RCS file: /cvs/src/bin/ed/undo.c,v
retrieving revision 1.13
diff -u -p -u -r1.13 undo.c
--- undo.c9 Oct 2015 19:47:02 -1.13
+++ undo.c16 Mar 2016 23:37:46 -
@@ -28,8 +28,12 @@
  * SUCH DAMAGE.
  */

-#include "ed.h"
+#include 
+#include 
+#include 
+#include 

+#include "ed.h"

 #define USIZE 100/* undo stack size */
 static undo_t *ustack = NULL;/* undo stack */

Re: New scheduler for OpenBSD

[Martin Pieuchot]

On 18/03/16(Fri) 13:04, Theo de Raadt wrote:
> > So I'm skeptical about this BFS scheduler.  Don't get me wrong; I do
> > think the scheduler needs attention.  But I'm not sure a scheduler
> > designed for interactive desktop use is the best option for OpenBSD.
> > I'm willing to be proven wrong.  But that means we need careful
> > benchmarking on a wide variety of workloads and hardware.
> 
> I don't think this scheduler is making things better because of
> it's scheduling behaviour.
> 
> I think the scheduling choices it makes are hiding a poor-performing
> artifact we have elsewhere.

I think the same thing.  After reading your diff carefully I think that
it might be nice to split it in pieces to be able to see the effect of
each of them.

I saw the following interesting items, but there might be even more:

 1. Each process gets the same deadline.  So you basically don't have
priorities or did I misunderstood something? 

 2. In any case, the cost of the migration of a process calculated in
sched_proc_to_cpu_cost() and used via sched_choosecpu() no longer
take the priority of a process in account.  But this might just be
an side-effect of 1.

 3. You changed the semantic of roundrobin().  With your diff there's no
context switch every 100ms.  There's now a context switch every time
a process has been has been "curproc" for ``rrticks'' long.

 4. You are no longer making a difference between ``p_usrpri'' and
``p_priority'' there's only priority: ``p_deadline''.

 4. You use only one runqueue.

 5. You're using deadlines which means you don't have all these
complicated, different and possibly buggy logics to recalculate the
priority of a process.


Please correct me if I said anything wrong.

Re: Octeon II usb

[Jonathan Matthew]

On Thu, Mar 17, 2016 at 11:43:03AM +0900, Masao Uebayashi wrote:
> A bit surprised that code does more than I imagined by reading your
> description :) but it looks very good to me!
> 
> A few comments:
> 
> - `struct octuctl_softc' is not using `sc_ehci' and `sc_ohci'?

These were leftovers from when I thought I could fit everything in one file.
I removed these, then got a friendly reminder from autoconf that I'd forgotten
the 'struct device' at the start of the softc.

> - Some magic numbers in `octuctl_clock_setup' could be #define'ed

Looking at this again, the 64 io clock cycle delay we're supposed to add after
enabling USB clocks is always going to be less than a microsecond, so I'll
just use delay(1).

I'll add a #define for the USB hclk target frequency.

Re: Octeon II usb

[Masao Uebayashi]

A bit surprised that code does more than I imagined by reading your
description :) but it looks very good to me!

A few comments:

- `struct octuctl_softc' is not using `sc_ehci' and `sc_ohci'?
- Some magic numbers in `octuctl_clock_setup' could be #define'ed

I've just bought EdgeRouter Pro.  Hopefully I'll test this soon.

OK uebayasi@

On Thu, Mar 17, 2016 at 11:51:19AM +1000, Jonathan Matthew wrote:
> I've had this sitting around for a while and I figure it's time to get it in
> the tree.  Octeon II sensibly got rid of the DWC USB controller and put in 
> ehci
> and ohci compliant controllers instead, so all we need to do here is set up a
> few registers in the usb controller interface and attach the standard drivers.
> The diff below adds octuctl, a driver for the usb controller interface, and 
> octehci and octohci, which are attachments for ehci and ohci.
> 
> I've tested this on a Lanner MR326b, where it allows me to boot off a usb
> stick, and on an Edgerouter Lite, where it makes no difference at all.
> 
> ok?
> 
> Index: conf/GENERIC
> ===
> RCS file: /cvs/src/sys/arch/octeon/conf/GENERIC,v
> retrieving revision 1.24
> diff -u -p -u -p -r1.24 GENERIC
> --- conf/GENERIC  14 Jan 2016 17:20:34 -  1.24
> +++ conf/GENERIC  17 Mar 2016 01:43:51 -
> @@ -64,9 +64,14 @@ wd*at pciide? flags 0x
>  
>  # USB Controllers
>  dwctwo0  at iobus? irq 56
> +octuctl0 at iobus? irq 56
> +ehci0at octuctl?
> +ohci0at octuctl?
>  
>  # USB bus support
>  usb* at dwctwo?
> +usb* at ehci?
> +usb* at ohci?
>  
>  # USB devices
>  uhub*at usb? # USB Hubs
> Index: conf/RAMDISK
> ===
> RCS file: /cvs/src/sys/arch/octeon/conf/RAMDISK,v
> retrieving revision 1.23
> diff -u -p -u -p -r1.23 RAMDISK
> --- conf/RAMDISK  14 Jan 2016 17:20:34 -  1.23
> +++ conf/RAMDISK  17 Mar 2016 01:43:51 -
> @@ -55,7 +55,14 @@ pciide*at pci? flags 0x
>  wd*  at pciide? flags 0x
>  
>  dwctwo0  at iobus0 irq 56
> +octuctl0 at iobus0 irq 56
> +ehci0at octuctl?
> +ohci0at octuctl?
> +
>  usb* at dwctwo?
> +usb* at ehci?
> +usb* at ohci?
> +
>  uhub*at usb?
>  uhub*at uhub?
>  umass*   at uhub?
> Index: conf/files.octeon
> ===
> RCS file: /cvs/src/sys/arch/octeon/conf/files.octeon,v
> retrieving revision 1.28
> diff -u -p -u -p -r1.28 files.octeon
> --- conf/files.octeon 14 Jan 2016 17:20:34 -  1.28
> +++ conf/files.octeon 17 Mar 2016 01:43:51 -
> @@ -71,6 +71,14 @@ file   arch/octeon/dev/cn30xxsmi.c 
> iobus
>  attach   dwctwo at iobus with octdwctwo
>  file arch/octeon/dev/octdwctwo.c octdwctwo   
> needs-flag
>  
> +device   octuctl {}
> +attach   octuctl at iobus
> +file arch/octeon/dev/octuctl.c   octuctl 
> needs-flag
> +attach   ehci at octuctl with octehci
> +file arch/octeon/dev/octehci.c   octehci
> +attach   ohci at octuctl with octohci
> +file arch/octeon/dev/octohci.c   octohci
> +
>  # On-board CF
>  device   octcf: disk
>  attach   octcf at iobus
> Index: dev/octehci.c
> ===
> RCS file: dev/octehci.c
> diff -N dev/octehci.c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ dev/octehci.c 17 Mar 2016 01:43:52 -
> @@ -0,0 +1,118 @@
> +/*   $OpenBSD$ */
> +
> +/*
> + * Copyright (c) 2015 Jonathan Matthew  
> + *
> + * Permission to use, copy, modify, and/or distribute this software for any
> + * purpose with or without fee is hereby granted, provided that the above
> + * copyright notice and this permission notice appear in all copies.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +struct octehci_softc {
> + struct ehci_softc   sc_ehci;
> +
> + void*sc_ih;
> +};
> +
> +int  

Re: puc(4): [WIP] TXIC TX382B UART controller support

[SASANO Takayoshi]

Hello,

The diff is committed (ok by deraadt@), and I am testing the behavior of
TX382B's FIFO.

> Here is a dmesg.
> 
>   ppb1 at pci1 dev 0 function 0 "ASMedia ASM1083/1085 PCIE-PCI" rev 0x04
>   pci2 at ppb1 bus 2
>   puc0 at pci2 dev 0 function 0 "TXIC TX382B" rev 0x10: ports: 2 com
>   com4 at puc0 port 0 apic 5 int 18: ns16550a, 16 byte fifo
>   com4: probed fifo depth: 0 bytes
>   com5 at puc0 port 1 apic 5 int 18: ns16550a, 16 byte fifo
>   com5: probed fifo depth: 0 bytes

com_fifo_probe() (at src/sys/dev/ic/com.c) checks the depth of Tx/Rx FIFO,
it uses MCR_LOOPBACK to enter loopback mode.

I found TX382B does not loopback with setting MCR_LOOPBACK,
and this cause com_fifo_probe() detects no FIFO.

It is difficult to write a special code to com.c, I think TX382B should
work without Tx/Rx FIFO. There is other good and cheap UART chip!

Regards,
-- 
SASANO Takayoshi 

SSLv3 and Internet Printing Protocol requirements problem

[Chris Bennett]

Apologies for my disappearance for a while but I have been brutally sick.
Fine now.

IPP is now using version 1.1 and new products also.

But it officially requires support for IPP version 1.0, which used
SSLv3.
I assume that there are printers, perhaps many were sold, which did use
version 1.0. That version used SSLv3 for encrypted communication. Which
is now gone.

How should we deal with this problem?

Chris Bennett

Re: Rename the global variable ``ticks''

[Alexandre Ratchov]

On Thu, Mar 17, 2016 at 09:02:03PM +0100, Martin Pieuchot wrote:
> ``ticks'' is in my opinion a really badly named global variable.  But we
> all know that finding names is hard ;)
> 
> Since its popularity seems to be really high lately, I'd suggest to
> rename it.  I chose ``hcticks'' for "hardclock ticks".  I believe this
> would help auditing the possible existing and/or future conditions
> leading to overflow.
> 
> As a bonus this diff removes all the "extern hcticks;" declaration and
> include  instead.
>
> Opinions?
> 

I prefer the "ticks" name, but this might be because i'm too used
to it.

OK, to remove all the ugly extern declarations.

add EdgeRouter Pro to www/octeon.html

[Marcus MERIGHI]

Hello,

"The patch seems to work fine on an EdgeRouter Pro.
OK visa@"
(http://marc.info/?l=openbsd-tech=145822792814191)

EdgeRouter Pro is not on octeon.html, put it there?

Bye, Marcus

Index: octeon.html
===
RCS file: /cvs/www/octeon.html,v
retrieving revision 1.27
diff -u -p -u -r1.27 octeon.html
--- octeon.html 13 Jan 2016 14:25:49 -  1.27
+++ octeon.html 18 Mar 2016 07:39:28 -
@@ -70,7 +70,8 @@ Portwell CAM-0100
 http://www.ubnt.com/edgemax/edgerouter-lite/;>Ubiquiti Networks
 EdgeRouter LITE
 http://www.ubnt.com/edgemax/edgerouter-poe/;>Ubiquiti Networks
-EdgeRouter PoE
+http://www.ubnt.com/edgemax/edgerouter-pro/;>Ubiquiti Networks
+EdgeRouter Pro
 
 
 

Re: New scheduler for OpenBSD

[Alexandre Ratchov]

On Fri, Mar 18, 2016 at 08:00:35PM +0100, Mark Kettenis wrote:
> > From: Bob Beck 
> > Date: Fri, 18 Mar 2016 09:20:35 -0600
> > 
> > this is cool .. but
> > 
> > I would be interested in someone comparing server workloads, as
> > opposed to interactive GUI response, using this.
> > 
> > I wouldn't be surprised that inspiriation from BFS would produce
> > better interactive response, my bigger concern would be does this
> > adversely impact how we deal with non-interactive workloads.
> 
> One other important case to test is network packet forwarding.  Some
> of our network stack is now running inside a kernel thread.  And any
> changes in the scheduling behaviour have the potential of having a
> significant impact there.
> 
> Another interesting case is the page zeroing thread.  It relies on
> priority-based scheduling to make sure it only runs if we have nothing
> better to do.
> 
> So I'm skeptical about this BFS scheduler.  Don't get me wrong; I do
> think the scheduler needs attention.  But I'm not sure a scheduler
> designed for interactive desktop use is the best option for OpenBSD.

IMHO current OpenBSD scheduler *is* designed for interactive
programs too, that's why I keep using OpenBSD for real-time audio
and didn't switch to Linux or OS X or whatever.

The browsers problems seem caused by the way pthreads behave;
browsers appear to spin.  With the proposed scheduler they spin
less.  But the real question is why they spin at all?

My 2 cents.

Re: Implement delay() using TSC

[Mike Larkin]

On Thu, Mar 17, 2016 at 09:44:22AM +0900, Masao Uebayashi wrote:
> Implement delay() using TSC
> 
> - Calculate delay using 64-bit RDTSC instruction
> - Enable tsc_delay() as delay(9) backend
> - Use tsc_delay() only when TSC is invariant
> - Configure tsc_delay() after primary CPU is identified
> - Assume all CPUs are identical

Why is this needed, or wanted? There is no explanation given above
aside from "let's make things different". Are you claiming that
delay(9) is somehow inaccurate or incorrect without this?

-ml

> 
> diff --git a/sys/arch/amd64/amd64/cpu.c b/sys/arch/amd64/amd64/cpu.c
> index df6c623..0863306 100644
> --- a/sys/arch/amd64/amd64/cpu.c
> +++ b/sys/arch/amd64/amd64/cpu.c
> @@ -330,6 +330,7 @@ cpu_attach(struct device *parent, struct device *self, 
> void *aux)
>   vaddr_t kstack;
>   struct pcb *pcb;
>  #endif
> + void tsc_delay_init(struct cpu_info *);
>  
>   /*
>* If we're an Application Processor, allocate a cpu_info
> @@ -409,6 +410,7 @@ cpu_attach(struct device *parent, struct device *self, 
> void *aux)
>  #endif /* MTRR */
>   cpu_init(ci);
>   cpu_init_mwait(sc);
> + tsc_delay_init(ci);
>   break;
>  
>   case CPU_ROLE_BP:
> @@ -432,6 +434,7 @@ cpu_attach(struct device *parent, struct device *self, 
> void *aux)
>   ioapic_bsp_id = caa->cpu_number;
>  #endif
>   cpu_init_mwait(sc);
> + tsc_delay_init(ci);
>   break;
>  
>   case CPU_ROLE_AP:
> diff --git a/sys/arch/amd64/amd64/tsc.c b/sys/arch/amd64/amd64/tsc.c
> new file mode 100644
> index 000..15242ca
> --- /dev/null
> +++ b/sys/arch/amd64/amd64/tsc.c
> @@ -0,0 +1,68 @@
> +/*
> + * Copyright (c) 2016 Masao Uebayashi 
> + *
> + * Permission to use, copy, modify, and distribute this software for any
> + * purpose with or without fee is hereby granted, provided that the above
> + * copyright notice and this permission notice appear in all copies.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +void tsc_delay_init(struct cpu_info *);
> +void tsc_delay(int);
> +uint64_t tsc2usec(uint64_t n);
> +
> +int64_t tsc_delay_mult;
> +
> +void
> +tsc_delay_init(struct cpu_info *ci)
> +{
> +#ifdef DIAGNOSTIC
> + KASSERT(ci->ci_tsc_freq != 0);
> +#endif
> + if ((ci->ci_flags & CPUF_CONST_TSC) == 0)
> + return;
> +
> + tsc_delay_mult = ci->ci_tsc_freq / 100;
> + delay_func = tsc_delay;
> +}
> +
> +void
> +tsc_delay(int usec)
> +{
> + int64_t n;
> + uint64_t now, prev;
> +
> + n = tsc_delay_mult * usec;
> + prev = rdtsc();
> + while (n > 0) {
> + CPU_BUSY_CYCLE();
> + now = rdtsc();
> + if (now < prev)
> + n -= UINT64_MAX - (prev - now);
> + else
> + n -= now - prev;
> + prev = now;
> + }
> +}
> +
> +uint64_t
> +tsc2usec(uint64_t n)
> +{
> + struct cpu_info *ci = curcpu();
> +
> + return n / ci->ci_tsc_freq * 100;
> +}
> diff --git a/sys/arch/amd64/conf/files.amd64 b/sys/arch/amd64/conf/files.amd64
> index 5d58b34..d101cf2 100644
> --- a/sys/arch/amd64/conf/files.amd64
> +++ b/sys/arch/amd64/conf/files.amd64
> @@ -97,6 +97,7 @@ define  cpu {[apid = -1]}
>  device   cpu
>  attach   cpu at mainbus
>  file arch/amd64/amd64/cpu.c  cpu
> +file arch/amd64/amd64/tsc.c  cpu
>  
>  
>  define   lapic
> 

Re: New scheduler for OpenBSD

[Ray Lai]

With this diff on my X200, YouTube used to be a stuttering mess on both 
chrome and firefox, and is now buttery smooth, even at 1080p. Thanks!

Re: CPUID in amd64/i386 boot code

[Masao Uebayashi]

On Wed, Mar 16, 2016 at 11:26:39PM -0700, Mike Larkin wrote:
> On Thu, Mar 17, 2016 at 03:15:07PM +0900, Masao Uebayashi wrote:
> > This is the intended use, avoid busy-polling of BIOS PC console if
> > running on HV.  Avoid 100% CPU usage at boot prompt on hypervisors.
> > 
> 
> Which hypervisors have you tested this on?

VMware ESXi
KVM
QEMU

> -ml
> 
> > Originally I unconditionally reverted the polling part, which was
> > introduced only for Intel Mac Mini.  After brief discussion with mikeb@,
> > I decided to leave that hack by checking HV bit in CPUID (cpu_ecxfeature).
> > 
> > diff --git a/sys/arch/amd64/stand/libsa/bioscons.c 
> > b/sys/arch/amd64/stand/libsa/bioscons.c
> > index bdff9a4..fa42751 100644
> > --- a/sys/arch/amd64/stand/libsa/bioscons.c
> > +++ b/sys/arch/amd64/stand/libsa/bioscons.c
> > @@ -30,6 +30,7 @@
> >  
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include 
> >  #include 
> > @@ -37,7 +38,7 @@
> >  #include 
> >  #include 
> >  
> > -#include 
> > +#include 
> >  
> >  #include "biosdev.h"
> >  
> > @@ -82,14 +83,17 @@ pc_getc(dev_t dev)
> > return (rv & 0xff);
> > }
> >  
> > -   /*
> > -* Wait for a character to actually become available.  Appears to
> > -* be necessary on (at least) the Intel Mac Mini.
> > -*/
> > -   do {
> > -   __asm volatile(DOINT(0x16) "; setnz %b0" : "=a" (rv) :
> > -   "0" (0x100) : "%ecx", "%edx", "cc" );
> > -   } while ((rv & 0xff) == 0);
> > +   if ((cpu_ecxfeature & CPUIDECX_HV) == 0) {
> > +   /*
> > + * Wait for a character to actually become available.
> > + * Appears to be necessary on (at least) the Intel Mac
> > + * Mini.
> > +*/
> > +   do {
> > +   __asm volatile(DOINT(0x16) "; setnz %b0" : "=a" (rv) :
> > +   "0" (0x100) : "%ecx", "%edx", "cc" );
> > +   } while ((rv & 0xff) == 0);
> > +   }
> >  
> > __asm volatile(DOINT(0x16) : "=a" (rv) : "0" (0x000) :
> > "%ecx", "%edx", "cc" );
> > diff --git a/sys/arch/i386/stand/libsa/bioscons.c 
> > b/sys/arch/i386/stand/libsa/bioscons.c
> > index 028bef3..b53abcf 100644
> > --- a/sys/arch/i386/stand/libsa/bioscons.c
> > +++ b/sys/arch/i386/stand/libsa/bioscons.c
> > @@ -27,15 +27,20 @@
> >   */
> >  
> >  #include 
> > +
> >  #include 
> >  #include 
> > +#include 
> > +
> >  #include 
> >  #include 
> >  #include 
> >  #include 
> >  /* #include  */
> >  #include 
> > -#include 
> > +
> > +#include 
> > +
> >  #include "debug.h"
> >  #include "biosdev.h"
> >  
> > @@ -80,14 +85,17 @@ pc_getc(dev_t dev)
> > return (rv & 0xff);
> > }
> >  
> > -   /*
> > -* Wait for a character to actually become available.  Appears to
> > -* be necessary on (at least) the Intel Mac Mini.
> > -*/
> > -   do {
> > -   __asm volatile(DOINT(0x16) "; setnz %b0" : "=a" (rv) :
> > -   "0" (0x100) : "%ecx", "%edx", "cc" );
> > -   } while ((rv & 0xff) == 0);
> > +   if ((cpu_ecxfeature & CPUIDECX_HV) == 0) {
> > +   /*
> > + * Wait for a character to actually become available.
> > + * Appears to be necessary on (at least) the Intel Mac
> > + * Mini.
> > +*/
> > +   do {
> > +   __asm volatile(DOINT(0x16) "; setnz %b0" : "=a" (rv) :
> > +   "0" (0x100) : "%ecx", "%edx", "cc" );
> > +   } while ((rv & 0xff) == 0);
> > +   }
> >  
> > __asm volatile(DOINT(0x16) : "=a" (rv) : "0" (0x000) :
> > "%ecx", "%edx", "cc" );
> > 
> > On Thu, Mar 17, 2016 at 02:58:58PM +0900, Masao Uebayashi wrote:
> > > Factor out CPUID code in mdrandom(), invoke it once, then save the
> > > result.  I'll use it to switch behavior depending on HV or not.
> > > 
> > > efiboot is not tested.
> > > 
> > > Comments?
> > 
> > > >From 104cb04bbbd0f7e40758938cc3103b2370a2285c Mon Sep 17 00:00:00 2001
> > > From: Masao Uebayashi 
> > > Date: Thu, 10 Mar 2016 21:03:07 +0900
> > > Subject: [PATCH 1/3] Factor out CPUID instruction in amd64 boot code
> > > 
> > > ---
> > >  sys/arch/amd64/stand/boot/Makefile   |  1 +
> > >  sys/arch/amd64/stand/boot/srt0.S |  1 +
> > >  sys/arch/amd64/stand/cdboot/Makefile |  1 +
> > >  sys/arch/amd64/stand/cdboot/srt0.S   |  2 +
> > >  sys/arch/amd64/stand/libsa/cpuid.S   | 69 
> > > 
> > >  sys/arch/amd64/stand/libsa/libsa.h   |  7 
> > >  sys/arch/amd64/stand/libsa/random_i386.S | 22 +-
> > >  sys/arch/amd64/stand/pxeboot/Makefile|  1 +
> > >  sys/arch/amd64/stand/pxeboot/srt0.S  |  2 +
> > >  9 files changed, 86 insertions(+), 20 deletions(-)
> > >  create mode 100644 sys/arch/amd64/stand/libsa/cpuid.S
> > > 
> > > diff --git a/sys/arch/amd64/stand/boot/Makefile 
> > > b/sys/arch/amd64/stand/boot/Makefile
> > > index 359ea31..5811646 100644
> > > --- 

Re: New scheduler for OpenBSD

[Henrik Friedrichsen]

Hey,

On Tue, Mar 15, 2016 at 03:05:47PM +0100, Michal Mazurek wrote:
> Chrome still isn't smooth.
> 
> Please test, and let me know if the performance of something else
> degrades.

While Chrome may not be 100% smooth yet, the system is a lot more
interactive. I can now play YouTube videos without stutters while doing
other things.

So for me it's a major improvement, thanks!

arm: remove ixp425

[Patrick Wildt]

Hi,

based on the SA1 diff, this change also removes IXP425.

Patrick

diff --git sys/arch/arm/arm/cpu.c sys/arch/arm/arm/cpu.c
index 593bdac..5c7e385 100644
--- sys/arch/arm/arm/cpu.c
+++ sys/arch/arm/arm/cpu.c
@@ -146,13 +146,6 @@ static const char * const pxa27x_steppings[16] = {
"rev 12",   "rev 13",   "rev 14",   "rev 15"
 };
 
-static const char * const ixp425_steppings[16] = {
-   "step 0",   "rev 1","rev 2","rev 3",
-   "rev 4","rev 5","rev 6","rev 7",
-   "rev 8","rev 9","rev 10",   "rev 11",
-   "rev 12",   "rev 13",   "rev 14",   "rev 15"
-};
-
 struct cpuidtab {
u_int32_t   cpuid;
enumcpu_class cpu_class;
@@ -207,13 +200,6 @@ const struct cpuidtab cpuids[] = {
{ CPU_ID_PXA210C,   CPU_CLASS_XSCALE,   "PXA210",
  pxa2x0_steppings },
 
-   { CPU_ID_IXP425_533,CPU_CLASS_XSCALE,   "IXP425 533MHz",
- ixp425_steppings },
-   { CPU_ID_IXP425_400,CPU_CLASS_XSCALE,   "IXP425 400MHz",
- ixp425_steppings },
-   { CPU_ID_IXP425_266,CPU_CLASS_XSCALE,   "IXP425 266MHz",
- ixp425_steppings },
-
{ CPU_ID_ARM1136JS, CPU_CLASS_ARM11J,   "ARM1136J-S",
  generic_steppings },
{ CPU_ID_ARM1136JSR1,   CPU_CLASS_ARM11J,   "ARM1136J-S R1",
@@ -415,7 +401,7 @@ identify_arm_cpu(struct device *dv, struct cpu_info *ci)
 #endif
 
 #if defined(CPU_XSCALE_80200) || defined(CPU_XSCALE_80321) || \
-defined(CPU_XSCALE_PXA2X0) || defined(CPU_XSCALE_IXP425)
+defined(CPU_XSCALE_PXA2X0)
case CPU_CLASS_XSCALE:
 #endif
break;
diff --git sys/arch/arm/arm/cpufunc.c sys/arch/arm/arm/cpufunc.c
index a0472f6..178bec9 100644
--- sys/arch/arm/arm/cpufunc.c
+++ sys/arch/arm/arm/cpufunc.c
@@ -66,11 +66,6 @@
 #include 
 #endif
 
-#ifdef CPU_XSCALE_IXP425
-#include 
-#include 
-#endif
-
 #if defined(CPU_XSCALE_80200) || defined(CPU_XSCALE_80321)
 #include 
 #endif
@@ -328,7 +323,7 @@ struct cpu_functions armv7_cpufuncs = {
 #endif /* CPU_ARMv7 */
 
 #if defined(CPU_XSCALE_80200) || defined(CPU_XSCALE_80321) || \
-defined(CPU_XSCALE_PXA2X0) || defined(CPU_XSCALE_IXP425)
+defined(CPU_XSCALE_PXA2X0)
 struct cpu_functions xscale_cpufuncs = {
/* CPU functions */
 
@@ -384,7 +379,7 @@ struct cpu_functions xscale_cpufuncs = {
xscale_setup/* cpu setup*/
 };
 #endif
-/* CPU_XSCALE_80200 || CPU_XSCALE_80321 || CPU_XSCALE_PXA2X0 || 
CPU_XSCALE_IXP425 */
+/* CPU_XSCALE_80200 || CPU_XSCALE_80321 || CPU_XSCALE_PXA2X0 */
 
 /*
  * Global constants also used by locore.s
@@ -396,7 +391,7 @@ u_int cpu_reset_needs_v4_MMU_disable;   /* flag used in 
locore.s */
 
 #if defined(CPU_ARM9E) || defined(CPU_ARM10) || defined(CPU_ARM11) || \
 defined(CPU_XSCALE_80200) || defined(CPU_XSCALE_80321) || \
-defined(CPU_XSCALE_PXA2X0) || defined(CPU_XSCALE_IXP425)
+defined(CPU_XSCALE_PXA2X0)
 static void get_cachetype_cp15 (void);
 
 /* Additional cache information local to this file.  Log2 of some of the
@@ -824,23 +819,6 @@ set_cpufuncs()
return 0;
}
 #endif /* CPU_XSCALE_PXA2X0 */
-#ifdef CPU_XSCALE_IXP425
-   if (cputype == CPU_ID_IXP425_533 || cputype == CPU_ID_IXP425_400 ||
-   cputype == CPU_ID_IXP425_266) {
-   ixp425_icu_init();
-
-   cpufuncs = xscale_cpufuncs;
-#if defined(PERFCTRS)
-   xscale_pmu_init();
-#endif
-
-   cpu_reset_needs_v4_MMU_disable = 1; /* XScale needs it */
-   get_cachetype_cp15();
-   pmap_pte_init_xscale();
-
-   return 0;
-   }
-#endif /* CPU_XSCALE_IXP425 */
/*
 * B. And the answer was ...
 */
@@ -967,7 +945,7 @@ armv7_setup()
 #endif /* CPU_ARMv7 */
 
 #if defined(CPU_XSCALE_80200) || defined(CPU_XSCALE_80321) || \
-defined(CPU_XSCALE_PXA2X0) || defined(CPU_XSCALE_IXP425)
+defined(CPU_XSCALE_PXA2X0)
 void
 xscale_setup()
 {
@@ -1018,4 +996,4 @@ xscale_setup()
__asm volatile("mcr p15, 0, %0, c1, c0, 1"
: : "r" (auxctl));
 }
-#endif /* CPU_XSCALE_80200 || CPU_XSCALE_80321 || CPU_XSCALE_PXA2X0 || 
CPU_XSCALE_IXP425 */
+#endif /* CPU_XSCALE_80200 || CPU_XSCALE_80321 || CPU_XSCALE_PXA2X0 */
diff --git sys/arch/arm/conf/files.arm sys/arch/arm/conf/files.arm
index fd9d508..fc37ca1 100644
--- sys/arch/arm/conf/files.arm
+++ sys/arch/arm/conf/files.arm
@@ -43,14 +43,12 @@ filearch/arm/arm/cpufunc_asm_arm10.S
cpu_arm9e | cpu_arm10
 file   arch/arm/arm/cpufunc_asm_armv4.Scpu_arm9e | cpu_arm10 |
cpu_xscale_80200 |
cpu_xscale_80321 |
-   cpu_xscale_ixp425 |

Octeon memory setup

[Visa Hankala]

Octeon firmware provides a list of usable memory regions. I would like
to make the memory setup routine use the list instead of hardcoded
assumptions. EdgeRouter Pro has a memory layout that does not match
with the current code, which causes a kernel crash.

I have tested this patch on EdgeRouter Lite and EdgeRouter Pro. Tests on
other Octeon boards are welcome.

OK?

Index: arch/octeon/include/octeonvar.h
===
RCS file: src/sys/arch/octeon/include/octeonvar.h,v
retrieving revision 1.24
diff -u -p -r1.24 octeonvar.h
--- arch/octeon/include/octeonvar.h 20 Jul 2015 19:44:32 -  1.24
+++ arch/octeon/include/octeonvar.h 17 Mar 2016 14:05:37 -
@@ -273,6 +273,24 @@ struct boot_info {
uint32_t config_flags;
 };
 
+struct octeon_bootmem_desc {
+   uint32_tlock;
+   uint32_tflags;
+   uint64_thead_addr;
+   uint32_tmajor_version;
+   uint32_tminor_version;
+   uint64_tapp_data_addr;
+   uint64_tapp_data_size;
+   uint32_tnamed_block_num_blocks;
+   uint32_tnamed_block_name_len;
+   uint64_tnamed_block_array_addr;
+};
+
+struct octeon_bootmem_block {
+   uint64_tnext;
+   uint64_tsize;
+};
+
 extern struct boot_desc *octeon_boot_desc;
 extern struct boot_info *octeon_boot_info;
 
Index: arch/octeon/octeon/machdep.c
===
RCS file: src/sys/arch/octeon/octeon/machdep.c,v
retrieving revision 1.72
diff -u -p -r1.72 machdep.c
--- arch/octeon/octeon/machdep.c6 Mar 2016 19:42:27 -   1.72
+++ arch/octeon/octeon/machdep.c17 Mar 2016 14:05:37 -
@@ -154,50 +154,48 @@ struct timecounter ipdclock_timecounter 
 void
 octeon_memory_init(struct boot_info *boot_info)
 {
-   extern char end[];
+   struct octeon_bootmem_block *block;
+   struct octeon_bootmem_desc *memdesc;
+   paddr_t blockaddr;
+   uint64_t fp, lp;
int i;
-   uint32_t realmem_bytes;
 
-   realmem_bytes = boot_info->dram_size << 20;
-   physmem = atop(realmem_bytes);
+   physmem = atop((uint64_t)boot_info->dram_size << 20);
 
-   /*-
-* Octeon Memory looks as follows:
- *   PA
-* First 256 MB DR0
-*     to    0FFF 
-* Second 256 MB DR1
-*  0004 1000  to   0004 1FFF 
-* Over 512MB Memory DR2  15.5GB
-*   2000  to   0003  
-*/
-
-   /* DR0, ignoring everything below the kernel image */
-   mem_layout[0].mem_first_page =
-   atop(CKSEG0_TO_PHYS(round_page((vaddr_t;
-   if (physmem > atop(256 << 20))
-   mem_layout[0].mem_last_page = atop(256 << 20);
-   else
-   mem_layout[0].mem_last_page = physmem;
-
-   /* DR1 */
-   i = 1;
-   if (physmem > atop(256 << 20)) {
-   mem_layout[i].mem_first_page = atop(0x41000ULL);
-   if (physmem > atop(512 << 20))
-   mem_layout[i].mem_last_page = atop(0x42000ULL);
-   else
-   mem_layout[i].mem_last_page =
-   atop(0x41000ULL) + physmem - atop(256 << 20);
-   i++;
-   }
+   if (boot_info->phys_mem_desc_addr == 0)
+   panic("bootmem desc is missing");
+   memdesc = (struct octeon_bootmem_desc *)PHYS_TO_XKPHYS(
+   boot_info->phys_mem_desc_addr, CCA_CACHED);
+   printf("bootmem desc 0x%x version %d.%d\n",
+   boot_info->phys_mem_desc_addr, memdesc->major_version,
+   memdesc->minor_version);
+   if (memdesc->major_version > 3)
+   panic("unhandled bootmem desc version %d.%d",
+   memdesc->major_version, memdesc->minor_version);
+
+   blockaddr = memdesc->head_addr;
+   if (blockaddr == 0)
+   panic("bootmem list is empty");
+   for (i = 0; i < MAXMEMSEGS && blockaddr != 0; blockaddr = block->next) {
+   block = (struct octeon_bootmem_block *)PHYS_TO_XKPHYS(
+   blockaddr, CCA_CACHED);
+   printf("avail phys mem 0x%016lx - 0x%016lx\n", blockaddr,
+   (paddr_t)(blockaddr + block->size));
+
+   fp = atop(round_page(blockaddr));
+   lp = atop(trunc_page(blockaddr + block->size));
 
-   /* DR2 */
-   if (physmem > atop(512 << 20)) {
-   mem_layout[i].mem_first_page = atop(0x2000ULL);
-   mem_layout[i].mem_last_page =
-   atop(0x2000ULL) + physmem - atop(512 << 20);
-   /* i++; */
+   /* Clamp to the range of the pmap. */
+   if (fp > atop(pfn_to_pad(PG_FRAME)))
+   continue;
+   if (lp > atop(pfn_to_pad(PG_FRAME)) + 1)
+

Re: multitouch support in wsmouse 1/3

[Joerg Jung]

> On 17 Mar 2016, at 13:58, Martin Pieuchot  wrote:
> 
> On 13/03/16(Sun) 18:37, Ulf Brosziewski wrote:
>> The diffs below are a rewrite of the input-processing part of wsmouse. It
>> adds support for multitouch input.
>> 
>> I have split the set of diffs into three parts and I will post part 2 and 3
>> in separate messages. Part 1 below contains all patches for wscons, part 2
>> is for the hardware drivers, part 3 is a patch for the synaptics driver in
>> xenocara (compiling that driver will require the modified version of
>> wsconsio.h in /usr/include/dev/wscons).
> 
> I'm really afraid because this is just a single diff split in 3, they
> are not independent.  Plus since your original mails included a broken
> diff I doubt anybody tried it. 
> 
> That said you've done some great work and I like it a lot.
> 
> Could you prepare a diff with all the new stuff that does do change

I guess you wanted to write s/does/doesn’t/ above.
Other than that, yes I agree that would be the right direction.

> anything in the existing code?  This could go in directly.
> 
> Which hardware still need to be tested?
>