Re: timeout.9: document kclock timeouts + a bunch of other changes

On Thu, Jun 24, 2021 at 05:39:56PM -0500, Scott Cheloha wrote: > On Thu, Jun 24, 2021 at 06:51:07AM +0100, Jason McIntyre wrote: > > On Wed, Jun 23, 2021 at 06:57:00PM -0500, Scott Cheloha wrote: > > > Hi, > > > > > > I want to document kclock timeouts so others can use them. > > > > morning.

Re: [External] : Re: if_etherbridge.c vs. parallel forwarding

On Thu, Jun 24, 2021 at 09:31:20AM +0200, Alexandr Nedvedicky wrote: > Hello David, > > > > > > i think we can get away with not refcounting eb_entry structures at all. > > either they're in the etherbridge map/table or they're not, and the > > thing that takes them out of the map while holding

Re: [please test] amd64: schedule clock interrupts against system clock

On Thu, Jun 24, 2021 at 09:50:07PM -0500, Scott Cheloha wrote: > > [...] > > Stats for the clockintr subsystem are exposed via sysctl(2). If > you're interested in providing them you can compile and run the > program attached inline in my next mail. A snippet of the output from > across a

[please test] amd64: schedule clock interrupts against system clock

Hi, I'm looking for testers for the attached patch. You need an amd64 machine with a lapic. This includes: - All "real" amd64 machines ever made - amd64 VMs running on hypervisors that provide a virtual lapic Note that this does *not* include: - amd64 VMs running on OpenBSD's vmm(4). (I

Re: timeout.9: document kclock timeouts + a bunch of other changes

On Thu, Jun 24, 2021 at 06:51:07AM +0100, Jason McIntyre wrote: > On Wed, Jun 23, 2021 at 06:57:00PM -0500, Scott Cheloha wrote: > > Hi, > > > > I want to document kclock timeouts so others can use them. > > morning. reads fine, except one issue: > > [...] > > > +.Bl -tag -width kclock > >

OpenSMTPD: status set incorrectly on envelope expiration + fix

Our OpenSMTPD daemon sent us the following confusing message: A message is delayed for more than 0 seconds for the following list of recipients: b...@gus.test: Envelope expired The enclosed patch will fix the issue permanently. Sincerely, Erik Index: usr.sbin/smtpd/queue.c

Re: bgpd refactor network flush code a bit

Claudio Jeker(cje...@diehard.n-r-g.com) on 2021.06.24 17:06:36 +0200: > The network flush code only operates on peerself (like all the other > network commands). Instead of passing a peer to the tree walker just > default to peerself in network_flush_upcall(). > This makes the code more obivous

Re: bgpd shuffle some code around

ok Claudio Jeker(cje...@diehard.n-r-g.com) on 2021.06.24 17:03:58 +0200: > In rde_update_dispatch() do the AFI check for IPv4 prefixes before > extracting the prefix. This is similar to what the MP code does and > is also more logical. > > OK? > -- > :wq Claudio > > Index: rde.c >

Re: bgpd fix add-path capability encoding

Claudio Jeker(cje...@diehard.n-r-g.com) on 2021.06.22 19:47:04 +0200: > Dumb copy paste error. The add-path capability is 4byte per AFI/SAFI > the 2 + is from graceful restart where two extra bytes are at the front of > the AFI/SAFI list. ok. > > -- > :wq Claudio > > Index: session.c >

SiFive Unmatched if_cad fix

Hello, On the risc-v SiFive Unmatched the internal cad0 ethernet interface stops working randomly after some packets are sent/received. It looks like it's because the bus_dmamap used isn't restricted to lower than 4GB physical addresses, and the interface itself is. Configuring the interface

Whitespace diff for sys/arch/amd64/amd64/identcpu.c

Found these while tinkering with my CPU scaling issue the other day. Two instances of trailing white-space. Index: sys/arch/amd64/amd64/identcpu.c === RCS file: /cvs/src/sys/arch/amd64/amd64/identcpu.c,v retrieving revision 1.118

OpenBSD Errata: June 25, 2021 (bgpd)

An errata patch for the bgpd routing daemon has been released for OpenBSD 6.9. During bgpd(8) config reloads prefixes of the wrong address family could leak to peers resulting in session resets. Binary updates for the amd64, i386, and arm64 platform are available via the syspatch utility. Source

bgpd refactor network flush code a bit

The network flush code only operates on peerself (like all the other network commands). Instead of passing a peer to the tree walker just default to peerself in network_flush_upcall(). This makes the code more obivous that it operates on peerself. -- :wq Claudio Index: rde.c

bgpd shuffle some code around

In rde_update_dispatch() do the AFI check for IPv4 prefixes before extracting the prefix. This is similar to what the MP code does and is also more logical. OK? -- :wq Claudio Index: rde.c === RCS file:

Re: bgpd fix bad free() call when deflating aspath

On Tue, Jun 22, 2021 at 08:19:22PM +0200, Claudio Jeker wrote: > I changed the way up_generate_attr() calls aspath_deflate() but did not > realize that aspath_deflate() frees the pdata at the end. That free should > no longer happen but for that also the mrt case where aspath_deflate() > needs to

Re: Bad comparison between double and uint64_t

Hi Ali, From: Ali Farzanrad Date: Thu, 24 Jun 2021 07:25:24 + > Hi Masato, > > Masato Asou wrote: >> Hi Ali, >> >> In this case, ULLONG_MAX is implicitly cast to double, isn't it? > > Yes it is implicitly cast to double, but due to floating point number > precision, ULLONG_MAX will

Re: [External] : Re: if_etherbridge.c vs. parallel forwarding

Hello David, > > i think we can get away with not refcounting eb_entry structures at all. > either they're in the etherbridge map/table or they're not, and the > thing that takes them out of the map while holding the eb_lock mutex > becomes responsible for their cleanup. > > i feel like most

Re: Bad comparison between double and uint64_t

Hi Masato, Masato Asou wrote: > Hi Ali, > > In this case, ULLONG_MAX is implicitly cast to double, isn't it? Yes it is implicitly cast to double, but due to floating point number precision, ULLONG_MAX will convert to (ULLONG_MAX + 1). So in case val is really ULLONG_MAX + 1, this condition is