ahci(4): Add support for JMicron JMB585 chipset

I have two devices here based on the JMicron JMB585 chipset. This diff adds the required pcidev IDs and sets disables native command queuing in the driver. FreeBSD does something similar for this device: https://github.com/freebsd/freebsd-src/commit/16b766eed443043f4216d50e40ba283e74f992c2 I've t

Re: ix(4)/riscv64: Make ix(4) work when MSI-X interrupts aren't available

Jonathan Matthew writes: > Yes, on second look that makes sense. Here's a better diff with that > change, and that also doesn't break arches without __HAVE_PCI_MSIX. > ok? Jonathan/Mark, Thank you for your help here. Just confirming that does indeed work for me. Any chance the other part of

Re: systat(1) counter overflow

Hi, just a quick update. After about two weeks, various counters have exceeded the 32 bit int limit, and haven't wrapped. There might eventually be some issues with the field width but that will take a long time to reach. Regards, Anindya On Sat, Jul 03, 2021 at 11:20:42AM +0100, Stuart Henderson

ipsec(4): use per-CPU counters for tunnel descriptor block (tdb) statistics

This makes 'tdb' struct more MP compliant. 'tdb_data' struct became unused and was removed. Index: sys/net/pfkeyv2_convert.c === RCS file: /cvs/src/sys/net/pfkeyv2_convert.c,v retrieving revision 1.72 diff -u -p -r1.72 pfkeyv2_convert

Re: unwind(8): WIP support using a custom CA

Florian Obser wrote: > I'm not a fan and I'm not personally interested in the functionality. > > I'd suggest getting a certificate from a recognized CA or add your CA to > /etc/ssl/cert.pem if it's trustworthy enough. > > Removing the unveil(2) call shows that you don't understand what that > do

Re: forwarding in parallel ipsec workaround

On 22.7.2021. 22:52, Vitaliy Makkoveev wrote: > On Thu, Jul 22, 2021 at 08:38:04PM +0200, Hrvoje Popovski wrote: >> On 22.7.2021. 12:21, Hrvoje Popovski wrote: >>> Thank you for explanation.. >>> >>> after hitting box all night, box panic and i was able to reproduce it >>> this morning ... I'm not

Re: forwarding in parallel ipsec workaround

On Thu, Jul 22, 2021 at 08:38:04PM +0200, Hrvoje Popovski wrote: > On 22.7.2021. 12:21, Hrvoje Popovski wrote: > > Thank you for explanation.. > > > > after hitting box all night, box panic and i was able to reproduce it > > this morning ... I'm not sure but box panic after hour or more of > > sen

snmpd(8): fix trapv2 on correct protocol detection

This type-O snuck in when merging traphandler into snmpe. Not a big deal since it's there just for ASN1/SMI strictness, but it breaks when introducing SNMPv3 support. OK? martijn@ Index: snmpe.c === RCS file: /cvs/src/usr.sbin/snmpd

snmpd(8): set smi_applicatoin in usm_decrypt

Not an issue with read requests, but will set requests if they contain snmp application elements such as timeticks. Definitely needed for upcoming SNMPv3 trap support. OK? martijn@ Index: usm.c === RCS file: /cvs/src/usr.sbin/snmpd

libutil/ber: add ober_dup(3)

I'm currently working on adding SNMPv3 support to traps in snmpd(8). For sending traps we loop over sc_trapreceivers and can send each trap to 0 or more receivers. I want to high-jack snmpe_response() to do the heavy lifting for doing the snmp/usm encoding, but this interface frees the varbindlist

Re: forwarding in parallel ipsec workaround

On 22.7.2021. 12:21, Hrvoje Popovski wrote: > Thank you for explanation.. > > after hitting box all night, box panic and i was able to reproduce it > this morning ... I'm not sure but box panic after hour or more of > sending traffic through iked tunnel .. > I will try to reproduce it through ipse

Fix: tcp_output window calculation error

Hi, This calculation of the receive window has a logic error: If win is 0 it will be overwritten by (rcv_adv - rcv_nxt). Thus, win will be (rcv_adv - rcv_nxt) even if its below (sb_hiwat / 4). We could just remove the dead (sb_hiwat / 4) code, or reorder the conditions to keep the original feat

Re: unwind(8): WIP support using a custom CA

On 2021-07-22 13:25 UTC, Lucas wrote: > Updated patch. It now: > > - Allows using a custom CA > - Reconfigure DoT resolvers' config when just the CA changed (previous > version only impacted CA changes when there were also resolvers > changes) > > Have been running it without problems so far,

Re: forwarding in parallel ipsec workaround

On Thu, Jul 22, 2021 at 12:21:47PM +0200, Hrvoje Popovski wrote: > On 22.7.2021. 0:39, Alexander Bluhm wrote: > > On Thu, Jul 22, 2021 at 12:06:09AM +0200, Hrvoje Popovski wrote: > >> I'm combining this and last parallel diff and i can't see any drops in > >> traffic. Even sending at high rate, tra

Re: unwind(8): WIP support using a custom CA

Updated patch. It now: - Allows using a custom CA - Reconfigure DoT resolvers' config when just the CA changed (previous version only impacted CA changes when there were also resolvers changes) Have been running it without problems so far, and it seemed to work in the early boot process too.

Re: forwarding in parallel ipsec workaround

On 22.7.2021. 0:39, Alexander Bluhm wrote: > On Thu, Jul 22, 2021 at 12:06:09AM +0200, Hrvoje Popovski wrote: >> I'm combining this and last parallel diff and i can't see any drops in >> traffic. Even sending at high rate, traffic through iked or isakmpd is >> stable at 150Kpps, which is good .. >