Re: Scheduler hack for multi-threaded processes

[Mark Kettenis]

> From: Amit Kulkarni 
> Date: Sun, 20 Mar 2016 17:57:49 -0500
> 
> On Sat, Mar 19, 2016 at 4:35 PM, Bob  wrote:
> 
> >
> > 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
> >
> >
> +1. Previously, when I did a cvs update with original scheduler code, doing
> the ports update the machine always froze solid while doing cvs update,
> taking 3 minutes to recover. This time with Martin's patch, the freezing
> period seems to have decreased quite a bit, although the freeze still
> happens. Stefan's amap diff and Bob's VFS/UVM diff also seems to have a
> made a difference.
> 
> Pentium G2020 2.9GHz dual core Ivy bridge 22nm... 8 GB RAM
> 
> IMHO, this patch should go in!

No.  It's a hack. It points out aproblem that should be investigated
deeper. 

Re: Scheduler hack for multi-threaded processes

[Amit Kulkarni]

On Sat, Mar 19, 2016 at 4:35 PM, Bob  wrote:

>
> 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
>
>
+1. Previously, when I did a cvs update with original scheduler code, doing
the ports update the machine always froze solid while doing cvs update,
taking 3 minutes to recover. This time with Martin's patch, the freezing
period seems to have decreased quite a bit, although the freeze still
happens. Stefan's amap diff and Bob's VFS/UVM diff also seems to have a
made a difference.

Pentium G2020 2.9GHz dual core Ivy bridge 22nm... 8 GB RAM

IMHO, this patch should go in!

Thanks

Re: New scheduler for OpenBSD

[Hrvoje Popovski]

On 18.3.2016. 20:00, Mark Kettenis wrote:
> 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.

I've done some basic PPS test over ix interface's and numbers are the
same with or without new schedule, ie. 720pps.

routing only
pf=NO
kern.pool_debug=0
net.inet.ip.forwarding=1
net.inet.ip.ifq.maxlen=8192
kern.maxclusters=32768

Re: Scheduler hack for multi-threaded processes

[Erling Westenvik]

On Sun, Mar 20, 2016 at 09:04:22PM +0100, Norman Golisz wrote:
> Hi Martin,
> 
> On Sat Mar 19 2016 13:53, Martin Pieuchot wrote:
> > I'm also interested in hearing from more people using multi-threaded
> > applications.
> 
> your patch - just like Michal's - improves the situation a lot.

For now I've only applied Martin's patch. Are there any reasons not to
apply both?
 
> Watching videos (HD) fullscreen in a browser without stuttering - the
> GUI stays responsive as well.

I'm kinda stunned here. For years I've been telling my girlfriend, my
friends and my children that I cannot watch all those funny YouTube
videos they have insisted on sending me. Of course there was always the
possibility of viewing them through smtube, minitube, youtube-dl and
whatnot, but ...  but no, those were really not "realtime" options.

Then now all of a sudden I can play Peppa Pig episodes for my youngest
one. Full screen. HD. Flawlessly. On my old dual core ThinkPad t500 with
"only" 4GB RAM. In Firefox on OpenBSD!!! Woah...

> 
> Thank you both!
> 

Seconded. At least as long as my work schedule won't suffocate as a
result of spending too much time watching vidoes...

Re: Scheduler hack for multi-threaded processes

[Norman Golisz]

Hi Martin,

On Sat Mar 19 2016 13:53, Martin Pieuchot wrote:
> I'm also interested in hearing from more people using multi-threaded
> applications.

your patch - just like Michal's - improves the situation a lot.

Watching videos (HD) fullscreen in a browser without stuttering - the
GUI stays responsive as well.

Thank you both!

Re: vnet(4) memory leak

[Mark Kettenis]

> Date: Sat, 19 Mar 2016 14:15:47 +0100
> From: 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.

ok kettenis@

> 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.c26 Feb 2016 13:41:51 -  1.54
> +++ vnet.c19 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

[Mark Kettenis]

> Date: Sat, 19 Mar 2016 09:06:26 +0100
> From: 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?

If we still hit the remaining spinlocks in libpthread, we
should probably replace the ones we hit with mutexes like I did for
malloc.

Re: tcp syn cache random reseed

[Alexander Bluhm]

On Sat, Mar 19, 2016 at 10:41:06PM +0100, Alexander Bluhm wrote:
> Perhaps the tcps_sc_seedrandom counter with a netstat -s line should
> be commited anyway to show the problem.

ok?

bluhm

Index: sys/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
--- sys/netinet/tcp_input.c 7 Mar 2016 18:44:00 -   1.314
+++ sys/netinet/tcp_input.c 19 Mar 2016 20:09:25 -
@@ -3371,8 +3371,10 @@ syn_cache_insert(struct syn_cache *sc, s
 * If there are no entries in the hash table, reinitialize
 * the hash secrets.
 */
-   if (tcp_syn_cache_count == 0)
+   if (tcp_syn_cache_count == 0) {
arc4random_buf(tcp_syn_hash, sizeof(tcp_syn_hash));
+   tcpstat.tcps_sc_seedrandom++;
+   }
 
SYN_HASHALL(sc->sc_hash, >sc_src.sa, >sc_dst.sa);
sc->sc_bucketidx = sc->sc_hash % tcp_syn_cache_size;
Index: sys/netinet/tcp_var.h
===
RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/tcp_var.h,v
retrieving revision 1.109
diff -u -p -r1.109 tcp_var.h
--- sys/netinet/tcp_var.h   27 Aug 2015 20:56:16 -  1.109
+++ sys/netinet/tcp_var.h   19 Mar 2016 20:53:39 -
@@ -440,6 +440,7 @@ struct  tcpstat {
u_int64_t tcps_sc_dropped;  /* # of SYNs dropped (no route/mem) */
u_int64_t tcps_sc_collisions;   /* # of hash collisions */
u_int64_t tcps_sc_retransmitted;/* # of retransmissions */
+   u_int64_t tcps_sc_seedrandom;   /* # of syn cache seeds with random */
 
u_int64_t tcps_conndrained; /* # of connections drained */
 
Index: usr.bin/netstat/inet.c
===
RCS file: /data/mirror/openbsd/cvs/src/usr.bin/netstat/inet.c,v
retrieving revision 1.144
diff -u -p -r1.144 inet.c
--- usr.bin/netstat/inet.c  20 Aug 2015 22:32:41 -  1.144
+++ usr.bin/netstat/inet.c  20 Mar 2016 18:25:55 -
@@ -455,6 +455,7 @@ tcp_stats(char *name)
p(tcps_sc_dupesyn, "\t%qd duplicate SYN%s received for entries "
"already in the cache\n");
p(tcps_sc_dropped, "\t%qd SYN%s dropped (no route or no space)\n");
+   p(tcps_sc_seedrandom, "\t%qd SYN cache seed%s with new random\n");
 
p(tcps_sack_recovery_episode, "\t%qd SACK recovery episode%s\n");
p(tcps_sack_rexmits,

Re: tcp syn cache random reseed

[Alexander Bluhm]

On Sat, Mar 19, 2016 at 10:41:06PM +0100, Alexander Bluhm wrote:
> The drawback is that the the cache lookup has to be done in two syn
> caches when an ACK arrives.

This can be prevented most of the time.  Switch the cache only after
10 uses.  So most of the time the passive cache is empty and
then no lookup is done.

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 20 Mar 2016 17:47:08 -
@@ -3260,40 +3260,46 @@ 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]))
+inttcp_syn_use_limit = 10;
+
+struct syn_cache_set {
+struct syn_cache_head scs_buckethead[TCP_SYN_HASH_SIZE];
+intscs_count;
+intscs_use;
+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 +3311,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--;
timeout_del(>sc_timer);
-   tcp_syn_cache_count--;
+   sc->sc_set->scs_count--;
 }
 
 void
@@ -3351,8 +3356,10 @@ syn_cache_init(void)
int i;
 
/* Initialize the hash buckets. */
-   for (i = 0; i < tcp_syn_cache_size; i++)
-   TAILQ_INIT(_syn_cache[i].sch_bucket);
+   for (i = 0; i < tcp_syn_cache_size; i++) {
+   

multitouch support again

[Ulf Brosziewski]

I have been asked to prepare a less invasive version of
the MT diffs I posted a week ago. Here it is. It doesn't
delete wsmouse_input(). The old and the new infrastructure
coexist in wsmouse, and only the touchpad drivers have been
changed to use the new one. Except for a stylistic detail
(s/timespeccpy/memcpy/), nothing else has changed, and the
descriptions I added last week apply to this version as
well (the synaptics diff, which needs the modified wsconsio.h,
is the first one here, the rest is for the kernel).

Tests have been made with an Elantech-v4 touchpad, an ALPS
Glidepoint, and an old Synaptics touchpad. I couldn't test
the older Elantech models, more recent Synaptics models, or
models that run with hidmt or ubcmtp. (The December version
had more tests, but this isn't exactly the same code anymore.)


Index: src/wsconscomm.c
===
RCS file: /cvs/xenocara/driver/xf86-input-synaptics/src/wsconscomm.c,v
retrieving revision 1.13
diff -u -p -r1.13 wsconscomm.c
--- src/wsconscomm.c29 Aug 2015 08:48:28 -  1.13
+++ src/wsconscomm.c11 Mar 2016 20:46:30 -
@@ -215,45 +215,29 @@ WSConsReadHwState(InputInfoPtr pInfo,
 hw->y = priv->maxy - event->value + priv->miny;
 hw->cumulative_dy = hw->y;
 break;
-case WSCONS_EVENT_MOUSE_ABSOLUTE_Z:
+case WSCONS_EVENT_TOUCH_PRESSURE:
 hw->z = event->value;
 break;
-case WSCONS_EVENT_MOUSE_ABSOLUTE_W:
-if (priv->model == MODEL_ELANTECH) {
-/* Elantech touchpads report number of fingers directly. */
-hw->fingerWidth = 5;
-hw->numFingers = event->value;
-break;
-}
-/* XXX magic number mapping which is mirrored in pms driver */
-switch (event->value) {
-case 0:
-hw->fingerWidth = 5;
-hw->numFingers = 2;
-break;
-case 1:
+case WSCONS_EVENT_TOUCH_CONTACTS:
+hw->numFingers = event->value;
+if (hw->numFingers == 0)
+hw->fingerWidth = 0;
+else if (hw->fingerWidth == 0)
 hw->fingerWidth = 5;
-hw->numFingers = 3;
-break;
-case 4 ... 5:
-hw->fingerWidth = event->value;
-hw->numFingers = 1;
-break;
-}
+break;
+case WSCONS_EVENT_TOUCH_WIDTH:
+hw->fingerWidth = event->value;
+break;
+case WSCONS_EVENT_TOUCH_RESET:
+/*
+ * The contact count or the active MT-slot has changed.
+ * Suppress pointer motion and two-finger scrolling.
+ */
+priv->count_packet_finger = 0;
+priv->vert_scroll_twofinger_on = FALSE;
+priv->horiz_scroll_twofinger_on = FALSE;
 break;
 case WSCONS_EVENT_SYNC:
-if (hw->z == 0) {
-hw->fingerWidth = 0;
-hw->numFingers = 0;
-} else if (hw->numFingers == 0) {
-/*
- * Because W may be 0 already, a two-finger touch on a
- * Synaptics touchpad doesn't necessarily produce an update
- * event for W.
- */
-hw->fingerWidth = 5;
-hw->numFingers = 2;
-}
 hw->millis = 1000 * event->time.tv_sec +
 event->time.tv_nsec / 100;
 SynapticsCopyHwState(hwRet, hw);
Index: dev/hid/hidmt.c
===
RCS file: /cvs/src/sys/dev/hid/hidmt.c,v
retrieving revision 1.1
diff -u -p -r1.1 hidmt.c
--- dev/hid/hidmt.c 20 Jan 2016 01:26:00 -  1.1
+++ dev/hid/hidmt.c 20 Mar 2016 14:22:49 -
@@ -329,20 +329,15 @@ hidmt_input(struct hidmt *mt, uint8_t *d
width = 50;
}

-   wsmouse_input(mt->sc_wsmousedev, mt->sc_button,
+   WSMOUSE_TOUCH(mt->sc_wsmousedev, mt->sc_button,
(mt->last_x = mt->sc_contacts[i].x),
(mt->last_y = mt->sc_contacts[i].y),
-   width, tips,
-   WSMOUSE_INPUT_ABSOLUTE_X |
-   WSMOUSE_INPUT_ABSOLUTE_Y |
-   WSMOUSE_INPUT_ABSOLUTE_Z |
-   WSMOUSE_INPUT_ABSOLUTE_W);
+   width, tips);
} else {
-   wsmouse_input(mt->sc_wsmousedev, mt->sc_button,
+   WSMOUSE_INPUT(mt->sc_wsmousedev, mt->sc_button,
(mt->last_x - mt->sc_contacts[i].x),
(mt->last_y - mt->sc_contacts[i].y),
-   0, 0,
-  

Re: Remove build machinery for non-UTF-8 charsets

[Jeremie Courreges-Anglas]

Stefan Sperling  writes:

> On Fri, Mar 18, 2016 at 01:49:05AM +0100, Jeremie Courreges-Anglas wrote:
>> 
>> 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?
>
> OK.
>
> I was just about to prepare a similar diff and already sent two chunks
> which are part of this diff which I missed when you posted it.
>
> We should also remove the corresponding .src files from share/locale/ctype
> and there's a share/locale/ctype/charset subdirectory with files which
> I think can be deleted as well.

Those are included by *.src files at the top level.

> I haven't tested a build without these
> files yet, though.

mkr still happy.

ok?

R bg_BG.CP1251.src
R el_GR.ISO8859-7.src
R en_US.ASCII.src
R en_US.DIS_8859-15.src
R en_US.ISO_8859-1.src
R en_US.ISO_8859-2.src
R en_US.ISO_8859-4.src
R hy_AM.ARMSCII-8.src
R ja_JP.CTEXT.src
R ja_JP.ISO-2022-JP-2.src
R ja_JP.ISO-2022-JP.src
R ja_JP.SJIS.src
R ja_JP.eucJP.src
R ko_KR.eucKR.src
R lt_LT.ISO8859-13.src
R ru_RU.CP866.src
R ru_RU.ISO_8859-5.src
R ru_RU.KOI8-R.src
R tr_TR.ISO8859-9.src
R uk_UA.KOI8-U.src
R zh_CN.GB18030.src
R zh_CN.eucCN.src
R zh_TW.BIG5.src
R zh_TW.eucTW.src
R charset/ASCII
R charset/GB2312
R charset/JISX0201-left
R charset/JISX0201-right
R charset/JISX0208-1978
R charset/JISX0208-1983
R charset/Latin-1
R charset/Latin-2
R charset/Latin-3
R charset/Latin-4
R charset/Latin-5
R charset/Latin-6
R charset/Latin-6+
R charset/Latin-Cyrillic
R charset/Latin-Greek
R charset/Latin-Hebrew


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

Re: more armreg.h cleanup

[Patrick Wildt]

On Mon, Mar 21, 2016 at 12:52:17AM +1100, Jonathan Gray wrote:
> Remove defines for unsupported chips, add V5TEJ and remove incorrect
> ARCH_V7 define.  The number ARM Ltd armv7 chips set here is 0xf,
> documented as 'Defined by CPUID scheme'.
> 
> Index: armreg.h
> ===
> RCS file: /cvs/src/sys/arch/arm/include/armreg.h,v
> retrieving revision 1.24
> diff -u -p -r1.24 armreg.h
> --- armreg.h  19 Mar 2016 09:51:24 -  1.24
> +++ armreg.h  20 Mar 2016 13:40:36 -
> @@ -109,35 +109,13 @@
>  /* The high-order byte is always the implementor */
>  #define CPU_ID_IMPLEMENTOR_MASK  0xff00
>  #define CPU_ID_ARM_LTD   0x4100 /* 'A' */
> -#define CPU_ID_DEC   0x4400 /* 'D' */
>  #define CPU_ID_INTEL 0x6900 /* 'i' */
> -#define CPU_ID_TI0x5400 /* 'T' */
>  
> -/* How to decide what format the CPUID is in. */
> -#define CPU_ID_ISOLD(x)  (((x) & 0xf000) == 0x)
> -#define CPU_ID_IS7(x)(((x) & 0xf000) == 0x7000)
> -#define CPU_ID_ISNEW(x)  (!CPU_ID_ISOLD(x) && !CPU_ID_IS7(x))
> -
> -/* On ARM3 and ARM6, this byte holds the foundry ID. */
> -#define CPU_ID_FOUNDRY_MASK  0x00ff
> -#define CPU_ID_FOUNDRY_VLSI  0x0056
> -
> -/* On ARM7 it holds the architecture and variant (sub-model) */
> -#define CPU_ID_7ARCH_MASK0x0080
> -#define CPU_ID_7ARCH_V3  0x
> -#define CPU_ID_7ARCH_V4T 0x0080
> -#define CPU_ID_7VARIANT_MASK 0x007f
> -
> -/* On more recent ARMs, it does the same, but in a different format */
>  #define CPU_ID_ARCH_MASK 0x000f
> -#define CPU_ID_ARCH_V3   0x
> -#define CPU_ID_ARCH_V4   0x0001
> -#define CPU_ID_ARCH_V4T  0x0002
> -#define CPU_ID_ARCH_V5   0x0003
> -#define CPU_ID_ARCH_V5T  0x0004
>  #define CPU_ID_ARCH_V5TE 0x0005
> +#define CPU_ID_ARCH_V5TEJ0x0006
>  #define CPU_ID_ARCH_V6   0x0007
> -#define CPU_ID_ARCH_V7   0x0008
> +#define CPU_ID_ARCH_CPUID0x000f
>  #define CPU_ID_VARIANT_MASK  0x00f0
>  
>  /* Next three nybbles are part number */
> @@ -153,29 +131,6 @@
>  
>  /* Individual CPUs are probably best IDed by everything but the revision. */
>  #define CPU_ID_CPU_MASK  0xfff0
> -
> -/* Fake CPU IDs for ARMs without CP15 */
> -#define CPU_ID_ARM2  0x41560200
> -#define CPU_ID_ARM2500x41560250
> -
> -/* Pre-ARM7 CPUs -- [15:12] == 0 */
> -#define CPU_ID_ARM3  0x41560300
> -#define CPU_ID_ARM6000x41560600
> -#define CPU_ID_ARM6100x41560610
> -#define CPU_ID_ARM6200x41560620
> -
> -/* ARM7 CPUs -- [15:12] == 7 */
> -#define CPU_ID_ARM7000x41007000 /* XXX This is a guess. */
> -#define CPU_ID_ARM7100x41007100
> -#define CPU_ID_ARM7500   0x41027100 /* XXX This is a guess. */
> -#define CPU_ID_ARM710A   0x41047100 /* inc ARM7100 */
> -#define CPU_ID_ARM7500FE 0x41077100
> -#define CPU_ID_ARM710T   0x41807100
> -#define CPU_ID_ARM720T   0x41807200
> -#define CPU_ID_ARM740T8K 0x41807400 /* XXX no MMU, 8KB cache */
> -#define CPU_ID_ARM740T4K 0x41817400 /* XXX no MMU, 4KB cache */
> -
> -/* Post-ARM7 CPUs */
>  #define CPU_ID_ARM926EJS 0x41069260
>  #define CPU_ID_ARM946ES  0x41049460 /* XXX no MMU */
>  #define CPU_ID_ARM966ES  0x41049660 /* XXX no MMU */
> @@ -233,18 +188,6 @@
>  #define CPU_ID_CORTEX_A720x410fd080
>  #define CPU_ID_CORTEX_A72_R1 0x411fd080
>  #define CPU_ID_CORTEX_A72_MASK   0xff00
> -
> -/* ARM3-specific coprocessor 15 registers */
> -#define ARM3_CP15_FLUSH  1
> -#define ARM3_CP15_CONTROL2
> -#define ARM3_CP15_CACHEABLE  3
> -#define ARM3_CP15_UPDATEABLE 4
> -#define ARM3_CP15_DISRUPTIVE 5   
> -
> -/* ARM3 Control register bits */
> -#define ARM3_CTL_CACHE_ON0x0001
> -#define ARM3_CTL_SHARED  0x0002
> -#define ARM3_CTL_MONITOR 0x0004
>  
>  /*
>   * Post-ARM3 CP15 registers:
> 

Looks good to me, ok patrick@.

Re: more armreg.h cleanup

[Brandon Mercer]

On Mon, Mar 21, 2016 at 12:52:17AM +1100, Jonathan Gray wrote:
> Remove defines for unsupported chips, add V5TEJ and remove incorrect
> ARCH_V7 define.  The number ARM Ltd armv7 chips set here is 0xf,
> documented as 'Defined by CPUID scheme'.


Looks OK to me. Compile tested only. 

Re: Remove build machinery for non-UTF-8 charsets

[Stefan Sperling]

On Fri, Mar 18, 2016 at 01:49:05AM +0100, Jeremie Courreges-Anglas wrote:
> 
> 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?

OK.

I was just about to prepare a similar diff and already sent two chunks
which are part of this diff which I missed when you posted it.

We should also remove the corresponding .src files from share/locale/ctype
and there's a share/locale/ctype/charset subdirectory with files which
I think can be deleted as well. I haven't tested a build without these
files yet, though.

> 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.inc  3 Jul 2015 11:15:19 -   1.20
> +++ lib/libc/locale/Makefile.inc  17 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 

more armreg.h cleanup

[Jonathan Gray]

Remove defines for unsupported chips, add V5TEJ and remove incorrect
ARCH_V7 define.  The number ARM Ltd armv7 chips set here is 0xf,
documented as 'Defined by CPUID scheme'.

Index: armreg.h
===
RCS file: /cvs/src/sys/arch/arm/include/armreg.h,v
retrieving revision 1.24
diff -u -p -r1.24 armreg.h
--- armreg.h19 Mar 2016 09:51:24 -  1.24
+++ armreg.h20 Mar 2016 13:40:36 -
@@ -109,35 +109,13 @@
 /* The high-order byte is always the implementor */
 #define CPU_ID_IMPLEMENTOR_MASK0xff00
 #define CPU_ID_ARM_LTD 0x4100 /* 'A' */
-#define CPU_ID_DEC 0x4400 /* 'D' */
 #define CPU_ID_INTEL   0x6900 /* 'i' */
-#define CPU_ID_TI  0x5400 /* 'T' */
 
-/* How to decide what format the CPUID is in. */
-#define CPU_ID_ISOLD(x)(((x) & 0xf000) == 0x)
-#define CPU_ID_IS7(x)  (((x) & 0xf000) == 0x7000)
-#define CPU_ID_ISNEW(x)(!CPU_ID_ISOLD(x) && !CPU_ID_IS7(x))
-
-/* On ARM3 and ARM6, this byte holds the foundry ID. */
-#define CPU_ID_FOUNDRY_MASK0x00ff
-#define CPU_ID_FOUNDRY_VLSI0x0056
-
-/* On ARM7 it holds the architecture and variant (sub-model) */
-#define CPU_ID_7ARCH_MASK  0x0080
-#define CPU_ID_7ARCH_V30x
-#define CPU_ID_7ARCH_V4T   0x0080
-#define CPU_ID_7VARIANT_MASK   0x007f
-
-/* On more recent ARMs, it does the same, but in a different format */
 #define CPU_ID_ARCH_MASK   0x000f
-#define CPU_ID_ARCH_V3 0x
-#define CPU_ID_ARCH_V4 0x0001
-#define CPU_ID_ARCH_V4T0x0002
-#define CPU_ID_ARCH_V5 0x0003
-#define CPU_ID_ARCH_V5T0x0004
 #define CPU_ID_ARCH_V5TE   0x0005
+#define CPU_ID_ARCH_V5TEJ  0x0006
 #define CPU_ID_ARCH_V6 0x0007
-#define CPU_ID_ARCH_V7 0x0008
+#define CPU_ID_ARCH_CPUID  0x000f
 #define CPU_ID_VARIANT_MASK0x00f0
 
 /* Next three nybbles are part number */
@@ -153,29 +131,6 @@
 
 /* Individual CPUs are probably best IDed by everything but the revision. */
 #define CPU_ID_CPU_MASK0xfff0
-
-/* Fake CPU IDs for ARMs without CP15 */
-#define CPU_ID_ARM20x41560200
-#define CPU_ID_ARM250  0x41560250
-
-/* Pre-ARM7 CPUs -- [15:12] == 0 */
-#define CPU_ID_ARM30x41560300
-#define CPU_ID_ARM600  0x41560600
-#define CPU_ID_ARM610  0x41560610
-#define CPU_ID_ARM620  0x41560620
-
-/* ARM7 CPUs -- [15:12] == 7 */
-#define CPU_ID_ARM700  0x41007000 /* XXX This is a guess. */
-#define CPU_ID_ARM710  0x41007100
-#define CPU_ID_ARM7500 0x41027100 /* XXX This is a guess. */
-#define CPU_ID_ARM710A 0x41047100 /* inc ARM7100 */
-#define CPU_ID_ARM7500FE   0x41077100
-#define CPU_ID_ARM710T 0x41807100
-#define CPU_ID_ARM720T 0x41807200
-#define CPU_ID_ARM740T8K   0x41807400 /* XXX no MMU, 8KB cache */
-#define CPU_ID_ARM740T4K   0x41817400 /* XXX no MMU, 4KB cache */
-
-/* Post-ARM7 CPUs */
 #define CPU_ID_ARM926EJS   0x41069260
 #define CPU_ID_ARM946ES0x41049460 /* XXX no MMU */
 #define CPU_ID_ARM966ES0x41049660 /* XXX no MMU */
@@ -233,18 +188,6 @@
 #define CPU_ID_CORTEX_A72  0x410fd080
 #define CPU_ID_CORTEX_A72_R1   0x411fd080
 #define CPU_ID_CORTEX_A72_MASK 0xff00
-
-/* ARM3-specific coprocessor 15 registers */
-#define ARM3_CP15_FLUSH1
-#define ARM3_CP15_CONTROL  2
-#define ARM3_CP15_CACHEABLE3
-#define ARM3_CP15_UPDATEABLE   4
-#define ARM3_CP15_DISRUPTIVE   5   
-
-/* ARM3 Control register bits */
-#define ARM3_CTL_CACHE_ON  0x0001
-#define ARM3_CTL_SHARED0x0002
-#define ARM3_CTL_MONITOR   0x0004
 
 /*
  * Post-ARM3 CP15 registers:

remove LOCALECHARSETS from libc

[Stefan Sperling]

Unused.

Index: locale/Makefile.inc
===
RCS file: /cvs/src/lib/libc/locale/Makefile.inc,v
retrieving revision 1.20
diff -u -p -r1.20 Makefile.inc
--- locale/Makefile.inc 3 Jul 2015 11:15:19 -   1.20
+++ locale/Makefile.inc 20 Mar 2016 13:14:36 -
@@ -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}\""

remove LOCALECHARSETS from locale(1) Makefile

[Stefan Sperling]

LOCALE_CHARSETS is unused in locale.c.

Index: Makefile
===
RCS file: /cvs/src/usr.bin/locale/Makefile,v
retrieving revision 1.1
diff -u -p -r1.1 Makefile
--- Makefile3 Jun 2013 14:27:50 -   1.1
+++ Makefile20 Mar 2016 13:01:37 -
@@ -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 

Re: axen improvements

[Remi Locherer]

On Sat, Mar 19, 2016 at 05:09:34PM -0400, Brandon Mercer wrote:
> 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. 
> 

This is an improvement for my usb3-to-gigEthernet device from Edimax. Without
this diff I have to configure the interface immediately ater plugged in. Now
I can wait for 5 min and it still works.

Tested device:

axen0 at uhub0 port 12 configuration 1 interface 0 "ASIX Elec. Corp. AX88179" 
rev 3.00/1.00 addr 3
axen0: AX88179, address 74:da:38:49:ed:82
rgephy0 at axen0 phy 3: RTL8169S/8110S/8211 PHY, rev. 5
axen0 detached

Remi

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

[Landry Breuil]

On Sun, Mar 20, 2016 at 11:55:23AM +0100, Stefan Sperling wrote:
> On Sun, Mar 20, 2016 at 10:43:43AM +, Stuart Henderson wrote:
> > While I do see use for this, can people also apply pressure to said
> > ISP to fix their setup as well please? This is basic routing and really
> > shouldn't need bridge hacks. People will need better than a single
> > /64 in order to segregate their IOT crap onto a network that doesn't
> > have access to their computers and the longer they get away with a
> > substandard setup the harder it will be for them to fix it later.
> > There's no address shortage with IPv6, this is just a business
> > decision the ISP have made.
> 
> Indeed.
> And bridging the internal LAN with the internet is really not a good idea.

Well, what's pf for then ? :)
At some point, if ppl want widespread v6, every host will be directly
reachable, so will have to be filtered at some point
I dont see the issue with bridging here, but i'm all open to
explanations.

Landry

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

[Stefan Sperling]

On Sun, Mar 20, 2016 at 10:43:43AM +, Stuart Henderson wrote:
> While I do see use for this, can people also apply pressure to said
> ISP to fix their setup as well please? This is basic routing and really
> shouldn't need bridge hacks. People will need better than a single
> /64 in order to segregate their IOT crap onto a network that doesn't
> have access to their computers and the longer they get away with a
> substandard setup the harder it will be for them to fix it later.
> There's no address shortage with IPv6, this is just a business
> decision the ISP have made.

Indeed.
And bridging the internal LAN with the internet is really not a good idea.

Re: axen improvements

[Stefan Sperling]

On Sat, Mar 19, 2016 at 05:09:34PM -0400, Brandon Mercer wrote:
> 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. 

Tested with 

axen0 at uhub2 port 2 configuration 1 interface 0 "ASIX Elec. Corp. AX88179" 
rev 2.10/1.00 addr 4
axen0: AX88179, address 80:1f:02:37:dc:89
rgephy0 at axen0 phy 3: RTL8169S/8110S/8211 PHY, rev. 5

Works fine. ifconfig axen0 lladdr random seems to be broken but I don't
think that's a new issue since the driver only copies the address from
hardware and never writes it back to hardware in case upper layers change it.

ok stsp@

> Index: dev/usb/if_axen.c
> @@ -399,69 +395,13 @@ axen_reset(struct axen_softc *sc)
>   if (usbd_is_dying(sc->axen_udev))
>   return;
>   /* XXX What to reset? */

Don't you want to remove the above comment as well?

> + axen_ax88179_init(sc);
>   /* Wait a little while for the chip to get its brains in order. */
>   DELAY(1000);
>   return;
>  }

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

[Landry Breuil]

On Wed, Mar 16, 2016 at 08:54:22PM +0100, Momtchil Momtchev wrote:
> 
> 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.

Fwiw, i've tested it here on my macppc gateway with the said ISP, and it
works fine.

$cat /etc/hostname.bridge0
add axe0
add gem0
blockipv4 gem0
rtsol
up

$ifconfig bridge0
bridge0: flags=200041
groups: bridge
priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp
designated: id 00:00:00:00:00:00 priority 0
axe0 flags=3
port 5 ifpriority 0 ifcost 0
gem0 flags=103
port 2 ifpriority 0 ifcost 0
Addresses (max cache: 100, timeout: 240):
00:24:d4:b9:3c:63 axe0 1 flags=0<>
00:1e:4f:94:e1:78 gem0 1 flags=0<>

(gem0 is my LAN iface, axe0 is the ISP-side with my public v4)

On a v4-natted host on the LAN side, ifconfig em0 inet6 autoconf gets me
a pair of v6 address in the /64 netblock assigned by the ISP, and i can
ping6 outside of my gw. Of course, i can still ping outside via natted
v4 :) http://ipv6.whatismyv6.com/ gives me the correct v6 ip too.

Here's the unmangled diff without the set/unset* refactoring, manually
applied and hopefully fixed wrt style(9).

Thanks for your work on this !

Landry
Index: sbin/ifconfig/brconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/brconfig.c,v
retrieving revision 1.9
diff -u -r1.9 brconfig.c
--- sbin/ifconfig/brconfig.c18 Jul 2015 06:50:24 -  1.9
+++ sbin/ifconfig/brconfig.c20 Mar 2016 09:05:48 -
@@ -59,7 +59,7 @@
 
 #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;\
@@ -115,6 +115,30 @@
 unsetblocknonip(const char *val, int d)
 {
bridge_ifclrflag(val, IFBIF_BLOCKNONIP);
+}
+
+void
+setblockipv4(const char *val, int d)
+{
+   bridge_ifsetflag(val, IFBIF_BLOCKIPV4);
+}
+
+void
+unsetblockipv4(const char *val, int d)
+{
+   bridge_ifclrflag(val, IFBIF_BLOCKIPV4);
+}
+
+void
+setblockipv6(const char *val, int d)
+{
+   bridge_ifsetflag(val, IFBIF_BLOCKIPV6);
+}
+
+void
+unsetblockipv6(const char *val, int d)
+{
+   bridge_ifclrflag(val, IFBIF_BLOCKIPV6);
 }
 
 void
Index: sbin/ifconfig/brconfig.h
===
RCS file: /cvs/src/sbin/ifconfig/brconfig.h,v
retrieving revision 1.9
diff -u -r1.9 brconfig.h
--- sbin/ifconfig/brconfig.h7 Jan 2016 15:33:56 -   1.9
+++ sbin/ifconfig/brconfig.h20 Mar 2016 09:05:48 -
@@ -25,6 +25,10 @@
 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 -r1.266 ifconfig.8
--- sbin/ifconfig/ifconfig.828 Feb 2016 21:55:36 -  1.266
+++ sbin/ifconfig/ifconfig.820 Mar 2016 09:05:49 -
@@ -564,6 +564,24 @@
 .It Cm -blocknonip Ar interface
 Allow non-IPv4, IPv6, ARP, or Reverse ARP packets through
 .Ar interface .
+.It Cm blockipv4 Ar interface
+Mark
+.Ar interface
+so that no IPv4 or ARP
+packets are accepted from it or forwarded to it from other
+bridge member interfaces. Allows the creation of IPv6-only bridges
+.It Cm -blockipv4 Ar interface
+Allow 

Re: Scheduler hack for multi-threaded processes

[Jonathan Matthew]

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.


The benefits for web browsers seem to have been well covered, so I thought
I'd try mariadb out a bit.  On the second-crappiest amd64 box I still run
(a sun v20z) I get significantly better results with the mysql tests in
sysbench using the configuration specified here:
https://mariadb.com/kb/en/mariadb/sysbench-benchmark-setup/

On the select_random_points test, for example, with 3 threads (on a 2 cpu box)
running for 5 minutes, across 4 different runs:
before:
read/write requests: 554817 (1849.39 per sec.)
read/write requests: 582590 (1941.96 per sec.)
read/write requests: 573752 (1912.50 per sec.)
read/write requests: 571679 (1905.59 per sec.)

after:
read/write requests: 661234 (2204.11 per sec.)
read/write requests: 647648 (2158.82 per sec.)
read/write requests: 649752 (2165.83 per sec.)
read/write requests: 642049 (2140.16 per sec.)

Not a real database performance test, but it at least shows that it helps
things other than browsers.