Re: relayd stops processing traffic intermittently
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
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
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
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
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)
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
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
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
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.