Re: obsd 6.7 - ntpd error msg
On Wed, Jun 17, 2020 at 10:53:54PM +0200, Salvatore Cuzzilla wrote: > Hi Otto here the logs (multitail) - @22:49:15 I restarted ntpd: > - > Jun 17 22:49:23 obsd ntpd[88568]: constraint reply from 188.61.106.24: offset > -0.541051 > Jun 17 22:49:46 obsd ntpd[88568]: peer 172.17.1.1 now valid > 01] /var/log/daemon <--- > > >248KB - 2020/06/17 > 22:49:46 > - > Jun 17 14:00:01 obsd syslogd[80400]: restart > Jun 17 16:19:41 obsd ntpd[92699]: pipe write error (from main): No such file > or directory > Jun 17 16:21:07 obsd ntpd[29588]: pipe write error (from main): No such file > or directory > Jun 17 17:00:01 obsd syslogd[80400]: restart > Jun 17 17:01:25 obsd ntpd[96273]: pipe write error (from main): No such file > or directory > Jun 17 17:02:38 obsd ntpd[94737]: pipe write error (from main): No such file > or directory > Jun 17 20:00:01 obsd syslogd[80400]: restart > Jun 17 22:00:01 obsd syslogd[80400]: restart > Jun 17 22:49:22 obsd ntpd[40936]: pipe write error (from main): No such file > or directory > 02] /var/log/messages <--- > > >205KB - 2020/06/17 > 22:49:22 > - > 22:49:15 -ksh ToTo@obsd ~ $ doas rcctl restart ntpd > ntpd(ok) > ntpd(ok) > 22:49:23 -ksh ToTo@obsd ~ $ OK, now we're getting somewhere. It always helps to provide lots of information form the start. The message is generated by ntpd being stopped. It is harmless, though it is actually wrong, it's a pip read error. So nothing to worry about. I'll see if the log level should be changed to debug for this one or maybe another solution. -Otto > > On 17.06.2020 21:18, Otto Moerbeek wrote: > > On Wed, Jun 17, 2020 at 09:15:22PM +0200, Salvatore Cuzzilla wrote: > > > > > Hi Otto, > > > > > > thanks for helping, really appreciated! > > > The msg is showing after each restart. My simple conf here below: > > > - > > > 21:05:52 -ksh ToTo@obsd ~ $ doas cat /etc/ntpd.conf > > > # $OpenBSD: ntpd.conf,v 1.14 2015/07/15 20:28:37 ajacoutot Exp $ > > > # > > > # See ntpd.conf(5) and /etc/examples/ntpd.conf > > > > > > server 172.17.1.1 > > > sensor * > > > constraints from "https://www.alfanetti.org"; > > > - > > > > And show the log lines, all of them > > > > -Otto > > > > > > > > On 17.06.2020 20:51, Otto Moerbeek wrote: > > > > On Wed, Jun 17, 2020 at 04:50:46PM +0200, Salvatore Cuzzilla wrote: > > > > > > > > > Hi Folks, > > > > > > > > > > when I restart ntpd I see this msg in /var/log/daemon: > > > > > > > > > > Jun 17 16:19:41 obsd ntpd[92699]: pipe write error (from main): No > > > > > suchfile or directory > > > > > > > > > > however, time seems to be in sync: > > > > > > > > > > --- > > > > > 16:37:17 -ksh ToTo@obsd ~ $ ntpctl -sa > > > > > 1/1 peers valid, 1/1 sensors valid, constraint offset -1s, clock > > > > > unsynced > > > > > > > > > > peer > > > > >wt tl st next poll offset delay jitter > > > > > 172.17.1.1 > > > > > 1 10 3 2361s 3069s-0.008ms 0.716ms 0.137ms > > > > > > > > > > sensor > > > > >wt gd st next poll offset correction > > > > > vmt0 > > > > > 1 1 07s 15s27.860ms 0.000ms > > > > > > > > > > 16:38:20 -ksh ToTo@obsd ~ $ doas sysctl -a | grep timecounter > > > > > kern.timecounter.tick=1 > > > > > kern.timecounter.timestepwarnings=0 > > > > > kern.timecounter.hardware=tsc > > > > > kern.timecounter.choice=i8254(0) acpihpet0(1000) tsc(2000) > > > > > acpitimer0(1000) > > > > > --- > > > > > > > > > > anyone else experiencing the same? > > > > > > > > > > --- > > > > > :wq, > > > > > Salvatore. > > > > > > > > > > > > > Was the message in the log before or after restarting? > > > > Please show your ntpd.conf > > > > > > > > -Otto > > > > > > > > > > --- > > > :wq, > > > Salvatore. > > > > --- > :wq, > Salvatore.
Re: stoeplitz_hash_ip*: avoid early split into hi and lo
> On 18 Jun 2020, at 2:34 pm, Theo Buehler wrote:
>
> Now that the calls to stoeplitz_cache_entry() are out of the way,
> we can avoid half of the calculations by merging the computation of
> hi and lo, only spliting at the end. This allows us to leverage
> stoeplitz_hash_n16().
>
> The name lo is now wrong. I kept it in order to avoid noise. I'm
> going clean this up in the next step.
ok on this, and on the next step where lo is renamed.
please keep __unused though.
>
> Index: toeplitz.c
> ===
> RCS file: /cvs/src/sys/net/toeplitz.c,v
> retrieving revision 1.3
> diff -u -p -U5 -r1.3 toeplitz.c
> --- toeplitz.c18 Jun 2020 03:53:38 - 1.3
> +++ toeplitz.c18 Jun 2020 03:57:43 -
> @@ -114,108 +114,79 @@ stoeplitz_cache_init(struct stoeplitz_ca
>
> uint16_t
> stoeplitz_hash_ip4(const struct stoeplitz_cache *scache,
> in_addr_t faddr, in_addr_t laddr)
> {
> - uint16_t lo, hi;
> + uint16_t lo;
>
> lo = faddr >> 0;
> lo ^= faddr >> 16;
> lo ^= laddr >> 0;
> lo ^= laddr >> 16;
>
> - hi = faddr >> 8;
> - hi ^= faddr >> 24;
> - hi ^= laddr >> 8;
> - hi ^= laddr >> 24;
> -
> - return (swap16(stoeplitz_cache_entry(scache, lo))
> - ^ stoeplitz_cache_entry(scache, hi));
> + return (stoeplitz_hash_n16(scache, lo));
> }
>
> uint16_t
> stoeplitz_hash_ip4port(const struct stoeplitz_cache *scache,
> in_addr_t faddr, in_addr_t laddr, in_port_t fport, in_port_t lport)
> {
> - uint16_t hi, lo;
> + uint16_t lo;
>
> lo = faddr >> 0;
> lo ^= faddr >> 16;
> lo ^= laddr >> 0;
> lo ^= laddr >> 16;
> lo ^= fport >> 0;
> lo ^= lport >> 0;
>
> - hi = faddr >> 8;
> - hi ^= faddr >> 24;
> - hi ^= laddr >> 8;
> - hi ^= laddr >> 24;
> - hi ^= fport >> 8;
> - hi ^= lport >> 8;
> -
> - return (swap16(stoeplitz_cache_entry(scache, lo))
> - ^ stoeplitz_cache_entry(scache, hi));
> + return (stoeplitz_hash_n16(scache, lo));
> }
>
> #ifdef INET6
> uint16_t
> stoeplitz_hash_ip6(const struct stoeplitz_cache *scache,
> const struct in6_addr *faddr6, const struct in6_addr *laddr6)
> {
> - uint16_t hi = 0, lo = 0;
> + uint16_t lo = 0;
> size_t i;
>
> for (i = 0; i < nitems(faddr6->s6_addr32); i++) {
> uint32_t faddr = faddr6->s6_addr32[i];
> uint32_t laddr = laddr6->s6_addr32[i];
>
> lo ^= faddr >> 0;
> lo ^= faddr >> 16;
> lo ^= laddr >> 0;
> lo ^= laddr >> 16;
> -
> - hi ^= faddr >> 8;
> - hi ^= faddr >> 24;
> - hi ^= laddr >> 8;
> - hi ^= laddr >> 24;
> }
>
> - return (swap16(stoeplitz_cache_entry(scache, lo))
> - ^ stoeplitz_cache_entry(scache, hi));
> + return (stoeplitz_hash_n16(scache, lo));
> }
>
> uint16_t
> stoeplitz_hash_ip6port(const struct stoeplitz_cache *scache,
> const struct in6_addr *faddr6, const struct in6_addr * laddr6,
> in_port_t fport, in_port_t lport)
> {
> - uint16_t hi = 0, lo = 0;
> + uint16_t lo = 0;
> size_t i;
>
> for (i = 0; i < nitems(faddr6->s6_addr32); i++) {
> uint32_t faddr = faddr6->s6_addr32[i];
> uint32_t laddr = laddr6->s6_addr32[i];
>
> lo ^= faddr >> 0;
> lo ^= faddr >> 16;
> lo ^= laddr >> 0;
> lo ^= laddr >> 16;
> -
> - hi ^= faddr >> 8;
> - hi ^= faddr >> 24;
> - hi ^= laddr >> 8;
> - hi ^= laddr >> 24;
> }
>
> lo ^= fport >> 0;
> lo ^= lport >> 0;
>
> - hi ^= fport >> 8;
> - hi ^= lport >> 8;
> -
> - return (swap16(stoeplitz_cache_entry(scache, lo))
> - ^ stoeplitz_cache_entry(scache, hi));
> + return (stoeplitz_hash_n16(scache, lo));
> }
> #endif /* INET6 */
>
> void
> stoeplitz_to_key(uint8_t *k, size_t klen)
> Index: toeplitz.h
> ===
> RCS file: /cvs/src/sys/net/toeplitz.h,v
> retrieving revision 1.1
> diff -u -p -U5 -r1.1 toeplitz.h
> --- toeplitz.h16 Jun 2020 04:46:49 - 1.1
> +++ toeplitz.h18 Jun 2020 03:57:43 -
> @@ -52,11 +52,11 @@ uint16_t stoeplitz_hash_ip6port(const st
> const struct in6_addr *, const struct in6_addr *,
> uint16_t, uint16_t);
> #endif
>
> /* hash a uint16_t in network byte order */
> -static __unused inline uint16_t
> +static inline uint16_t
> stoeplitz_hash_n16(const struct stoeplitz_cache *scache, uint16_t n16)
> {
> uint16_t hi, lo;
>
> hi = stoeplitz_cache_entry(scache, n16 >> 8);
>
stoeplitz_hash_ip*: avoid early split into hi and lo
Now that the calls to stoeplitz_cache_entry() are out of the way,
we can avoid half of the calculations by merging the computation of
hi and lo, only spliting at the end. This allows us to leverage
stoeplitz_hash_n16().
The name lo is now wrong. I kept it in order to avoid noise. I'm
going clean this up in the next step.
Index: toeplitz.c
===
RCS file: /cvs/src/sys/net/toeplitz.c,v
retrieving revision 1.3
diff -u -p -U5 -r1.3 toeplitz.c
--- toeplitz.c 18 Jun 2020 03:53:38 - 1.3
+++ toeplitz.c 18 Jun 2020 03:57:43 -
@@ -114,108 +114,79 @@ stoeplitz_cache_init(struct stoeplitz_ca
uint16_t
stoeplitz_hash_ip4(const struct stoeplitz_cache *scache,
in_addr_t faddr, in_addr_t laddr)
{
- uint16_t lo, hi;
+ uint16_t lo;
lo = faddr >> 0;
lo ^= faddr >> 16;
lo ^= laddr >> 0;
lo ^= laddr >> 16;
- hi = faddr >> 8;
- hi ^= faddr >> 24;
- hi ^= laddr >> 8;
- hi ^= laddr >> 24;
-
- return (swap16(stoeplitz_cache_entry(scache, lo))
- ^ stoeplitz_cache_entry(scache, hi));
+ return (stoeplitz_hash_n16(scache, lo));
}
uint16_t
stoeplitz_hash_ip4port(const struct stoeplitz_cache *scache,
in_addr_t faddr, in_addr_t laddr, in_port_t fport, in_port_t lport)
{
- uint16_t hi, lo;
+ uint16_t lo;
lo = faddr >> 0;
lo ^= faddr >> 16;
lo ^= laddr >> 0;
lo ^= laddr >> 16;
lo ^= fport >> 0;
lo ^= lport >> 0;
- hi = faddr >> 8;
- hi ^= faddr >> 24;
- hi ^= laddr >> 8;
- hi ^= laddr >> 24;
- hi ^= fport >> 8;
- hi ^= lport >> 8;
-
- return (swap16(stoeplitz_cache_entry(scache, lo))
- ^ stoeplitz_cache_entry(scache, hi));
+ return (stoeplitz_hash_n16(scache, lo));
}
#ifdef INET6
uint16_t
stoeplitz_hash_ip6(const struct stoeplitz_cache *scache,
const struct in6_addr *faddr6, const struct in6_addr *laddr6)
{
- uint16_t hi = 0, lo = 0;
+ uint16_t lo = 0;
size_t i;
for (i = 0; i < nitems(faddr6->s6_addr32); i++) {
uint32_t faddr = faddr6->s6_addr32[i];
uint32_t laddr = laddr6->s6_addr32[i];
lo ^= faddr >> 0;
lo ^= faddr >> 16;
lo ^= laddr >> 0;
lo ^= laddr >> 16;
-
- hi ^= faddr >> 8;
- hi ^= faddr >> 24;
- hi ^= laddr >> 8;
- hi ^= laddr >> 24;
}
- return (swap16(stoeplitz_cache_entry(scache, lo))
- ^ stoeplitz_cache_entry(scache, hi));
+ return (stoeplitz_hash_n16(scache, lo));
}
uint16_t
stoeplitz_hash_ip6port(const struct stoeplitz_cache *scache,
const struct in6_addr *faddr6, const struct in6_addr * laddr6,
in_port_t fport, in_port_t lport)
{
- uint16_t hi = 0, lo = 0;
+ uint16_t lo = 0;
size_t i;
for (i = 0; i < nitems(faddr6->s6_addr32); i++) {
uint32_t faddr = faddr6->s6_addr32[i];
uint32_t laddr = laddr6->s6_addr32[i];
lo ^= faddr >> 0;
lo ^= faddr >> 16;
lo ^= laddr >> 0;
lo ^= laddr >> 16;
-
- hi ^= faddr >> 8;
- hi ^= faddr >> 24;
- hi ^= laddr >> 8;
- hi ^= laddr >> 24;
}
lo ^= fport >> 0;
lo ^= lport >> 0;
- hi ^= fport >> 8;
- hi ^= lport >> 8;
-
- return (swap16(stoeplitz_cache_entry(scache, lo))
- ^ stoeplitz_cache_entry(scache, hi));
+ return (stoeplitz_hash_n16(scache, lo));
}
#endif /* INET6 */
void
stoeplitz_to_key(uint8_t *k, size_t klen)
Index: toeplitz.h
===
RCS file: /cvs/src/sys/net/toeplitz.h,v
retrieving revision 1.1
diff -u -p -U5 -r1.1 toeplitz.h
--- toeplitz.h 16 Jun 2020 04:46:49 - 1.1
+++ toeplitz.h 18 Jun 2020 03:57:43 -
@@ -52,11 +52,11 @@ uint16_tstoeplitz_hash_ip6port(const st
const struct in6_addr *, const struct in6_addr *,
uint16_t, uint16_t);
#endif
/* hash a uint16_t in network byte order */
-static __unused inline uint16_t
+static inline uint16_t
stoeplitz_hash_n16(const struct stoeplitz_cache *scache, uint16_t n16)
{
uint16_t hi, lo;
hi = stoeplitz_cache_entry(scache, n16 >> 8);
BCM5719 A1 seen in the wild
Mostly cosmetic, but it removes an "unknown" from dmesg which may
spook some of our users.
ok?
Index: dev/pci/if_bge.c
===
RCS file: /cvs/src/sys/dev/pci/if_bge.c,v
retrieving revision 1.388
diff -u -p -r1.388 if_bge.c
--- dev/pci/if_bge.c9 Nov 2018 14:14:31 - 1.388
+++ dev/pci/if_bge.c17 Jun 2020 23:08:45 -
@@ -384,6 +384,7 @@ static const struct bge_revision {
{ BGE_CHIPID_BCM5717_A0, "BCM5717 A0" },
{ BGE_CHIPID_BCM5717_B0, "BCM5717 B0" },
{ BGE_CHIPID_BCM5719_A0, "BCM5719 A0" },
+ { BGE_CHIPID_BCM5719_A1, "BCM5719 A1" },
{ BGE_CHIPID_BCM5720_A0, "BCM5720 A0" },
{ BGE_CHIPID_BCM5755_A0, "BCM5755 A0" },
{ BGE_CHIPID_BCM5755_A1, "BCM5755 A1" },
Index: dev/pci/if_bgereg.h
===
RCS file: /cvs/src/sys/dev/pci/if_bgereg.h,v
retrieving revision 1.130
diff -u -p -r1.130 if_bgereg.h
--- dev/pci/if_bgereg.h 29 Nov 2015 20:19:35 - 1.130
+++ dev/pci/if_bgereg.h 17 Jun 2020 23:08:45 -
@@ -305,6 +305,7 @@
#defineBGE_CHIPID_BCM5717_A0 0x05717000
#defineBGE_CHIPID_BCM5717_B0 0x05717100
#defineBGE_CHIPID_BCM5719_A0 0x05719000
+#defineBGE_CHIPID_BCM5719_A1 0x05719001
#defineBGE_CHIPID_BCM5720_A0 0x0572
#defineBGE_CHIPID_BCM5762_A0 0x05762000
#defineBGE_CHIPID_BCM57765_A0 0x57785000
Re: simplify stoeplitz_hash_ip*
> On 18 Jun 2020, at 1:34 am, Theo Buehler wrote:
>
> The next step is to use that we have cached the result of the matrix
> multiplication H * val in stoeplitz_cache_entry(scache, val), so the
> identity (H * x) ^ (H * y) == H * (x ^ y) allows us to push the calls to
> the cache function down to the end of stoeplitz_hash_ip{4,6}{,port}().
>
> The result is the mechanical diff below. I have at least one follow-up,
> so it's intentionally minimalistic.
>
> The identity in question was again confirmed by brute force on amd64,
> sparc64 and powerpc for all possible values of skey, x and y.
ok dlg@
>
> Index: toeplitz.c
> ===
> RCS file: /cvs/src/sys/net/toeplitz.c,v
> retrieving revision 1.2
> diff -u -p -r1.2 toeplitz.c
> --- toeplitz.c17 Jun 2020 06:36:56 - 1.2
> +++ toeplitz.c17 Jun 2020 06:56:11 -
> @@ -118,17 +118,18 @@ stoeplitz_hash_ip4(const struct stoeplit
> {
> uint16_t lo, hi;
>
> - lo = stoeplitz_cache_entry(scache, faddr >> 0);
> - lo ^= stoeplitz_cache_entry(scache, faddr >> 16);
> - lo ^= stoeplitz_cache_entry(scache, laddr >> 0);
> - lo ^= stoeplitz_cache_entry(scache, laddr >> 16);
> -
> - hi = stoeplitz_cache_entry(scache, faddr >> 8);
> - hi ^= stoeplitz_cache_entry(scache, faddr >> 24);
> - hi ^= stoeplitz_cache_entry(scache, laddr >> 8);
> - hi ^= stoeplitz_cache_entry(scache, laddr >> 24);
> + lo = faddr >> 0;
> + lo ^= faddr >> 16;
> + lo ^= laddr >> 0;
> + lo ^= laddr >> 16;
> +
> + hi = faddr >> 8;
> + hi ^= faddr >> 24;
> + hi ^= laddr >> 8;
> + hi ^= laddr >> 24;
>
> - return (swap16(lo) ^ hi);
> + return (swap16(stoeplitz_cache_entry(scache, lo))
> + ^ stoeplitz_cache_entry(scache, hi));
> }
>
> uint16_t
> @@ -137,21 +138,22 @@ stoeplitz_hash_ip4port(const struct stoe
> {
> uint16_t hi, lo;
>
> - lo = stoeplitz_cache_entry(scache, faddr >> 0);
> - lo ^= stoeplitz_cache_entry(scache, faddr >> 16);
> - lo ^= stoeplitz_cache_entry(scache, laddr >> 0);
> - lo ^= stoeplitz_cache_entry(scache, laddr >> 16);
> - lo ^= stoeplitz_cache_entry(scache, fport >> 0);
> - lo ^= stoeplitz_cache_entry(scache, lport >> 0);
> -
> - hi = stoeplitz_cache_entry(scache, faddr >> 8);
> - hi ^= stoeplitz_cache_entry(scache, faddr >> 24);
> - hi ^= stoeplitz_cache_entry(scache, laddr >> 8);
> - hi ^= stoeplitz_cache_entry(scache, laddr >> 24);
> - hi ^= stoeplitz_cache_entry(scache, fport >> 8);
> - hi ^= stoeplitz_cache_entry(scache, lport >> 8);
> + lo = faddr >> 0;
> + lo ^= faddr >> 16;
> + lo ^= laddr >> 0;
> + lo ^= laddr >> 16;
> + lo ^= fport >> 0;
> + lo ^= lport >> 0;
> +
> + hi = faddr >> 8;
> + hi ^= faddr >> 24;
> + hi ^= laddr >> 8;
> + hi ^= laddr >> 24;
> + hi ^= fport >> 8;
> + hi ^= lport >> 8;
>
> - return (swap16(lo) ^ hi);
> + return (swap16(stoeplitz_cache_entry(scache, lo))
> + ^ stoeplitz_cache_entry(scache, hi));
> }
>
> #ifdef INET6
> @@ -166,18 +168,19 @@ stoeplitz_hash_ip6(const struct stoeplit
> uint32_t faddr = faddr6->s6_addr32[i];
> uint32_t laddr = laddr6->s6_addr32[i];
>
> - lo ^= stoeplitz_cache_entry(scache, faddr >> 0);
> - lo ^= stoeplitz_cache_entry(scache, faddr >> 16);
> - lo ^= stoeplitz_cache_entry(scache, laddr >> 0);
> - lo ^= stoeplitz_cache_entry(scache, laddr >> 16);
> -
> - hi ^= stoeplitz_cache_entry(scache, faddr >> 8);
> - hi ^= stoeplitz_cache_entry(scache, faddr >> 24);
> - hi ^= stoeplitz_cache_entry(scache, laddr >> 8);
> - hi ^= stoeplitz_cache_entry(scache, laddr >> 24);
> + lo ^= faddr >> 0;
> + lo ^= faddr >> 16;
> + lo ^= laddr >> 0;
> + lo ^= laddr >> 16;
> +
> + hi ^= faddr >> 8;
> + hi ^= faddr >> 24;
> + hi ^= laddr >> 8;
> + hi ^= laddr >> 24;
> }
>
> - return (swap16(lo) ^ hi);
> + return (swap16(stoeplitz_cache_entry(scache, lo))
> + ^ stoeplitz_cache_entry(scache, hi));
> }
>
> uint16_t
> @@ -192,24 +195,25 @@ stoeplitz_hash_ip6port(const struct stoe
> uint32_t faddr = faddr6->s6_addr32[i];
> uint32_t laddr = laddr6->s6_addr32[i];
>
> - lo ^= stoeplitz_cache_entry(scache, faddr >> 0);
> - lo ^= stoeplitz_cache_entry(scache, faddr >> 16);
> - lo ^= stoeplitz_cache_entry(scache, laddr >> 0);
> - lo ^= stoeplitz_cache_entry(scache, laddr >> 16);
> -
> - hi ^= stoeplitz_cache_entry(scache, faddr >> 8);
> - hi ^= stoeplitz_cache_entry(scache, faddr >> 24);
> - hi ^= stoeplitz_cache_entry(scache, laddr >> 8);
> - hi ^= stoeplitz_cache_entry(scache, laddr >> 24);
> +
Sync armv7 fbtab with arm64 fbtab
Hi tech@, Here is a diff to sync armv7 fbtab with arm64 fbtab. I left out drm devices as there aren't any on this platform. Comments? OK? Index: etc/etc.armv7/fbtab === RCS file: /cvs/src/etc/etc.armv7/fbtab,v retrieving revision 1.1 diff -u -p -r1.1 fbtab --- etc/etc.armv7/fbtab 4 Sep 2013 16:53:40 - 1.1 +++ etc/etc.armv7/fbtab 17 Jun 2020 21:07:00 - @@ -1 +1,2 @@ /dev/tty00 0600/dev/console +/dev/ttyC0 0600 /dev/console:/dev/wskbd:/dev/wskbd0:/dev/wsmouse:/dev/wsmouse0:/dev/ttyCcfg:/dev/ttyC4
Re: obsd 6.7 - ntpd error msg
Hi Otto here the logs (multitail) - @22:49:15 I restarted ntpd: - Jun 17 22:49:23 obsd ntpd[88568]: constraint reply from 188.61.106.24: offset -0.541051 Jun 17 22:49:46 obsd ntpd[88568]: peer 172.17.1.1 now valid 01] /var/log/daemon <--- 248KB - 2020/06/17 22:49:46 - Jun 17 14:00:01 obsd syslogd[80400]: restart Jun 17 16:19:41 obsd ntpd[92699]: pipe write error (from main): No such file or directory Jun 17 16:21:07 obsd ntpd[29588]: pipe write error (from main): No such file or directory Jun 17 17:00:01 obsd syslogd[80400]: restart Jun 17 17:01:25 obsd ntpd[96273]: pipe write error (from main): No such file or directory Jun 17 17:02:38 obsd ntpd[94737]: pipe write error (from main): No such file or directory Jun 17 20:00:01 obsd syslogd[80400]: restart Jun 17 22:00:01 obsd syslogd[80400]: restart Jun 17 22:49:22 obsd ntpd[40936]: pipe write error (from main): No such file or directory 02] /var/log/messages <--- 205KB - 2020/06/17 22:49:22 - 22:49:15 -ksh ToTo@obsd ~ $ doas rcctl restart ntpd ntpd(ok) ntpd(ok) 22:49:23 -ksh ToTo@obsd ~ $ On 17.06.2020 21:18, Otto Moerbeek wrote: On Wed, Jun 17, 2020 at 09:15:22PM +0200, Salvatore Cuzzilla wrote: Hi Otto, thanks for helping, really appreciated! The msg is showing after each restart. My simple conf here below: - 21:05:52 -ksh ToTo@obsd ~ $ doas cat /etc/ntpd.conf # $OpenBSD: ntpd.conf,v 1.14 2015/07/15 20:28:37 ajacoutot Exp $ # # See ntpd.conf(5) and /etc/examples/ntpd.conf server 172.17.1.1 sensor * constraints from "https://www.alfanetti.org"; - And show the log lines, all of them -Otto On 17.06.2020 20:51, Otto Moerbeek wrote: > On Wed, Jun 17, 2020 at 04:50:46PM +0200, Salvatore Cuzzilla wrote: > > > Hi Folks, > > > > when I restart ntpd I see this msg in /var/log/daemon: > > > > Jun 17 16:19:41 obsd ntpd[92699]: pipe write error (from main): No suchfile or directory > > > > however, time seems to be in sync: > > > > --- > > 16:37:17 -ksh ToTo@obsd ~ $ ntpctl -sa > > 1/1 peers valid, 1/1 sensors valid, constraint offset -1s, clock unsynced > > > > peer > >wt tl st next poll offset delay jitter > > 172.17.1.1 > > 1 10 3 2361s 3069s-0.008ms 0.716ms 0.137ms > > > > sensor > >wt gd st next poll offset correction > > vmt0 > > 1 1 07s 15s27.860ms 0.000ms > > > > 16:38:20 -ksh ToTo@obsd ~ $ doas sysctl -a | grep timecounter > > kern.timecounter.tick=1 > > kern.timecounter.timestepwarnings=0 > > kern.timecounter.hardware=tsc > > kern.timecounter.choice=i8254(0) acpihpet0(1000) tsc(2000) acpitimer0(1000) > > --- > > > > anyone else experiencing the same? > > > > --- > > :wq, > > Salvatore. > > > > Was the message in the log before or after restarting? > Please show your ntpd.conf > >-Otto > --- :wq, Salvatore. --- :wq, Salvatore.
Re: obsd 6.7 - ntpd error msg
On Wed, Jun 17, 2020 at 09:15:22PM +0200, Salvatore Cuzzilla wrote: > Hi Otto, > > thanks for helping, really appreciated! > The msg is showing after each restart. My simple conf here below: > - > 21:05:52 -ksh ToTo@obsd ~ $ doas cat /etc/ntpd.conf > # $OpenBSD: ntpd.conf,v 1.14 2015/07/15 20:28:37 ajacoutot Exp $ > # > # See ntpd.conf(5) and /etc/examples/ntpd.conf > > server 172.17.1.1 > sensor * > constraints from "https://www.alfanetti.org"; > - And show the log lines, all of them -Otto > > On 17.06.2020 20:51, Otto Moerbeek wrote: > > On Wed, Jun 17, 2020 at 04:50:46PM +0200, Salvatore Cuzzilla wrote: > > > > > Hi Folks, > > > > > > when I restart ntpd I see this msg in /var/log/daemon: > > > > > > Jun 17 16:19:41 obsd ntpd[92699]: pipe write error (from main): No > > > suchfile or directory > > > > > > however, time seems to be in sync: > > > > > > --- > > > 16:37:17 -ksh ToTo@obsd ~ $ ntpctl -sa > > > 1/1 peers valid, 1/1 sensors valid, constraint offset -1s, clock unsynced > > > > > > peer > > >wt tl st next poll offset delay jitter > > > 172.17.1.1 > > > 1 10 3 2361s 3069s-0.008ms 0.716ms 0.137ms > > > > > > sensor > > >wt gd st next poll offset correction > > > vmt0 > > > 1 1 07s 15s27.860ms 0.000ms > > > > > > 16:38:20 -ksh ToTo@obsd ~ $ doas sysctl -a | grep timecounter > > > kern.timecounter.tick=1 > > > kern.timecounter.timestepwarnings=0 > > > kern.timecounter.hardware=tsc > > > kern.timecounter.choice=i8254(0) acpihpet0(1000) tsc(2000) > > > acpitimer0(1000) > > > --- > > > > > > anyone else experiencing the same? > > > > > > --- > > > :wq, > > > Salvatore. > > > > > > > Was the message in the log before or after restarting? > > Please show your ntpd.conf > > > > -Otto > > > > --- > :wq, > Salvatore.
Re: obsd 6.7 - ntpd error msg
Hi Otto, thanks for helping, really appreciated! The msg is showing after each restart. My simple conf here below: - 21:05:52 -ksh ToTo@obsd ~ $ doas cat /etc/ntpd.conf # $OpenBSD: ntpd.conf,v 1.14 2015/07/15 20:28:37 ajacoutot Exp $ # # See ntpd.conf(5) and /etc/examples/ntpd.conf server 172.17.1.1 sensor * constraints from "https://www.alfanetti.org"; - On 17.06.2020 20:51, Otto Moerbeek wrote: On Wed, Jun 17, 2020 at 04:50:46PM +0200, Salvatore Cuzzilla wrote: Hi Folks, when I restart ntpd I see this msg in /var/log/daemon: Jun 17 16:19:41 obsd ntpd[92699]: pipe write error (from main): No suchfile or directory however, time seems to be in sync: --- 16:37:17 -ksh ToTo@obsd ~ $ ntpctl -sa 1/1 peers valid, 1/1 sensors valid, constraint offset -1s, clock unsynced peer wt tl st next poll offset delay jitter 172.17.1.1 1 10 3 2361s 3069s-0.008ms 0.716ms 0.137ms sensor wt gd st next poll offset correction vmt0 1 1 07s 15s27.860ms 0.000ms 16:38:20 -ksh ToTo@obsd ~ $ doas sysctl -a | grep timecounter kern.timecounter.tick=1 kern.timecounter.timestepwarnings=0 kern.timecounter.hardware=tsc kern.timecounter.choice=i8254(0) acpihpet0(1000) tsc(2000) acpitimer0(1000) --- anyone else experiencing the same? --- :wq, Salvatore. Was the message in the log before or after restarting? Please show your ntpd.conf -Otto --- :wq, Salvatore.
Re: obsd 6.7 - ntpd error msg
On Wed, Jun 17, 2020 at 04:50:46PM +0200, Salvatore Cuzzilla wrote: > Hi Folks, > > when I restart ntpd I see this msg in /var/log/daemon: > > Jun 17 16:19:41 obsd ntpd[92699]: pipe write error (from main): No suchfile > or directory > > however, time seems to be in sync: > > --- > 16:37:17 -ksh ToTo@obsd ~ $ ntpctl -sa > 1/1 peers valid, 1/1 sensors valid, constraint offset -1s, clock unsynced > > peer >wt tl st next poll offset delay jitter > 172.17.1.1 > 1 10 3 2361s 3069s-0.008ms 0.716ms 0.137ms > > sensor >wt gd st next poll offset correction > vmt0 > 1 1 07s 15s27.860ms 0.000ms > > 16:38:20 -ksh ToTo@obsd ~ $ doas sysctl -a | grep timecounter > kern.timecounter.tick=1 > kern.timecounter.timestepwarnings=0 > kern.timecounter.hardware=tsc > kern.timecounter.choice=i8254(0) acpihpet0(1000) tsc(2000) acpitimer0(1000) > --- > > anyone else experiencing the same? > > --- > :wq, > Salvatore. > Was the message in the log before or after restarting? Please show your ntpd.conf -Otto
Re: packets to bridged interfaces bypass input filter
Stephan Mending on Wed, May 27 2020: >> [bridge0 with members athn0 em0 vether0, all in group lan] >> >> # ifconfig athn0 -group lan > Did you flush states between your tests (pfctl -F states) ? -> After > you removed athn0 from lan group ? Yes, I did. >> [sys/net/if_bridge.c: bridge_process()] >> >> a packet that comes in on a member of a bridge and is addressed to _any_ >> bridge member interface, is processed as input to (only) the destination >> interface. if that destination interface differs from the one that the >> packet actually came in on, pf rules for the actual input interface are >> not evaluated. Note that the responsible code at the end of the function will set "ifp" to the interface that the packet arrived on and branch to reenqueue: bridge_ifinput(ifp, m); So if I'm reading this right, the idea is to reevaluate a packet that arrives on one interface for the address of another as having come in on the latter, and I'm guessing pf processing happens only after that. Correct me if I'm wrong: My expectation was that a packet that comes in on bridge member athn0 has to pass the "in" rules for athn0, regardless of destination. What I'm unsure about is how/if any rules for the destination member should apply. Should a packet coming in on athn0 but destined for the address of vether0 have to pass "in" rules for both athn0 and vether0? Regards, pesco
Add entry for wsfont_init.9 in man9 Makefile
Hi tech@, I commited wsfont_init.9 last year to document the wsfont module of wscons, but apparently forgot to add an entry in the man9 Makefile. The following diff does exactly that. Comments? OK? Index: share/man/man9/Makefile === RCS file: /cvs/src/share/man/man9/Makefile,v retrieving revision 1.302 diff -u -p -r1.302 Makefile --- share/man/man9/Makefile 17 Jun 2020 00:28:28 - 1.302 +++ share/man/man9/Makefile 17 Jun 2020 16:30:37 - @@ -49,6 +49,6 @@ MAN= aml_evalnode.9 atomic_add_int.9 ato vfs_cache.9 vaccess.9 vclean.9 vcount.9 vdevgone.9 vfinddev.9 vflush.9 \ vflushbuf.9 vget.9 vgone.9 vhold.9 vinvalbuf.9 vnode.9 vnsubr.9 \ VOP_LOOKUP.9 vput.9 vrecycle.9 vref.9 vrele.9 \ - vwaitforio.9 vwakeup.9 wdog_register.9 + vwaitforio.9 vwakeup.9 wdog_register.9 wsfont_init.9 .include
Re: [PATCH]: sysupgrade(8) don't create /home/_sysupgrade/keep
Nice catch!
Committed, thanks.
On Tue, Jun 16, 2020 at 01:36:22PM +0200, Martin Vahlensieck wrote:
> Hi
>
> In the last revision install.sub stopped using /home/_sysupgrade/keep,
> so unless I miss something this line can be removed.
>
> Best,
>
> Martin
>
> Index: sysupgrade.sh
> ===
> RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.sh,v
> retrieving revision 1.37
> diff -u -p -r1.37 sysupgrade.sh
> --- sysupgrade.sh 26 Jan 2020 22:08:36 - 1.37
> +++ sysupgrade.sh 16 Jun 2020 10:40:25 -
> @@ -178,8 +178,6 @@ if [[ -n ${DL} ]]; then
> unpriv cksum -qC SHA256 ${DL}
> fi
>
> -${KEEP} && > keep
> -
> cat <<__EOT >/auto_upgrade.conf
> Location of sets = disk
> Pathname to the sets = /home/_sysupgrade/
>
--
I'm not entirely sure you are real.
obsd 6.7 - ntpd error msg
Hi Folks, when I restart ntpd I see this msg in /var/log/daemon: Jun 17 16:19:41 obsd ntpd[92699]: pipe write error (from main): No suchfile or directory however, time seems to be in sync: --- 16:37:17 -ksh ToTo@obsd ~ $ ntpctl -sa 1/1 peers valid, 1/1 sensors valid, constraint offset -1s, clock unsynced peer wt tl st next poll offset delay jitter 172.17.1.1 1 10 3 2361s 3069s-0.008ms 0.716ms 0.137ms sensor wt gd st next poll offset correction vmt0 1 1 07s 15s27.860ms 0.000ms 16:38:20 -ksh ToTo@obsd ~ $ doas sysctl -a | grep timecounter kern.timecounter.tick=1 kern.timecounter.timestepwarnings=0 kern.timecounter.hardware=tsc kern.timecounter.choice=i8254(0) acpihpet0(1000) tsc(2000) acpitimer0(1000) --- anyone else experiencing the same? --- :wq, Salvatore.
simplify stoeplitz_hash_ip*
The next step is to use that we have cached the result of the matrix
multiplication H * val in stoeplitz_cache_entry(scache, val), so the
identity (H * x) ^ (H * y) == H * (x ^ y) allows us to push the calls to
the cache function down to the end of stoeplitz_hash_ip{4,6}{,port}().
The result is the mechanical diff below. I have at least one follow-up,
so it's intentionally minimalistic.
The identity in question was again confirmed by brute force on amd64,
sparc64 and powerpc for all possible values of skey, x and y.
Index: toeplitz.c
===
RCS file: /cvs/src/sys/net/toeplitz.c,v
retrieving revision 1.2
diff -u -p -r1.2 toeplitz.c
--- toeplitz.c 17 Jun 2020 06:36:56 - 1.2
+++ toeplitz.c 17 Jun 2020 06:56:11 -
@@ -118,17 +118,18 @@ stoeplitz_hash_ip4(const struct stoeplit
{
uint16_t lo, hi;
- lo = stoeplitz_cache_entry(scache, faddr >> 0);
- lo ^= stoeplitz_cache_entry(scache, faddr >> 16);
- lo ^= stoeplitz_cache_entry(scache, laddr >> 0);
- lo ^= stoeplitz_cache_entry(scache, laddr >> 16);
-
- hi = stoeplitz_cache_entry(scache, faddr >> 8);
- hi ^= stoeplitz_cache_entry(scache, faddr >> 24);
- hi ^= stoeplitz_cache_entry(scache, laddr >> 8);
- hi ^= stoeplitz_cache_entry(scache, laddr >> 24);
+ lo = faddr >> 0;
+ lo ^= faddr >> 16;
+ lo ^= laddr >> 0;
+ lo ^= laddr >> 16;
+
+ hi = faddr >> 8;
+ hi ^= faddr >> 24;
+ hi ^= laddr >> 8;
+ hi ^= laddr >> 24;
- return (swap16(lo) ^ hi);
+ return (swap16(stoeplitz_cache_entry(scache, lo))
+ ^ stoeplitz_cache_entry(scache, hi));
}
uint16_t
@@ -137,21 +138,22 @@ stoeplitz_hash_ip4port(const struct stoe
{
uint16_t hi, lo;
- lo = stoeplitz_cache_entry(scache, faddr >> 0);
- lo ^= stoeplitz_cache_entry(scache, faddr >> 16);
- lo ^= stoeplitz_cache_entry(scache, laddr >> 0);
- lo ^= stoeplitz_cache_entry(scache, laddr >> 16);
- lo ^= stoeplitz_cache_entry(scache, fport >> 0);
- lo ^= stoeplitz_cache_entry(scache, lport >> 0);
-
- hi = stoeplitz_cache_entry(scache, faddr >> 8);
- hi ^= stoeplitz_cache_entry(scache, faddr >> 24);
- hi ^= stoeplitz_cache_entry(scache, laddr >> 8);
- hi ^= stoeplitz_cache_entry(scache, laddr >> 24);
- hi ^= stoeplitz_cache_entry(scache, fport >> 8);
- hi ^= stoeplitz_cache_entry(scache, lport >> 8);
+ lo = faddr >> 0;
+ lo ^= faddr >> 16;
+ lo ^= laddr >> 0;
+ lo ^= laddr >> 16;
+ lo ^= fport >> 0;
+ lo ^= lport >> 0;
+
+ hi = faddr >> 8;
+ hi ^= faddr >> 24;
+ hi ^= laddr >> 8;
+ hi ^= laddr >> 24;
+ hi ^= fport >> 8;
+ hi ^= lport >> 8;
- return (swap16(lo) ^ hi);
+ return (swap16(stoeplitz_cache_entry(scache, lo))
+ ^ stoeplitz_cache_entry(scache, hi));
}
#ifdef INET6
@@ -166,18 +168,19 @@ stoeplitz_hash_ip6(const struct stoeplit
uint32_t faddr = faddr6->s6_addr32[i];
uint32_t laddr = laddr6->s6_addr32[i];
- lo ^= stoeplitz_cache_entry(scache, faddr >> 0);
- lo ^= stoeplitz_cache_entry(scache, faddr >> 16);
- lo ^= stoeplitz_cache_entry(scache, laddr >> 0);
- lo ^= stoeplitz_cache_entry(scache, laddr >> 16);
-
- hi ^= stoeplitz_cache_entry(scache, faddr >> 8);
- hi ^= stoeplitz_cache_entry(scache, faddr >> 24);
- hi ^= stoeplitz_cache_entry(scache, laddr >> 8);
- hi ^= stoeplitz_cache_entry(scache, laddr >> 24);
+ lo ^= faddr >> 0;
+ lo ^= faddr >> 16;
+ lo ^= laddr >> 0;
+ lo ^= laddr >> 16;
+
+ hi ^= faddr >> 8;
+ hi ^= faddr >> 24;
+ hi ^= laddr >> 8;
+ hi ^= laddr >> 24;
}
- return (swap16(lo) ^ hi);
+ return (swap16(stoeplitz_cache_entry(scache, lo))
+ ^ stoeplitz_cache_entry(scache, hi));
}
uint16_t
@@ -192,24 +195,25 @@ stoeplitz_hash_ip6port(const struct stoe
uint32_t faddr = faddr6->s6_addr32[i];
uint32_t laddr = laddr6->s6_addr32[i];
- lo ^= stoeplitz_cache_entry(scache, faddr >> 0);
- lo ^= stoeplitz_cache_entry(scache, faddr >> 16);
- lo ^= stoeplitz_cache_entry(scache, laddr >> 0);
- lo ^= stoeplitz_cache_entry(scache, laddr >> 16);
-
- hi ^= stoeplitz_cache_entry(scache, faddr >> 8);
- hi ^= stoeplitz_cache_entry(scache, faddr >> 24);
- hi ^= stoeplitz_cache_entry(scache, laddr >> 8);
- hi ^= stoeplitz_cache_entry(scache, laddr >> 24);
+ lo ^= faddr >> 0;
+ lo ^= faddr >> 16;
+ lo ^= laddr >> 0;
+ lo ^= laddr >> 16;
+
+ hi ^
Enable bwfm(4) on armv7 RAMDISK for SD/MMC and USB devices
Hi tech@, Here is a diff to enable bwfm(4) on armv7 RAMDISK for SD/MMC and USB devices. Discussed with patrick@. Tested on a Cubieboard2 by building a RAMDISK kernel, which shows my USB Wi-Fi dongle attaching when booting it. I checked the miniroot images and they all have several megabytes of free space: Filesystem SizeUsed Avail Capacity Mounted on /dev/vnd0a14.9M 12.0M3.0M80%/mnt Comments? OK? Index: arch/armv7/conf/RAMDISK === RCS file: /cvs/src/sys/arch/armv7/conf/RAMDISK,v retrieving revision 1.118 diff -u -p -r1.118 RAMDISK --- arch/armv7/conf/RAMDISK 29 Apr 2020 19:30:58 - 1.118 +++ arch/armv7/conf/RAMDISK 17 Jun 2020 10:05:23 - @@ -126,6 +126,7 @@ pci*at pciecam? sdhc* at fdt? sdmmc* at sdhc? +bwfm* at sdmmc? # Broadcom FullMAC psci* at fdt? early 1 syscon*at fdt? early 1 @@ -272,6 +273,7 @@ rsu*at uhub?# Realtek RTL8188SU/RTL8 uath* at uhub?# Atheros AR5005UG/AR5005UX otus* at uhub?# Atheros AR9001U athn* at uhub?# Atheros AR9002U +bwfm* at uhub?# Broadcom FullMAC atphy* at mii? # Attansic F1 PHYs rgephy*at mii? # Realtek 8169S/8110S PHY
improve pkg_add bandwidth usage with some mirrors
I propose a small diff for pkg_add when using http/https mirrors.
Don't wait 30 seconds for the ftp process to stop when closing
file handler, send SIGHUP immediately after closing the file handler.
Running pkg_add -u neovim (already installed and up to date) I got
those results of bandwidth usage
using mirror https://mirror.one.com/pub/OpenBSD/
62513 kB without diff
9050 kB with diff
using mirror https://ftp.fr.openbsd.org/pub/OpenBSD
6530 kB without diff
6373 kB with diff
The 2500 kB difference between the two mirrors with the diff is
explained by the html directory listing which is different
between servers. mirror.one.com list is 3800 kB while
ftp.fr.openbsd.org only 1387 kB.
I can't explain why but when using mirror.one.com the ftp command will
continuously fetch packages until completion or stop if ftp is killed
after 30 seconds. This extra downloaded data is useless.
I came with the following diff, but maybe the real issue is ftp(1)
not stopping immediately if output is closed?
Index: OpenBSD/PackageRepository.pm
===
RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PackageRepository.pm,v
retrieving revision 1.171
diff -u -p -r1.171 PackageRepository.pm
--- OpenBSD/PackageRepository.pm8 Nov 2019 14:50:58 - 1.171
+++ OpenBSD/PackageRepository.pm17 Jun 2020 09:21:41 -
@@ -206,12 +206,8 @@ sub close
my ($self, $object, $hint) = @_;
close($object->{fh}) if defined $object->{fh};
if (defined $object->{pid2}) {
- local $SIG{ALRM} = sub {
- kill HUP => $object->{pid2};
- };
- alarm(30);
+ kill HUP => $object->{pid2};
waitpid($object->{pid2}, 0);
- alarm(0);
}
$self->parse_problems($object->{errors}, $hint, $object)
if defined $object->{errors};
pckbd_enable: command error. anything to worry about?
It doesn't seem to be causing a problem but I've noticed these recently and thought I'd write a mail to at least document it / when it started. 2020-06-17T11:00:52.021Z symphytum /bsd: root on sd1a (2b4432fd9000a5b7.a) swap on sd1b dump on sd1b 2020-06-17T11:00:52.021Z symphytum /bsd: inteldrm0: 1920x1200, 32bpp 2020-06-17T11:00:52.021Z symphytum /bsd: wsdisplay0 at inteldrm0 mux 1 2020-06-17T11:00:52.021Z symphytum /bsd: pckbd_enable: command error 2020-06-17T11:00:52.021Z symphytum /bsd: wskbd1: connecting to wsdisplay0 2020-06-17T11:00:52.021Z symphytum /bsd: wskbd2: connecting to wsdisplay0 2020-06-17T11:00:52.022Z symphytum /bsd: wsdisplay0: screen 0-5 added (std, vt100 emulation) 2020-06-17T11:01:10.626Z symphytum /bsd: pckbd_enable: command error 2020-06-17T11:01:10.676Z symphytum /bsd: pckbd_disable: command error First seen with OpenBSD 6.7-current (GENERIC.MP) #24: Thu May 28 16:43:24 BST 2020 Previous kernel before I was running that OpenBSD 6.7-current (GENERIC.MP) #213: Sat May 23 20:38:40 MDT 2020 2020-06-17T11:00:51.991Z symphytum /bsd: OpenBSD 6.7-current (GENERIC.MP) #5: Wed Jun 17 11:38:10 BST 2020 2020-06-17T11:00:51.991Z symphytum /bsd: st...@symphytum.spacehopper.org:/sys/arch/amd64/compile/GENERIC.MP 2020-06-17T11:00:51.992Z symphytum /bsd: real mem = 34247069696 (32660MB) 2020-06-17T11:00:51.992Z symphytum /bsd: avail mem = 33194221568 (31656MB) 2020-06-17T11:00:51.992Z symphytum /bsd: random: good seed from bootblocks 2020-06-17T11:00:51.992Z symphytum /bsd: mpath0 at root 2020-06-17T11:00:51.992Z symphytum /bsd: scsibus0 at mpath0: 256 targets 2020-06-17T11:00:51.992Z symphytum /bsd: mainbus0 at root 2020-06-17T11:00:51.992Z symphytum /bsd: bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec400 (92 entries) 2020-06-17T11:00:51.993Z symphytum /bsd: bios0: vendor Dell Inc. version "A12" date 05/11/2017 2020-06-17T11:00:51.993Z symphytum /bsd: bios0: Dell Inc. PowerEdge T20 2020-06-17T11:00:51.993Z symphytum /bsd: acpi0 at bios0: ACPI 5.0 2020-06-17T11:00:51.993Z symphytum /bsd: acpi0: sleep states S0 S4 S5 2020-06-17T11:00:51.994Z symphytum /bsd: acpi0: tables DSDT FACP APIC FPDT SLIC LPIT SSDT SSDT SSDT HPET SSDT MCFG SSDT ASF! DMAR 2020-06-17T11:00:51.994Z symphytum /bsd: acpi0: wakeup devices UAR1(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) PXSX(S4) RP05(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3) EHC2(S3) XHC_(S4) HDEF(S4) [...] 2020-06-17T11:00:51.994Z symphytum /bsd: acpitimer0 at acpi0: 3579545 Hz, 24 bits 2020-06-17T11:00:51.994Z symphytum /bsd: acpimadt0 at acpi0 addr 0xfee0: PC-AT compat 2020-06-17T11:00:51.994Z symphytum /bsd: cpu0 at mainbus0: apid 0 (boot processor) 2020-06-17T11:00:51.995Z symphytum /bsd: cpu0: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3392.57 MHz, 06-3c-03 2020-06-17T11:00:51.995Z symphytum /bsd: cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN 2020-06-17T11:00:51.995Z symphytum /bsd: cpu0: 256KB 64b/line 8-way L2 cache 2020-06-17T11:00:51.995Z symphytum /bsd: cpu0: smt 0, core 0, package 0 2020-06-17T11:00:51.995Z symphytum /bsd: mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges 2020-06-17T11:00:51.995Z symphytum /bsd: cpu0: apic clock running at 99MHz 2020-06-17T11:00:51.995Z symphytum /bsd: cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE 2020-06-17T11:00:51.996Z symphytum /bsd: cpu1 at mainbus0: apid 2 (application processor) 2020-06-17T11:00:51.996Z symphytum /bsd: cpu1: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3392.17 MHz, 06-3c-03 2020-06-17T11:00:51.996Z symphytum /bsd: cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN 2020-06-17T11:00:51.996Z symphytum /bsd: cpu1: 256KB 64b/line 8-way L2 cache 2020-06-17T11:00:51.996Z symphytum /bsd: cpu1: smt 0, core 1, package 0 2020-06-17T11:00:51.996Z symphytum /bsd: cpu2 at mainbus0: apid 4 (application processor) 2020-06-17T11:00:51.996Z symphytum /bsd: cpu2: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3392.17 MHz, 06-3c-03 2020-06-17T11:00:51.996Z symphytum /bsd: cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2A
Re: multiple rings and cpus for ix(4)
On 17.6.2020. 13:13, Jonathan Matthew wrote: > On Wed, Jun 17, 2020 at 12:50:46PM +0200, Hrvoje Popovski wrote: >> On 17.6.2020. 12:45, Hrvoje Popovski wrote: >>> On 17.6.2020. 11:27, Hrvoje Popovski wrote: On 17.6.2020. 10:36, David Gwynne wrote: > this is an updated version of a diff from christiano haesbaert by way of > mpi@ to enable the use of multiple tx and rx rings with msi-x. > > the high level description is that that driver checks to see if msix is > available, and if so how many vectors it has. it then gets an intrmap > based on that information, and bumps the number of queues to the number > of cpus that intrmap says are available. > > once the queues are allocated, it then iterates over them and wires up > interrupts to the cpus provided by the intrmap. > > im happy for people to try this out, but i can't commit it until all the > architectures that ix(4) is enabled on support the APIs that it's using. > this basically means it'll work on amd64 (and a little bit on i386), but > not much else. please hold back your tears and cries of anguish. > > thanks to christiano and mpi for doing most of the work leading up to > this diff :) Hi, first, thank you all for mq work :) with this diff, if i'm sending traffic over ix and at the same time execute ifconfig ix down/up, forwarding stops until i stop generator, wait for few seconds and execute ifconfig ix down/up few times and than forwarding start normally >>> >> >> >> in vmstat i should see ix0:0-5 and ix1:0-5 ? > > vmstat -i only shows interrupts that have actually fired. Use -zi to show > all interrupts. > > This diff doesn't set up RSS, so received packets will only go to the first > vector, which is why only one of the ix1 interrupts has fired. Outgoing > packets are scattered across the tx queues, so all the ix0 interrupts have > fired. yes, thank you .. r620-1# vmstat -iz interrupt total rate irq0/clock4967987 599 irq0/ipi 14405128 1738 irq144/acpi040 irq114/ix0:0 20722297 2501 irq115/ix0:1 15585680 1881 irq116/ix0:2 14654922 1768 irq117/ix0:3861769301 104015 irq118/ix0:4 17121128 2066 irq119/ix0:5 17010524 2053 irq120/ix0 100 irq121/ix1:0 55895380 6746 irq122/ix1:100 irq123/ix1:200 irq124/ix1:300 irq125/ix1:400 irq126/ix1:500 irq127/ix1 160 irq96/ppb1 00 irq97/mfi0 380924 irq98/ppb3 00 irq128/ixl0 00 irq129/ixl0:0 00 irq130/ixl1 00 irq131/ixl1:0 00 irq132/ixl2 70 irq133/ixl2:0 5650 irq134/ixl3 70 irq135/ixl3:0 5590 irq99/ehci0 1390 irq136/em0 230872 irq137/em15590 irq100/ehci1 280 irq101/ahci010 irq145/com0 00 irq146/com1 44110 Total 1022199832 123379
Re: multiple rings and cpus for ix(4)
On Wed, Jun 17, 2020 at 12:50:46PM +0200, Hrvoje Popovski wrote: > On 17.6.2020. 12:45, Hrvoje Popovski wrote: > > On 17.6.2020. 11:27, Hrvoje Popovski wrote: > >> On 17.6.2020. 10:36, David Gwynne wrote: > >>> this is an updated version of a diff from christiano haesbaert by way of > >>> mpi@ to enable the use of multiple tx and rx rings with msi-x. > >>> > >>> the high level description is that that driver checks to see if msix is > >>> available, and if so how many vectors it has. it then gets an intrmap > >>> based on that information, and bumps the number of queues to the number > >>> of cpus that intrmap says are available. > >>> > >>> once the queues are allocated, it then iterates over them and wires up > >>> interrupts to the cpus provided by the intrmap. > >>> > >>> im happy for people to try this out, but i can't commit it until all the > >>> architectures that ix(4) is enabled on support the APIs that it's using. > >>> this basically means it'll work on amd64 (and a little bit on i386), but > >>> not much else. please hold back your tears and cries of anguish. > >>> > >>> thanks to christiano and mpi for doing most of the work leading up to > >>> this diff :) > >> > >> Hi, > >> > >> first, thank you all for mq work :) > >> > >> with this diff, if i'm sending traffic over ix and at the same time > >> execute ifconfig ix down/up, forwarding stops until i stop generator, > >> wait for few seconds and execute ifconfig ix down/up few times and than > >> forwarding start normally > > > > > in vmstat i should see ix0:0-5 and ix1:0-5 ? vmstat -i only shows interrupts that have actually fired. Use -zi to show all interrupts. This diff doesn't set up RSS, so received packets will only go to the first vector, which is why only one of the ix1 interrupts has fired. Outgoing packets are scattered across the tx queues, so all the ix0 interrupts have fired. > > r620-1# vmstat -i > interrupt total rate > irq0/clock3985752 599 > irq0/ipi 3462063 520 > irq144/acpi040 > irq114/ix0:0 8042709 1209 > irq115/ix0:1 2906070 437 > irq116/ix0:2 1975350 297 > irq117/ix0:3849089681 127721 > irq118/ix0:4 4441608 668 > irq119/ix0:5 4330871 651 > irq120/ix0 100 > irq121/ix1:0 43209056 6499 > irq127/ix1 160 > irq97/mfi0 368465 > irq132/ixl2 70 > irq133/ixl2:0 4590 > irq134/ixl3 70 > irq135/ixl3:0 4510 > irq99/ehci0 1390 > irq136/em0 186372 > irq137/em14510 > irq100/ehci1 280 > irq101/ahci010 > irq146/com1 44110 > Total 921504627 138613 >
Re: multiple rings and cpus for ix(4)
On 17.6.2020. 12:45, Hrvoje Popovski wrote: > On 17.6.2020. 11:27, Hrvoje Popovski wrote: >> On 17.6.2020. 10:36, David Gwynne wrote: >>> this is an updated version of a diff from christiano haesbaert by way of >>> mpi@ to enable the use of multiple tx and rx rings with msi-x. >>> >>> the high level description is that that driver checks to see if msix is >>> available, and if so how many vectors it has. it then gets an intrmap >>> based on that information, and bumps the number of queues to the number >>> of cpus that intrmap says are available. >>> >>> once the queues are allocated, it then iterates over them and wires up >>> interrupts to the cpus provided by the intrmap. >>> >>> im happy for people to try this out, but i can't commit it until all the >>> architectures that ix(4) is enabled on support the APIs that it's using. >>> this basically means it'll work on amd64 (and a little bit on i386), but >>> not much else. please hold back your tears and cries of anguish. >>> >>> thanks to christiano and mpi for doing most of the work leading up to >>> this diff :) >> >> Hi, >> >> first, thank you all for mq work :) >> >> with this diff, if i'm sending traffic over ix and at the same time >> execute ifconfig ix down/up, forwarding stops until i stop generator, >> wait for few seconds and execute ifconfig ix down/up few times and than >> forwarding start normally > in vmstat i should see ix0:0-5 and ix1:0-5 ? r620-1# vmstat -i interrupt total rate irq0/clock3985752 599 irq0/ipi 3462063 520 irq144/acpi040 irq114/ix0:0 8042709 1209 irq115/ix0:1 2906070 437 irq116/ix0:2 1975350 297 irq117/ix0:3849089681 127721 irq118/ix0:4 4441608 668 irq119/ix0:5 4330871 651 irq120/ix0 100 irq121/ix1:0 43209056 6499 irq127/ix1 160 irq97/mfi0 368465 irq132/ixl2 70 irq133/ixl2:0 4590 irq134/ixl3 70 irq135/ixl3:0 4510 irq99/ehci0 1390 irq136/em0 186372 irq137/em14510 irq100/ehci1 280 irq101/ahci010 irq146/com1 44110 Total 921504627 138613 > dmesg > > ix0 at pci1 dev 0 function 0 "Intel 82599" rev 0x01, msix, 6 queues, > address ec:f4:bb:da:f7:f8 > ix1 at pci1 dev 0 function 1 "Intel 82599" rev 0x01, msix, 6 queues, > address ec:f4:bb:da:f7:fa > > > > OpenBSD 6.7-current (GENERIC.MP) #71: Wed Jun 17 10:53:55 CEST 2020 > hrv...@r620-1.srce.hr:/sys/arch/amd64/compile/GENERIC.MP > real mem = 17115840512 (16322MB) > avail mem = 16582168576 (15813MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xcf42c000 (99 entries) > bios0: vendor Dell Inc. version "2.9.0" date 12/06/2019 > bios0: Dell Inc. PowerEdge R620 > acpi0 at bios0: ACPI 3.0 > acpi0: sleep states S0 S4 S5 > acpi0: tables DSDT FACP APIC SPCR HPET DMAR MCFG WDAT SLIC ERST HEST > BERT EINJ TCPA PC__ SRAT SSDT > acpi0: wakeup devices PCI0(S5) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 4 (boot processor) > cpu0: Intel(R) Xeon(R) CPU E5-2643 v2 @ 3.50GHz, 3600.48 MHz, 06-3e-04 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 2, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE > cpu1 at mainbus0: apid 6 (application processor) > cpu1: Intel(R) Xeon(R) CPU E5-2643 v2 @ 3.50GHz, 3600.00 MHz, 06-3e-04 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu1: 256KB 64b/line 8-way L2 cache > cpu1: smt 0, core 3, package 0 > cpu2 at mainbus0: apid 8 (application processor) > cpu2: Intel(R) Xe
Re: multiple rings and cpus for ix(4)
On 17.6.2020. 11:27, Hrvoje Popovski wrote: > On 17.6.2020. 10:36, David Gwynne wrote: >> this is an updated version of a diff from christiano haesbaert by way of >> mpi@ to enable the use of multiple tx and rx rings with msi-x. >> >> the high level description is that that driver checks to see if msix is >> available, and if so how many vectors it has. it then gets an intrmap >> based on that information, and bumps the number of queues to the number >> of cpus that intrmap says are available. >> >> once the queues are allocated, it then iterates over them and wires up >> interrupts to the cpus provided by the intrmap. >> >> im happy for people to try this out, but i can't commit it until all the >> architectures that ix(4) is enabled on support the APIs that it's using. >> this basically means it'll work on amd64 (and a little bit on i386), but >> not much else. please hold back your tears and cries of anguish. >> >> thanks to christiano and mpi for doing most of the work leading up to >> this diff :) > > Hi, > > first, thank you all for mq work :) > > with this diff, if i'm sending traffic over ix and at the same time > execute ifconfig ix down/up, forwarding stops until i stop generator, > wait for few seconds and execute ifconfig ix down/up few times and than > forwarding start normally dmesg ix0 at pci1 dev 0 function 0 "Intel 82599" rev 0x01, msix, 6 queues, address ec:f4:bb:da:f7:f8 ix1 at pci1 dev 0 function 1 "Intel 82599" rev 0x01, msix, 6 queues, address ec:f4:bb:da:f7:fa OpenBSD 6.7-current (GENERIC.MP) #71: Wed Jun 17 10:53:55 CEST 2020 hrv...@r620-1.srce.hr:/sys/arch/amd64/compile/GENERIC.MP real mem = 17115840512 (16322MB) avail mem = 16582168576 (15813MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xcf42c000 (99 entries) bios0: vendor Dell Inc. version "2.9.0" date 12/06/2019 bios0: Dell Inc. PowerEdge R620 acpi0 at bios0: ACPI 3.0 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP APIC SPCR HPET DMAR MCFG WDAT SLIC ERST HEST BERT EINJ TCPA PC__ SRAT SSDT acpi0: wakeup devices PCI0(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 4 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5-2643 v2 @ 3.50GHz, 3600.48 MHz, 06-3e-04 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 2, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE cpu1 at mainbus0: apid 6 (application processor) cpu1: Intel(R) Xeon(R) CPU E5-2643 v2 @ 3.50GHz, 3600.00 MHz, 06-3e-04 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 3, package 0 cpu2 at mainbus0: apid 8 (application processor) cpu2: Intel(R) Xeon(R) CPU E5-2643 v2 @ 3.50GHz, 3600.00 MHz, 06-3e-04 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 4, package 0 cpu3 at mainbus0: apid 16 (application processor) cpu3: Intel(R) Xeon(R) CPU E5-2643 v2 @ 3.50GHz, 3600.00 MHz, 06-3e-04 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 8, package 0 cpu4 at mainbus0: apid 18 (application processor) cpu4: Intel(R) Xeon(R) CPU E5-2643 v2 @ 3.50GHz, 3600.01 MHz, 06-3e-04 cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCI
Re: ddb(4): tr /t 0t
On Wed, Jun 17, 2020 at 10:34:58AM +0100, Stuart Henderson wrote: > Every time I want to use this I spend several minutes figuring out rhe > correct prefix, it would help to add a note. Ok? Since I hit the same issue I'm OK with this :) > Index: man4/ddb.4 > === > RCS file: /cvs/src/share/man/man4/ddb.4,v > retrieving revision 1.97 > diff -u -p -r1.97 ddb.4 > --- man4/ddb.417 May 2020 14:34:35 - 1.97 > +++ man4/ddb.417 Jun 2020 09:31:49 - > @@ -557,6 +557,8 @@ modifier interprets the > .Ar frameaddr > argument as the TID of a process and shows the stack trace of > that process. > +.Ar frameaddr > +is subject to the radix; use the 0t prefix to enter a decimal TID. > The > .Cm /t > modifier is not supported on all platforms. > -- :wq Claudio
Re: New EVFILT_EXCEPT for POLLPRI & POLLRDBAND
On 16/06/20(Tue) 06:18, Todd C. Miller wrote:
> On Tue, 16 Jun 2020 12:48:58 +0200, Martin Pieuchot wrote:
>
> > The diff below implements DragonFly's approach of adding a new kind of
> > filter, EVFILT_EXCEPT, to report such conditions. This extends the
> > existing kqueue interface which is questionable. On the one hand this
> > allows userland programs to use kevent(2) to check for this conditions.
> > One the other hand this is not supported by any other BSD and thus non
> > standard.
>
> Actually, it looks like macOS uses EVFILT_EXCEPT too. They were
> the first OS to implement poll in terms of kqueue as far as I know.
> I don't think there is a problem extended kqueue with EVFILT_EXCEPT.
>
> > In the tree there's two poll handlers that set the POLLPRI & POLLRDBAND
> > bits as illustrated by the diff below.
> >
> > Do we see value in this new type of filter? Should I document it and
> > put it in? Or should I restrict it to the __EV_POLL for now? In the
> > latter case should we pick a different name and/or prefix it?
>
> I think EVFILT_EXCEPT should be exposed to userland. It is not our
> own invention and two other OSes support it.
Updated diff below addresses multiples comments and implements the
common functionalities of EVFILT_EXCEPT supported by both DragonFly
and xnu. Changes compared to the previous version include:
- Introduction of NOTE_OOB which should be set in `fflags' according to
other implementations
- Set `kn_data' to the value of `so_oobmark' for sockets. This matches
xnu behavior, the arbitrary value was also questioned by visa@.
- Adds a missing break pointed out by anton@
- Set NOTE_OOB for pty as well, this isn't supported by DragonFly nor
xnu but I don't see the point of introducing something different.
- Document the new filter
Note that the last available version of Xnu available on github, from
late 2018, has the following behavior which this diff doesn't implement:
If the read direction of the socket has shutdown, then
the filter also sets EV_EOF in flags, and returns the
socket error (if any) in fflags
ok?
Index: sys/kern/kern_event.c
===
RCS file: /cvs/src/sys/kern/kern_event.c,v
retrieving revision 1.139
diff -u -p -r1.139 kern_event.c
--- sys/kern/kern_event.c 15 Jun 2020 15:42:11 - 1.139
+++ sys/kern/kern_event.c 17 Jun 2020 09:35:42 -
@@ -158,6 +158,7 @@ const struct filterops *const sysfilt_op
&sig_filtops, /* EVFILT_SIGNAL */
&timer_filtops, /* EVFILT_TIMER */
&file_filtops, /* EVFILT_DEVICE */
+ &file_filtops, /* EVFILT_EXCEPT */
};
void
Index: sys/kern/tty_pty.c
===
RCS file: /cvs/src/sys/kern/tty_pty.c,v
retrieving revision 1.100
diff -u -p -r1.100 tty_pty.c
--- sys/kern/tty_pty.c 15 Jun 2020 15:29:40 - 1.100
+++ sys/kern/tty_pty.c 17 Jun 2020 09:34:02 -
@@ -107,6 +107,7 @@ voidfilt_ptcrdetach(struct knote *);
intfilt_ptcread(struct knote *, long);
void filt_ptcwdetach(struct knote *);
intfilt_ptcwrite(struct knote *, long);
+intfilt_ptcexcept(struct knote *, long);
static struct pt_softc **ptyarralloc(int);
static int check_pty(int);
@@ -719,6 +720,25 @@ filt_ptcwrite(struct knote *kn, long hin
return (kn->kn_data > 0);
}
+int
+filt_ptcexcept(struct knote *kn, long hint)
+{
+ struct pt_softc *pti = (struct pt_softc *)kn->kn_hook;
+ struct tty *tp;
+
+ tp = pti->pt_tty;
+ kn->kn_data = 0;
+
+ /* If in packet or user control mode, check for data. */
+ if (((pti->pt_flags & PF_PKT) && pti->pt_send) ||
+ ((pti->pt_flags & PF_UCNTL) && pti->pt_ucntl)) {
+ kn->kn_fflags |= NOTE_OOB;
+ kn->kn_data = 1;
+ }
+
+ return (kn->kn_data > 0);
+}
+
const struct filterops ptcread_filtops = {
.f_flags= FILTEROP_ISFD,
.f_attach = NULL,
@@ -733,6 +753,13 @@ const struct filterops ptcwrite_filtops
.f_event= filt_ptcwrite,
};
+const struct filterops ptcexcept_filtops = {
+ .f_flags= FILTEROP_ISFD,
+ .f_attach = NULL,
+ .f_detach = filt_ptcrdetach,
+ .f_event= filt_ptcexcept,
+};
+
int
ptckqfilter(dev_t dev, struct knote *kn)
{
@@ -748,6 +775,10 @@ ptckqfilter(dev_t dev, struct knote *kn)
case EVFILT_WRITE:
klist = &pti->pt_selw.si_note;
kn->kn_fop = &ptcwrite_filtops;
+ break;
+ case EVFILT_EXCEPT:
+ klist = &pti->pt_selr.si_note;
+ kn->kn_fop = &ptcexcept_filtops;
break;
default:
return (EINVAL);
Index: sys/kern/uipc_socket.c
===
RCS file: /cvs/src/sys/k
btrace(8) seems to read same events
Hi, I'm newbie to OpenBSD.
I'm trying to learn OpenBSD kernel by btrace.
It is really helpful tool to me.
Thanks for the development and 6.7 release.
I found that brace sometimes read more than one event at the same time.
After that, same events are always read and evaluated by my btrace script.
I think btrace command reuses the read buffer for '/dev/dt' in each read.
It is cleared by nobody and overwritten by the kernel.
It seems that btrace expects zero is written at the end of the buffer,
But kernel doesn't write zeroes.
So if more than one events are read and then one event is read in next time,
the second event is still written and evaluated by btrace script.
I think number of read events should be determined by return value of read(2).
Following patch works for me.
Index: btrace.c
===
RCS file: /cvs/src/usr.sbin/btrace/btrace.c,v
retrieving revision 1.18
diff -u -p -r1.18 btrace.c
--- btrace.c24 Apr 2020 14:56:43 - 1.18
+++ btrace.c17 Jun 2020 08:25:49 -
@@ -339,12 +339,8 @@ rules_do(int fd)
err(1, "incorrect read");
- for (i = 0; i < nitems(devtbuf); i++) {
+ for (i = 0; i < rlen / sizeof(struct dt_evt); i++) {
struct dt_evt *dtev = &devtbuf[i];
-
- if (dtev->dtev_tid == 0)
- break;
-
rules_apply(dtev);
}
}
--
Yuichiro NAITO (naito.yuich...@gmail.com)
ddb(4): tr /t 0t
Every time I want to use this I spend several minutes figuring out rhe correct prefix, it would help to add a note. Ok? Index: man4/ddb.4 === RCS file: /cvs/src/share/man/man4/ddb.4,v retrieving revision 1.97 diff -u -p -r1.97 ddb.4 --- man4/ddb.4 17 May 2020 14:34:35 - 1.97 +++ man4/ddb.4 17 Jun 2020 09:31:49 - @@ -557,6 +557,8 @@ modifier interprets the .Ar frameaddr argument as the TID of a process and shows the stack trace of that process. +.Ar frameaddr +is subject to the radix; use the 0t prefix to enter a decimal TID. The .Cm /t modifier is not supported on all platforms.
Re: multiple rings and cpus for ix(4)
On 17.6.2020. 10:36, David Gwynne wrote: > this is an updated version of a diff from christiano haesbaert by way of > mpi@ to enable the use of multiple tx and rx rings with msi-x. > > the high level description is that that driver checks to see if msix is > available, and if so how many vectors it has. it then gets an intrmap > based on that information, and bumps the number of queues to the number > of cpus that intrmap says are available. > > once the queues are allocated, it then iterates over them and wires up > interrupts to the cpus provided by the intrmap. > > im happy for people to try this out, but i can't commit it until all the > architectures that ix(4) is enabled on support the APIs that it's using. > this basically means it'll work on amd64 (and a little bit on i386), but > not much else. please hold back your tears and cries of anguish. > > thanks to christiano and mpi for doing most of the work leading up to > this diff :) Hi, first, thank you all for mq work :) with this diff, if i'm sending traffic over ix and at the same time execute ifconfig ix down/up, forwarding stops until i stop generator, wait for few seconds and execute ifconfig ix down/up few times and than forwarding start normally
iwx: offload WPA2 crypto to hardware
This patch implements WPA2 (CCMP) crypto offload for iwx(4).
The patch will only work on top of an up-to-date tree. Note that I just
committed another patch (Tx rate selection offload) to CVS which is
required in order to test this CCMP offload patch.
ok?
diff 928c82450e6e5ea105cab6ca7a7766c4b84f1e21
730c65a14bf291ecd58baa8b3cc72e18ca34903d
blob - 113362f4c0f4a672dc8ef719bd95964a53817db5
blob + d3fa66b174be1e0200e95254640f95c60c0e4508
--- sys/dev/pci/if_iwx.c
+++ sys/dev/pci/if_iwx.c
@@ -349,8 +349,10 @@ intiwx_rxmq_get_signal_strength(struct iwx_softc
*, s
void iwx_rx_rx_phy_cmd(struct iwx_softc *, struct iwx_rx_packet *,
struct iwx_rx_data *);
intiwx_get_noise(const struct iwx_statistics_rx_non_phy *);
-void iwx_rx_frame(struct iwx_softc *, struct mbuf *, int, int, int, uint32_t,
- struct ieee80211_rxinfo *, struct mbuf_list *);
+intiwx_ccmp_decap(struct iwx_softc *, struct mbuf *,
+ struct ieee80211_node *);
+void iwx_rx_frame(struct iwx_softc *, struct mbuf *, int, uint32_t, int, int,
+ uint32_t, struct ieee80211_rxinfo *, struct mbuf_list *);
void iwx_enable_ht_cck_fallback(struct iwx_softc *, struct iwx_node *);
void iwx_rx_tx_cmd_single(struct iwx_softc *, struct iwx_rx_packet *,
struct iwx_node *, int, int);
@@ -420,6 +422,10 @@ intiwx_disassoc(struct iwx_softc *);
intiwx_run(struct iwx_softc *);
intiwx_run_stop(struct iwx_softc *);
struct ieee80211_node *iwx_node_alloc(struct ieee80211com *);
+intiwx_set_key(struct ieee80211com *, struct ieee80211_node *,
+ struct ieee80211_key *);
+void iwx_delete_key(struct ieee80211com *,
+ struct ieee80211_node *, struct ieee80211_key *);
void iwx_calib_timeout(void *);
intiwx_media_change(struct ifnet *);
void iwx_newstate_task(void *);
@@ -3538,16 +3544,65 @@ iwx_get_noise(const struct iwx_statistics_rx_non_phy *
return (nbant == 0) ? -127 : (total / nbant) - 107;
}
+int
+iwx_ccmp_decap(struct iwx_softc *sc, struct mbuf *m, struct ieee80211_node *ni)
+{
+ struct ieee80211com *ic = &sc->sc_ic;
+ struct ieee80211_key *k = &ni->ni_pairwise_key;
+ struct ieee80211_frame *wh;
+ uint64_t pn, *prsc;
+ uint8_t *ivp;
+ uint8_t tid;
+ int hdrlen, hasqos;
+
+ wh = mtod(m, struct ieee80211_frame *);
+ hdrlen = ieee80211_get_hdrlen(wh);
+ ivp = (uint8_t *)wh + hdrlen;
+
+ /* Check that ExtIV bit is be set. */
+ if (!(ivp[3] & IEEE80211_WEP_EXTIV))
+ return 1;
+
+ hasqos = ieee80211_has_qos(wh);
+ tid = hasqos ? ieee80211_get_qos(wh) & IEEE80211_QOS_TID : 0;
+ prsc = &k->k_rsc[tid];
+
+ /* Extract the 48-bit PN from the CCMP header. */
+ pn = (uint64_t)ivp[0] |
+(uint64_t)ivp[1] << 8 |
+(uint64_t)ivp[4] << 16 |
+(uint64_t)ivp[5] << 24 |
+(uint64_t)ivp[6] << 32 |
+(uint64_t)ivp[7] << 40;
+ if (pn <= *prsc) {
+ ic->ic_stats.is_ccmp_replays++;
+ return 1;
+ }
+ /* Last seen packet number is updated in ieee80211_inputm(). */
+
+ /*
+* Some firmware versions strip the MIC, and some don't. It is not
+* clear which of the capability flags could tell us what to expect.
+* For now, keep things simple and just leave the MIC in place if
+* it is present.
+*
+* The IV will be stripped by ieee80211_inputm().
+*/
+ return 0;
+}
+
void
iwx_rx_frame(struct iwx_softc *sc, struct mbuf *m, int chanidx,
- int is_shortpre, int rate_n_flags, uint32_t device_timestamp,
- struct ieee80211_rxinfo *rxi, struct mbuf_list *ml)
+uint32_t rx_pkt_status, int is_shortpre, int rate_n_flags,
+uint32_t device_timestamp, struct ieee80211_rxinfo *rxi,
+struct mbuf_list *ml)
{
struct ieee80211com *ic = &sc->sc_ic;
struct ieee80211_frame *wh;
struct ieee80211_node *ni;
struct ieee80211_channel *bss_chan;
uint8_t saved_bssid[IEEE80211_ADDR_LEN] = { 0 };
+ struct ifnet *ifp = IC2IFP(ic);
if (chanidx < 0 || chanidx >= nitems(ic->ic_channels))
chanidx = ieee80211_chan2ieee(ic, ic->ic_ibss_chan);
@@ -3564,6 +3619,37 @@ iwx_rx_frame(struct iwx_softc *sc, struct mbuf *m, int
}
ni->ni_chan = &ic->ic_channels[chanidx];
+ /* Handle hardware decryption. */
+ if (((wh->i_fc[0] & IEEE80211_FC0_TYPE_MASK) != IEEE80211_FC0_TYPE_CTL)
+ && (wh->i_fc[1] & IEEE80211_FC1_PROTECTED) &&
+ (ni->ni_flags & IEEE80211_NODE_RXPROT) &&
+ ni->ni_pairwise_key.k_cipher == IEEE80211_CIPHER_CCMP) {
+ if ((rx_pkt_status & IWX_RX_MPDU_RES_STATUS_SEC_ENC_MSK) !=
+ IWX_RX_MPDU_RES_STATUS_SEC_CCM_ENC) {
+ ic->ic_stats.is_ccmp_dec_errs++;
+ ifp->if_ierrors++;
+
multiple rings and cpus for ix(4)
this is an updated version of a diff from christiano haesbaert by way of
mpi@ to enable the use of multiple tx and rx rings with msi-x.
the high level description is that that driver checks to see if msix is
available, and if so how many vectors it has. it then gets an intrmap
based on that information, and bumps the number of queues to the number
of cpus that intrmap says are available.
once the queues are allocated, it then iterates over them and wires up
interrupts to the cpus provided by the intrmap.
im happy for people to try this out, but i can't commit it until all the
architectures that ix(4) is enabled on support the APIs that it's using.
this basically means it'll work on amd64 (and a little bit on i386), but
not much else. please hold back your tears and cries of anguish.
thanks to christiano and mpi for doing most of the work leading up to
this diff :)
Index: if_ix.c
===
RCS file: /cvs/src/sys/dev/pci/if_ix.c,v
retrieving revision 1.166
diff -u -p -r1.166 if_ix.c
--- if_ix.c 7 Jun 2020 23:52:05 - 1.166
+++ if_ix.c 17 Jun 2020 08:27:55 -
@@ -115,7 +115,7 @@ voidixgbe_identify_hardware(struct ix_s
intixgbe_allocate_pci_resources(struct ix_softc *);
intixgbe_allocate_legacy(struct ix_softc *);
intixgbe_allocate_msix(struct ix_softc *);
-intixgbe_setup_msix(struct ix_softc *);
+void ixgbe_setup_msix(struct ix_softc *);
intixgbe_allocate_queues(struct ix_softc *);
void ixgbe_free_pci_resources(struct ix_softc *);
void ixgbe_local_timer(void *);
@@ -199,7 +199,7 @@ struct cfattach ix_ca = {
};
int ixgbe_smart_speed = ixgbe_smart_speed_on;
-int ixgbe_enable_msix = 0;
+int ixgbe_enable_msix = 1;
/*
* Device identification routine
@@ -301,7 +301,7 @@ ixgbe_attach(struct device *parent, stru
bcopy(sc->hw.mac.addr, sc->arpcom.ac_enaddr,
IXGBE_ETH_LENGTH_OF_ADDRESS);
- if (sc->msix > 1)
+ if (sc->sc_intrmap)
error = ixgbe_allocate_msix(sc);
else
error = ixgbe_allocate_legacy(sc);
@@ -798,7 +798,7 @@ ixgbe_init(void *arg)
timeout_add_sec(&sc->timer, 1);
/* Set up MSI/X routing */
- if (sc->msix > 1) {
+ if (sc->sc_intrmap) {
ixgbe_configure_ivars(sc);
/* Set up auto-mask */
if (sc->hw.mac.type == ixgbe_mac_82598EB)
@@ -829,7 +829,7 @@ ixgbe_init(void *arg)
itr |= IXGBE_EITR_LLI_MOD | IXGBE_EITR_CNT_WDIS;
IXGBE_WRITE_REG(&sc->hw, IXGBE_EITR(0), itr);
- if (sc->msix > 1) {
+ if (sc->sc_intrmap) {
/* Set moderation on the Link interrupt */
IXGBE_WRITE_REG(&sc->hw, IXGBE_EITR(sc->linkvec),
IXGBE_LINK_ITR);
@@ -903,7 +903,7 @@ ixgbe_config_gpie(struct ix_softc *sc)
gpie |= 0xf << IXGBE_GPIE_LLI_DELAY_SHIFT;
}
- if (sc->msix > 1) {
+ if (sc->sc_intrmap) {
/* Enable Enhanced MSIX mode */
gpie |= IXGBE_GPIE_MSIX_MODE;
gpie |= IXGBE_GPIE_EIAME | IXGBE_GPIE_PBA_SUPPORT |
@@ -1717,80 +1717,86 @@ ixgbe_allocate_msix(struct ix_softc *sc)
{
struct ixgbe_osdep *os = &sc->osdep;
struct pci_attach_args *pa = &os->os_pa;
- int vec, error = 0;
- struct ix_queue *que = sc->queues;
- const char *intrstr = NULL;
- pci_chipset_tag_t pc = pa->pa_pc;
+ int i = 0, error = 0;
+ struct ix_queue *que;
pci_intr_handle_t ih;
- vec = 0;
- if (pci_intr_map_msix(pa, vec, &ih)) {
- printf(": couldn't map interrupt\n");
- return (ENXIO);
- }
+ for (i = 0, que = sc->queues; i < sc->num_queues; i++, que++) {
+ if (pci_intr_map_msix(pa, i, &ih)) {
+ printf("ixgbe_allocate_msix: "
+ "pci_intr_map_msix vec %d failed\n", i);
+ error = ENOMEM;
+ goto fail;
+ }
- que->msix = vec;
- snprintf(que->name, sizeof(que->name), "%s:%d", sc->dev.dv_xname, vec);
+ que->tag = pci_intr_establish_cpu(pa->pa_pc, ih,
+ IPL_NET | IPL_MPSAFE, intrmap_cpu(sc->sc_intrmap, i),
+ ixgbe_queue_intr, que, que->name);
+ if (que->tag == NULL) {
+ printf("ixgbe_allocate_msix: "
+ "pci_intr_establish vec %d failed\n", i);
+ error = ENOMEM;
+ goto fail;
+ }
- intrstr = pci_intr_string(pc, ih);
- que->tag = pci_intr_establish(pc, ih, IPL_NET | IPL_MPSAFE,
- ixgbe_queue_intr, que, que->name);
- if (que->tag == NULL) {
-
