Re: uhidpp(4): logitech hid++ device driver

Hi, On Mon, Feb 08, 2021 at 02:50:39PM -0800, Anindya Mukherjee wrote: > Hi, I have a Logitech M570 which seems to be handled by this new driver. > However I don't see any battery level information. > > dmesg: > uhidpp0 at uhidev4 device 1 mouse "M570" serial ef-81-ff-80 > > sysctl kern.version:

iked(8): roadwarrior client support

This diff adds support for automatic installation of virtual IPs and routes for iked roadwarrior clients. Requesting addresses from the peer has been supported for some time now but is by itself pretty useless. This change adds a new 'iface' config option to specify an interface on which the addre

Re: uhidpp(4): logitech hid++ device driver

Hi, I have a Logitech M570 which seems to be handled by this new driver. However I don't see any battery level information. dmesg: uhidpp0 at uhidev4 device 1 mouse "M570" serial ef-81-ff-80 sysctl kern.version: kern.version=OpenBSD 6.8-current (GENERIC.MP) #313: Fri Feb 5 18:31:44 MST 2021

Mention cvschroot in anoncvs.html

Hi, My usual mirror died apparently. stsp kindly pointed out the cvschroot in cvsutils package to switch to a new mirror. Here's a diff to add this where I looked at how to do it. Comments? OK? Index: anoncvs.html === RCS file: /cv

Re: diff: tcp ack improvement

On Mon, Feb 08, 2021 at 03:42:54PM +0100, Alexander Bluhm wrote: > On Wed, Feb 03, 2021 at 11:20:04AM +0100, Claudio Jeker wrote: > > Just commit it. OK claudio@ > > If people see problems we can back it out again. > > This has huge impact on TCP performance. > > http://bluhm.genua.de/perform/res

Re: diff: tcp ack improvement

Claudio Jeker wrote: > On Mon, Feb 08, 2021 at 07:46:46PM +0100, Alexander Bluhm wrote: > > On Mon, Feb 08, 2021 at 07:03:59PM +0100, Jan Klemkow wrote: > > > On Mon, Feb 08, 2021 at 03:42:54PM +0100, Alexander Bluhm wrote: > > > > On Wed, Feb 03, 2021 at 11:20:04AM +0100, Claudio Jeker wrote: >

Re: diff: tcp ack improvement

On Mon, Feb 08, 2021 at 07:46:46PM +0100, Alexander Bluhm wrote: > On Mon, Feb 08, 2021 at 07:03:59PM +0100, Jan Klemkow wrote: > > On Mon, Feb 08, 2021 at 03:42:54PM +0100, Alexander Bluhm wrote: > > > On Wed, Feb 03, 2021 at 11:20:04AM +0100, Claudio Jeker wrote: > > > > Just commit it. OK claudi

Re: diff: tcp ack improvement

On Mon, Feb 08, 2021 at 07:03:59PM +0100, Jan Klemkow wrote: > On Mon, Feb 08, 2021 at 03:42:54PM +0100, Alexander Bluhm wrote: > > On Wed, Feb 03, 2021 at 11:20:04AM +0100, Claudio Jeker wrote: > > > Just commit it. OK claudio@ > > > If people see problems we can back it out again. > > > > This h

change rpki-client repository code

Split the repository code into two parts: - fetch of the trust anchors (the certs referenced by TAL files) - fetch of the MFT files of a repository While the two things kind of look similar there are some differences. - TA files are loaded via rsync or https URI (only one file needs to be load

Re: diff: tcp ack improvement

Yes it is unacceptable. Alexander Bluhm wrote: > On Wed, Feb 03, 2021 at 11:20:04AM +0100, Claudio Jeker wrote: > > Just commit it. OK claudio@ > > If people see problems we can back it out again. > > This has huge impact on TCP performance. > > http://bluhm.genua.de/perform/results/2021-02-07

Re: diff: tcp ack improvement

On Wed, Feb 03, 2021 at 11:20:04AM +0100, Claudio Jeker wrote: > Just commit it. OK claudio@ > If people see problems we can back it out again. This has huge impact on TCP performance. http://bluhm.genua.de/perform/results/2021-02-07T00%3A01%3A40Z/perform.html For a single TCP connection between

stricter bioctl -c option parsing

bioctl(8) only looks at the first character of the -c option argument and ignores any trailing characters in the argument. Following the addition of the RAID1C discipline this behaviour can lead to confusion. This command with a typo ("C1" vs "1C") attempts to create a CRYPTO volume: # bioctl -cC

Re: some Ryzen, AMD 500 Chipset, Navi 10 and Kingson pcidev

Hi, thanks for your fast response. I've chosen "AMD 17_3X_IOMMU" instead of "Starship/Matisse" because in my point of view, also the other Ryzen Zen 2 pci devices were named 17_3x (e.g. PCI_PRODUCT_AMD_17_3X_RC 0x1480 /* 17h/3xh Root Complex */) Maybe I'm wrong, but we should choose the same

Re: some Ryzen, AMD 500 Chipset, Navi 10 and Kingson pcidev

On 2021/02/08 10:54, Jonathan Gray wrote: > On Sun, Feb 07, 2021 at 07:58:52PM +0100, Sven Wolf wrote: > > Hi, > > > > I've added some Ryzen 3xxx, AMD 500 Chipset, Navi 10 and Kingston ids to > > pcidev. I've taken the description from the Linux PCI device ids > > https://pci-ids.ucw.cz/v2.2/pci.i