Re: relayd stops processing traffic intermittently

[Sebastian Benoit]

ok

Claudio Jeker(cje...@diehard.n-r-g.com) on 2017.12.28 14:21:27 +0100:
> Forwarding to tech, since people may have missed this.
> Hope to commit this soon.
> 
> - Forwarded message from Claudio Jeker  -
> 
> Date: Sun, 24 Dec 2017 19:07:11 +0100
> From: Claudio Jeker
> To: Mischa Peters
> Subject: Re: relayd stops processing traffic intermittently
> 
> On Sat, Dec 23, 2017 at 02:04:19PM +0100, Mischa Peters wrote:
> > 
> > > On 23 Dec 2017, at 13:08, Claudio Jeker wrote:
> > > 
> > >> On Sat, Dec 23, 2017 at 11:40:57AM +0100, Mischa wrote:
> > >> Hi All,
> > >> 
> > >> Since OpenBSD 6.2, just confirmed this in the latest snapshot 
> > >> (GENERIC.MP#305) as well, for some reason relayd stops processing 
> > >> traffic and starts flooding the log file with the following message:
> > >> 
> > >> Dec 23 11:19:11 lb2 relayd[22515]: rsae_send_imsg: poll timeout
> > >> Dec 23 11:19:12 lb2 relayd[52110]: rsae_send_imsg: poll timeout
> > >> Dec 23 11:19:12 lb2 relayd[69641]: rsae_send_imsg: poll timeout
> > >> Dec 23 11:19:12 lb2 relayd[22515]: rsae_send_imsg: poll timeout
> > >> [snip]
> > >> Dec 23 11:19:17 lb2 relayd[69641]: rsae_send_imsg: poll timeout
> > >> Dec 23 11:19:18 lb2 relayd[22515]: rsae_send_imsg: poll timeout
> > >> Dec 23 11:19:18 lb2 relayd[52110]: rsae_send_imsg: poll timeout
> > >> Dec 23 11:19:18 lb2 relayd[69641]: rsae_send_imsg: poll timeout
> > >> ...etc...
> > >> 
> > >> Restarting the daemon "fixes" the problem.
> > >> Not sure how to trouble shoot this but I am able to reproduce this 
> > >> consistently by pointing SSLLabs towards relayd.
> > >> Would be great to get some pointers.
> > >> 
> > > 
> > > I have seen this as well on our production systems. This is a problem in
> > > the privsep part of the TLS code. I could not do more testing yet but my
> > > assumption is that a new option / feature is freaking this code out.
> > 
> > Anything I can do or collect to give you more information? 
> 
> So, I think I found the problem. The ca process did not handle errors from
> RSA_private_encrypt correctly. So once you got a bad signature in the
> system chocked and stopped. This diff seems to work for me (against
> SSLlabs).
> 
> Cheers
> -- 
> :wq Claudio
> 
> Index: ca.c
> ===
> RCS file: /cvs/src/usr.sbin/relayd/ca.c,v
> retrieving revision 1.31
> diff -u -p -r1.31 ca.c
> --- ca.c  28 Nov 2017 00:20:23 -  1.31
> +++ ca.c  24 Dec 2017 18:01:20 -
> @@ -266,9 +266,15 @@ ca_dispatch_relay(int fd, struct privsep
>   break;
>   }
>  
> + if (cko.cko_tlen == -1) {
> + char buf[256];
> + log_warnx("%s: %s", __func__,
> + ERR_error_string(ERR_get_error(), buf));
> + }
> +
>   iov[c].iov_base = 
>   iov[c++].iov_len = sizeof(cko);
> - if (cko.cko_tlen) {
> + if (cko.cko_tlen > 0) {
>   iov[c].iov_base = to;
>   iov[c++].iov_len = cko.cko_tlen;
>   }
> @@ -381,12 +387,12 @@ rsae_send_imsg(int flen, const u_char *f
>  
>   IMSG_SIZE_CHECK(, ());
>   memcpy(, imsg.data, sizeof(cko));
> - if (IMSG_DATA_SIZE() !=
> - (sizeof(cko) + cko.cko_tlen))
> - fatalx("data size");
>  
>   ret = cko.cko_tlen;
> - if (ret) {
> + if (ret > 0) {
> + if (IMSG_DATA_SIZE() !=
> + (sizeof(cko) + ret))
> + fatalx("data size");
>   toptr = (u_char *)imsg.data + sizeof(cko);
>   memcpy(to, toptr, ret);
>   }
> 
> 
> - End forwarded message -
> 
> -- 
> :wq Claudio
> 

arm/sxitwi: dup includes

[Artturi Alm]

Hi,

sxitwi got thru lazy review.

-Artturi


diff --git a/sys/dev/fdt/sxitwi.c b/sys/dev/fdt/sxitwi.c
index 099f394823f..9e19812e6bd 100644
--- a/sys/dev/fdt/sxitwi.c
+++ b/sys/dev/fdt/sxitwi.c
@@ -71,10 +71,6 @@
 #include 
 #include 
 
-#include 
-#include 
-#include 
-
 #define_I2C_PRIVATE
 #include 
 

relayd timeout handling

[Rivo Nurges]

Hi!

I'm resending my previous proposal.

Bump client<>relay, relay<>server bufferevent timeouts as long there is
some traffic flowing. Current code doesn't handle long unidirectional
flows correctly.

Simplest route would be to check presence of traffic every second, but
I choose to schedule the task at half of the remainig timeout.


Rivo

Index: usr.sbin/relayd/relay.c
===
RCS file: /cvs/src/usr.sbin/relayd/relay.c,v
retrieving revision 1.236
diff -u -p -r1.236 relay.c
--- usr.sbin/relayd/relay.c 28 Nov 2017 01:51:47 -  1.236
+++ usr.sbin/relayd/relay.c 28 Dec 2017 16:28:03 -
@@ -69,6 +69,7 @@ intrelay_socket_connect(struct sockad
 
 voidrelay_accept(int, short, void *);
 voidrelay_input(struct rsession *);
+voidrelay_timeout(int, short, void *);
 
 voidrelay_hash_addr(SIPHASH_CTX *, struct sockaddr_storage *, int);
 
@@ -662,6 +663,7 @@ relay_connected(int fd, short sig, void 
struct bufferevent  *bev;
struct ctl_relay_event  *out = >se_out;
socklen_tlen;
+   struct timeval   tv;
int  error;
 
if (sig == EV_TIMEOUT) {
@@ -724,6 +726,14 @@ relay_connected(int fd, short sig, void 
 
bufferevent_settimeout(bev,
rlay->rl_conf.timeout.tv_sec, rlay->rl_conf.timeout.tv_sec);
+
+   evtimer_set(>se_ev, relay_timeout, con);
+   timerclear();
+   tv.tv_sec = rlay->rl_conf.timeout.tv_sec / 2;
+   if (tv.tv_sec == 0)
+   tv.tv_usec = 50;
+   evtimer_add(>se_ev, );
+
bufferevent_setwatermark(bev, EV_WRITE,
RELAY_MIN_PREFETCHED * proto->tcpbufsiz, 0);
bufferevent_enable(bev, EV_READ|EV_WRITE);
@@ -955,6 +965,37 @@ relay_spliceadjust(struct ctl_relay_even
cre->splicelen = -1;
 
return (0);
+}
+
+void
+relay_timeout(int fd, short event, void *arg)
+{
+   struct rsession *con = arg;
+   struct relay*rlay = con->se_relay;
+   struct timeval   tv, tv_now;
+   time_t   timeout;
+
+   timerclear();
+   getmonotime(_now);
+   timersub(_now, >se_tv_last, );
+   timeout = rlay->rl_conf.timeout.tv_sec - tv.tv_sec;
+
+   DPRINTF("%s: session %d: last %llds ago, timeout %llds", __func__,
+   con->se_id, tv.tv_sec, timeout);
+
+   if (timeout > 0){
+   bufferevent_settimeout(con->se_out.bev, timeout, timeout);
+   bufferevent_settimeout(con->se_in.bev, timeout, timeout);
+   }
+
+   evtimer_set(>se_ev, relay_timeout, con);
+   tv.tv_sec = (rlay->rl_conf.timeout.tv_sec - tv.tv_sec) / 2;
+   if (tv.tv_sec == 0)
+   tv.tv_usec = 50;
+   evtimer_add(>se_ev, );
+
+   DPRINTF("%s: session %d: next after %llds", __func__, con->se_id,
+   tv.tv_sec);
 }
 
 void

Re: cpu.4: VIA amd64 compatible CPUs support Enhanced SpeedStep

[Jason McIntyre]

On Thu, Dec 28, 2017 at 11:39:09AM +0100, Frederic Cambus wrote:
> Hi tech@,
> 
> VIA amd64 compatible CPUs support Enhanced SpeedStep, so reflect that
> in cpu.4.
> 
> On my VIA Nano U3500:
> 
> cpu0: VIA Nano U3500@1000MHz, 997.66 MHz
> cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,
> CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE,SSE3,MWAIT,VMX,EST,TM2,SSSE3,
> CX16,xTPR,SSE4.1,POPCNT,NXE,LONG,LAHF,PERF
> cpu0: Enhanced SpeedStep 997 MHz: speeds: 1000, 800 MHz
> 
> On my VIA Eden X2 U4200:
> 
> cpu0: VIA Eden X2 U4200 @ 1.0+ GHz, 1000.23 MHz
> cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,
> CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,MWAIT,VMX,EST,TM2,
> SSSE3,CX16,xTPR,SSE4.1,POPCNT,NXE,LONG,LAHF,PERF
> cpu0: Enhanced SpeedStep 1000 MHz: speeds: 1000, 900, 800 MHz
> 
> Comments? OK?
> 

ok.
jmc

> Index: share/man/man4/man4.amd64/cpu.4
> ===
> RCS file: /cvs/src/share/man/man4/man4.amd64/cpu.4,v
> retrieving revision 1.4
> diff -u -p -r1.4 cpu.4
> --- share/man/man4/man4.amd64/cpu.4   13 Jul 2009 15:43:05 -  1.4
> +++ share/man/man4/man4.amd64/cpu.4   27 Dec 2017 17:22:10 -
> @@ -46,7 +46,7 @@ There are several possible implementatio
>  to the user.
>  .Bl -tag -width tenletters
>  .It EST
> -Enhanced SpeedStep found on Intel processors,
> +Enhanced SpeedStep found on Intel and VIA processors,
>  offers frequency scaling with numerous positions.
>  .It PowerNow
>  Found on various AMD processors.
> 

cwm 'wm' menu

[Okan Demirmen]

Hi cwm users,

I am not sure how many cwm users actually use the 'wm' (exec window
manager) menu, but I'd like to somewhat change it.

Right now it works just like the 'exec' menu where it populates any
executable in the path, then replaces the existing window manager with
that. For cwm development (or any wm development this feature is for),
this is essentially useless because one does't actually install the
various test binaries into the path (even if one did, the menu doesn't
display the path of each, just the first match, etc, etc). One has to
always hand type the full path of whatever replacement window manager
into the 'wm' menu - it's painful and slow. I don't know many other
people actively working on cwm so I'm not sure of the opinions and
impact here.

What I'd prefer is somewhat what other window managers have - a list,
via config, for a selection of available window managers.  A default
list as just 'wm cwm cwm' (wm  ). Most folks might
have just used this 'wm' feature to restart cwm as opposed to the
'restart' command from the old days (which is why this menu originated
long time ago I believe) - leaving support for that and not changing the
function name is fine.

I doubt people are installing window managers and switching back and
forth in such a manner that annotating them via config is a burden.

Below is a rough draft of the above - it needs manpage changes, clean-up
of the old way, etc, but it's the minimal diff for the general idea.

Bonus side-effect: This also limits the shell-like goop to just the
'exec' menu.

Thanks,
Okan

Index: calmwm.h
===
RCS file: /home/open/cvs/xenocara/app/cwm/calmwm.h,v
retrieving revision 1.347
diff -u -p -r1.347 calmwm.h
--- calmwm.h19 Dec 2017 14:30:53 -  1.347
+++ calmwm.h27 Dec 2017 19:21:24 -
@@ -255,6 +255,7 @@ struct cmd_ctx {
char path[PATH_MAX];
 };
 TAILQ_HEAD(cmd_q, cmd_ctx);
+TAILQ_HEAD(wm_q, cmd_ctx);
 
 enum menu_exec {
CWM_MENU_EXEC_EXEC,
@@ -284,6 +285,7 @@ struct conf {
struct autogroup_q   autogroupq;
struct ignore_q  ignoreq;
struct cmd_q cmdq;
+   struct wm_q  wmq;
int  ngroups;
int  stickygroups;
int  nameqlen;
@@ -457,10 +459,13 @@ void   search_match_cmd(struct menu_q 
*
 char *);
 voidsearch_match_group(struct menu_q *, struct menu_q *,
 char *);
+voidsearch_match_wm(struct menu_q *, struct menu_q *,
+char *);
 voidsearch_print_client(struct menu *, int);
 voidsearch_print_cmd(struct menu *, int);
 voidsearch_print_group(struct menu *, int);
 voidsearch_print_text(struct menu *, int);
+voidsearch_print_wm(struct menu *, int);
 
 struct region_ctx  *region_find(struct screen_ctx *, int, int);
 struct geom screen_apply_gap(struct screen_ctx *, struct geom);
@@ -500,6 +505,7 @@ void kbfunc_group_alltoggle(void *, 
s
 voidkbfunc_menu_client(void *, struct cargs *);
 voidkbfunc_menu_cmd(void *, struct cargs *);
 voidkbfunc_menu_group(void *, struct cargs *);
+voidkbfunc_menu_wm(void *, struct cargs *);
 voidkbfunc_menu_exec(void *, struct cargs *);
 voidkbfunc_menu_ssh(void *, struct cargs *);
 voidkbfunc_client_menu_label(void *, struct cargs *);
@@ -528,6 +534,8 @@ int  conf_bind_mouse(struct conf *, co
 voidconf_clear(struct conf *);
 voidconf_client(struct client_ctx *);
 int conf_cmd_add(struct conf *, const char *,
+const char *);
+int conf_wm_add(struct conf *, const char *,
 const char *);
 voidconf_cursor(struct conf *);
 voidconf_grab_kbd(Window);
Index: conf.c
===
RCS file: /home/open/cvs/xenocara/app/cwm/conf.c,v
retrieving revision 1.236
diff -u -p -r1.236 conf.c
--- conf.c  19 Dec 2017 14:30:53 -  1.236
+++ conf.c  27 Dec 2017 19:25:07 -
@@ -195,8 +195,7 @@ static const struct {
CWM_MENU_WINDOW_HIDDEN },
{ "menu-exec", kbfunc_menu_exec, CWM_CONTEXT_SC,
CWM_MENU_EXEC_EXEC },
-   { "menu-exec-wm", kbfunc_menu_exec, CWM_CONTEXT_SC,
-   CWM_MENU_EXEC_WM },
+   { "menu-exec-wm", kbfunc_menu_wm, CWM_CONTEXT_SC, 0 },
 
{ "terminal", kbfunc_exec_term, CWM_CONTEXT_SC, 0 },
{ "lock", kbfunc_exec_lock, CWM_CONTEXT_SC, 0 

Re: Remove unnecessary includes (i386 VIA PadLock driver)

[Frederic Cambus]

On Fri, Dec 08, 2017 at 12:39:36PM +0100, Frederic Cambus wrote:

> This diff remove unnecessary includes in the i386 version of the
> VIA PadLock driver.
> 
> Comments? OK?

Ping. Anyone?

This is the last step in syncing amd64 and i386 versions of the
VIA PadLock driver.

Re: ksh: fix sign compare warnings

[Todd C. Miller]

On Wed, 27 Dec 2017 07:02:50 -0700, "Todd C. Miller" wrote:

> Add WARNINGS=yes to ksh and fix the resulting sign compare warnings.
> Still passes regress.  Note that gcc is pickier than clang in this
> respect as it requires a matching sign for ternary operations.
>
> I tried to limit the use of casts.

Slightly modified diff that uses a different variable name for the
unsigned ints used with NELEM().  Having some "i" as signed and
others as unsigned is confusing for the reader.

 - todd

Index: bin/ksh/Makefile
===
RCS file: /cvs/src/bin/ksh/Makefile,v
retrieving revision 1.35
diff -u -p -u -r1.35 Makefile
--- bin/ksh/Makefile27 Dec 2017 13:02:57 -  1.35
+++ bin/ksh/Makefile28 Dec 2017 13:58:06 -
@@ -6,7 +6,8 @@ SRCS=   alloc.c c_ksh.c c_sh.c c_test.c c_
misc.c path.c shf.c syn.c table.c trap.c tree.c tty.c var.c \
version.c vi.c
 
-DEFS=  -Wall -Wshadow -DEMACS -DVI
+WARNINGS=yes
+DEFS=  -DEMACS -DVI
 CFLAGS+=${DEFS} -I. -I${.CURDIR} -I${.CURDIR}/../../lib/libc/gen
 MAN=   ksh.1 sh.1
 
Index: bin/ksh/c_ksh.c
===
RCS file: /cvs/src/bin/ksh/c_ksh.c,v
retrieving revision 1.52
diff -u -p -u -r1.52 c_ksh.c
--- bin/ksh/c_ksh.c 27 Dec 2017 13:02:57 -  1.52
+++ bin/ksh/c_ksh.c 28 Dec 2017 13:58:06 -
@@ -1194,7 +1194,8 @@ c_kill(char **wp)
ki.num_width++;
 
for (i = 0; i < NSIG; i++) {
-   w = sigtraps[i].name ? strlen(sigtraps[i].name) 
:
+   w = sigtraps[i].name ?
+   (int)strlen(sigtraps[i].name) :
ki.num_width;
if (w > ki.name_width)
ki.name_width = w;
Index: bin/ksh/edit.c
===
RCS file: /cvs/src/bin/ksh/edit.c,v
retrieving revision 1.58
diff -u -p -u -r1.58 edit.c
--- bin/ksh/edit.c  27 Dec 2017 13:02:57 -  1.58
+++ bin/ksh/edit.c  28 Dec 2017 13:58:06 -
@@ -224,13 +224,13 @@ set_editmode(const char *ed)
 #endif
};
char *rcp;
-   int i;
+   unsigned int ele;
 
if ((rcp = strrchr(ed, '/')))
ed = ++rcp;
-   for (i = 0; i < NELEM(edit_flags); i++)
-   if (strstr(ed, sh_options[(int) edit_flags[i]].name)) {
-   change_flag(edit_flags[i], OF_SPECIAL, 1);
+   for (ele = 0; ele < NELEM(edit_flags); ele++)
+   if (strstr(ed, sh_options[(int) edit_flags[ele]].name)) {
+   change_flag(edit_flags[ele], OF_SPECIAL, 1);
return;
}
 }
Index: bin/ksh/emacs.c
===
RCS file: /cvs/src/bin/ksh/emacs.c,v
retrieving revision 1.77
diff -u -p -u -r1.77 emacs.c
--- bin/ksh/emacs.c 27 Dec 2017 13:02:57 -  1.77
+++ bin/ksh/emacs.c 28 Dec 2017 13:58:06 -
@@ -1249,7 +1249,7 @@ static char *
 kb_decode(const char *s)
 {
static char l[LINE + 1];
-   int i, at = 0;
+   unsigned inti, at = 0;
 
l[0] = '\0';
for (i = 0; i < strlen(s); i++) {
@@ -1292,7 +1292,7 @@ kb_del(struct kb_entry *k)
 static struct kb_entry *
 kb_add_string(void *func, void *args, char *str)
 {
-   int i, count;
+   unsigned inti, count;
struct kb_entry *k;
struct x_ftab   *xf = NULL;
 
@@ -1362,7 +1362,7 @@ x_bind(const char *a1, const char *a2,
int macro,  /* bind -m */
int list)   /* bind -l */
 {
-   int i;
+   unsigned inti;
struct kb_entry *k, *kb;
charin[LINE + 1];
 
Index: bin/ksh/eval.c
===
RCS file: /cvs/src/bin/ksh/eval.c,v
retrieving revision 1.54
diff -u -p -u -r1.54 eval.c
--- bin/ksh/eval.c  27 Aug 2017 00:29:04 -  1.54
+++ bin/ksh/eval.c  28 Dec 2017 13:58:06 -
@@ -1114,10 +1114,11 @@ debunk(char *dp, const char *sp, size_t 
char *d, *s;
 
if ((s = strchr(sp, MAGIC))) {
-   if (s - sp >= dlen)
+   size_t slen = s - sp;
+   if (slen >= dlen)
return dp;
-   memcpy(dp, sp, s - sp);
-   for (d = dp + (s - sp); *s && (d - dp < dlen); s++)
+   memcpy(dp, sp, slen);
+   for (d = dp + slen; *s && (d < dp + dlen); s++)
if (!ISMAGIC(*s) || !(*++s & 0x80) ||
!strchr("*+?@! ", *s & 0x7f))
*d++ = *s;
@@ -1125,7 +1126,7 @@ debunk(char *dp, const char *sp, size_t 
 

Re: relayd stops processing traffic intermittently

[Claudio Jeker]

Forwarding to tech, since people may have missed this.
Hope to commit this soon.

- Forwarded message from Claudio Jeker  -

Date: Sun, 24 Dec 2017 19:07:11 +0100
From: Claudio Jeker
To: Mischa Peters
Subject: Re: relayd stops processing traffic intermittently

On Sat, Dec 23, 2017 at 02:04:19PM +0100, Mischa Peters wrote:
> 
> > On 23 Dec 2017, at 13:08, Claudio Jeker wrote:
> > 
> >> On Sat, Dec 23, 2017 at 11:40:57AM +0100, Mischa wrote:
> >> Hi All,
> >> 
> >> Since OpenBSD 6.2, just confirmed this in the latest snapshot 
> >> (GENERIC.MP#305) as well, for some reason relayd stops processing traffic 
> >> and starts flooding the log file with the following message:
> >> 
> >> Dec 23 11:19:11 lb2 relayd[22515]: rsae_send_imsg: poll timeout
> >> Dec 23 11:19:12 lb2 relayd[52110]: rsae_send_imsg: poll timeout
> >> Dec 23 11:19:12 lb2 relayd[69641]: rsae_send_imsg: poll timeout
> >> Dec 23 11:19:12 lb2 relayd[22515]: rsae_send_imsg: poll timeout
> >> [snip]
> >> Dec 23 11:19:17 lb2 relayd[69641]: rsae_send_imsg: poll timeout
> >> Dec 23 11:19:18 lb2 relayd[22515]: rsae_send_imsg: poll timeout
> >> Dec 23 11:19:18 lb2 relayd[52110]: rsae_send_imsg: poll timeout
> >> Dec 23 11:19:18 lb2 relayd[69641]: rsae_send_imsg: poll timeout
> >> ...etc...
> >> 
> >> Restarting the daemon "fixes" the problem.
> >> Not sure how to trouble shoot this but I am able to reproduce this 
> >> consistently by pointing SSLLabs towards relayd.
> >> Would be great to get some pointers.
> >> 
> > 
> > I have seen this as well on our production systems. This is a problem in
> > the privsep part of the TLS code. I could not do more testing yet but my
> > assumption is that a new option / feature is freaking this code out.
> 
> Anything I can do or collect to give you more information? 

So, I think I found the problem. The ca process did not handle errors from
RSA_private_encrypt correctly. So once you got a bad signature in the
system chocked and stopped. This diff seems to work for me (against
SSLlabs).

Cheers
-- 
:wq Claudio

Index: ca.c
===
RCS file: /cvs/src/usr.sbin/relayd/ca.c,v
retrieving revision 1.31
diff -u -p -r1.31 ca.c
--- ca.c28 Nov 2017 00:20:23 -  1.31
+++ ca.c24 Dec 2017 18:01:20 -
@@ -266,9 +266,15 @@ ca_dispatch_relay(int fd, struct privsep
break;
}
 
+   if (cko.cko_tlen == -1) {
+   char buf[256];
+   log_warnx("%s: %s", __func__,
+   ERR_error_string(ERR_get_error(), buf));
+   }
+
iov[c].iov_base = 
iov[c++].iov_len = sizeof(cko);
-   if (cko.cko_tlen) {
+   if (cko.cko_tlen > 0) {
iov[c].iov_base = to;
iov[c++].iov_len = cko.cko_tlen;
}
@@ -381,12 +387,12 @@ rsae_send_imsg(int flen, const u_char *f
 
IMSG_SIZE_CHECK(, ());
memcpy(, imsg.data, sizeof(cko));
-   if (IMSG_DATA_SIZE() !=
-   (sizeof(cko) + cko.cko_tlen))
-   fatalx("data size");
 
ret = cko.cko_tlen;
-   if (ret) {
+   if (ret > 0) {
+   if (IMSG_DATA_SIZE() !=
+   (sizeof(cko) + ret))
+   fatalx("data size");
toptr = (u_char *)imsg.data + sizeof(cko);
memcpy(to, toptr, ret);
}


- End forwarded message -

-- 
:wq Claudio

cpu.4: VIA amd64 compatible CPUs support Enhanced SpeedStep

[Frederic Cambus]

Hi tech@,

VIA amd64 compatible CPUs support Enhanced SpeedStep, so reflect that
in cpu.4.

On my VIA Nano U3500:

cpu0: VIA Nano U3500@1000MHz, 997.66 MHz
cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,
CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE,SSE3,MWAIT,VMX,EST,TM2,SSSE3,
CX16,xTPR,SSE4.1,POPCNT,NXE,LONG,LAHF,PERF
cpu0: Enhanced SpeedStep 997 MHz: speeds: 1000, 800 MHz

On my VIA Eden X2 U4200:

cpu0: VIA Eden X2 U4200 @ 1.0+ GHz, 1000.23 MHz
cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,
CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,MWAIT,VMX,EST,TM2,
SSSE3,CX16,xTPR,SSE4.1,POPCNT,NXE,LONG,LAHF,PERF
cpu0: Enhanced SpeedStep 1000 MHz: speeds: 1000, 900, 800 MHz

Comments? OK?

Index: share/man/man4/man4.amd64/cpu.4
===
RCS file: /cvs/src/share/man/man4/man4.amd64/cpu.4,v
retrieving revision 1.4
diff -u -p -r1.4 cpu.4
--- share/man/man4/man4.amd64/cpu.4 13 Jul 2009 15:43:05 -  1.4
+++ share/man/man4/man4.amd64/cpu.4 27 Dec 2017 17:22:10 -
@@ -46,7 +46,7 @@ There are several possible implementatio
 to the user.
 .Bl -tag -width tenletters
 .It EST
-Enhanced SpeedStep found on Intel processors,
+Enhanced SpeedStep found on Intel and VIA processors,
 offers frequency scaling with numerous positions.
 .It PowerNow
 Found on various AMD processors.