Hi,
Cleanup the error handling in ipsec ipip_output() and consistently
goto drop instead of return. This will help to refactor counter
and add tdb refcounting. An ENOBUFS should be EINVAL in IPv6 case.
Also use combined packet and byte counter.
ok?
bluhm
Index: netinet/ip_ipip.c
Hi,
On my way to tdb refcounting, I would like to setting ipsec mtu in
a function.
The NULL and invalid check in ipsec_common_ctlinput() is not
necessary, the loop in ipsec_set_mtu() does that anyway.
udpencap_ctlinput() did not work for bundled SA, this also needs
the loop in ipsec_set_mtu().
> Date: Mon, 4 Oct 2021 22:03:32 +0200
> From: Rafael Sadowski
>
> On Sun Sep 26, 2021 at 02:36:02PM +0200, Mark Kettenis wrote:
> > > Date: Fri, 24 Sep 2021 19:36:21 +0200
> > > From: Rafael Sadowski
> > >
> > > I'm trying to port the more KDE stuff so my question is from porter
> > >
On Sun Sep 26, 2021 at 02:36:02PM +0200, Mark Kettenis wrote:
> > Date: Fri, 24 Sep 2021 19:36:21 +0200
> > From: Rafael Sadowski
> >
> > I'm trying to port the more KDE stuff so my question is from porter
> > perspective.
> >
> > I need sigwaitinfo(2)/sigtimedwait(2) and I found both functions
On Sun 03/10/2021 22:49, Stefan Sperling wrote:
> While working on 40MHz support for iwm(4) I noticed that throughput
> dropped from 200 Mbit/s to about 2 Mbit/s whenever the laptop roamed
> between APs. Sometimes traffic even stalled completely.
> The patch below fixes this problem for me.
$
On Sat, Oct 02, 2021 at 03:23:57PM -0700, Chris Cappuccio wrote:
> Hrvoje Popovski [hrv...@srce.hr] wrote:
> >
> > box didn't panic, just stopped forwarding traffic through tunnel.
>
> any chance any progress has been made here? is there any newer versions
> of these diffs floating around?
Main
On Fri, Oct 01, 2021 at 08:10:35PM +0200, Martin Pieuchot wrote:
> Diff below turns i386's pmap_collect() into a noop like it is on
> amd64/arm64/powerpc64... This is part of the UVM unlocking diff and
> might no longer be necessary now that pmap_extract() has been fixed.
>
> So I'd like to know
> Date: Mon, 4 Oct 2021 13:42:48 +
> From: Visa Hankala
>
> On the Zynq-7000, the lowest 512KiB of physical address space usually
> contains RAM that is usable by the CPUs. However, many other bus
> masters, such as the Ethernet and SDIO controllers, are not able to
> access the 256KiB range
Am Mon, Oct 04, 2021 at 01:42:48PM + schrieb Visa Hankala:
> On the Zynq-7000, the lowest 512KiB of physical address space usually
> contains RAM that is usable by the CPUs. However, many other bus
> masters, such as the Ethernet and SDIO controllers, are not able to
> access the 256KiB range
On the Zynq-7000, the lowest 512KiB of physical address space usually
contains RAM that is usable by the CPUs. However, many other bus
masters, such as the Ethernet and SDIO controllers, are not able to
access the 256KiB range that starts at physical address 0x4.
So far I have used a device
On Mon, Oct 04, 2021 at 10:45:06AM +0200, Florian Obser wrote:
>
> This works as advertised on:
>
> iwm0 at pci1 dev 0 function 0 "Intel Dual Band Wireless-AC 9260" rev 0x29,
> msix
> iwm0: hw rev 0x320, fw ver 46.6b541b68.0, address 40:74:e0:38:11:11
>
> and
>
> iwm0 at pci2 dev 0 function 0
This works as advertised on:
iwm0 at pci1 dev 0 function 0 "Intel Dual Band Wireless-AC 9260" rev 0x29, msix
iwm0: hw rev 0x320, fw ver 46.6b541b68.0, address 40:74:e0:38:11:11
and
iwm0 at pci2 dev 0 function 0 "Intel AC 7260" rev 0x83, msi
iwm0: hw rev 0x140, fw ver 17.3216344376.0, address
12 matches
Mail list logo
