On 2023-05-20 19:37 +02, Paul de Weerd wrote:
> On Sat, May 20, 2023 at 05:33:11PM +0200, Florian Obser wrote:
> | In case this turns out to be useful for unlocking work in the kernel.
> |
> | It's a minimum diff, if we want to go this way we probably want to move
> | init_soiikey() to the engine
On Sat, May 20, 2023 at 05:33:11PM +0200, Florian Obser wrote:
| In case this turns out to be useful for unlocking work in the kernel.
|
| It's a minimum diff, if we want to go this way we probably want to move
| init_soiikey() to the engine process and stop bouncing through the main
| process whe
In case this turns out to be useful for unlocking work in the kernel.
It's a minimum diff, if we want to go this way we probably want to move
init_soiikey() to the engine process and stop bouncing through the main
process when an interface changes.
This changes behaviour: in -current we can chang
Hi,
with help from Aaron Mason, I have found the problem responsible for the
vioscsi panic on oracle cloud and windows qemu. Basically before using any
virt-queues, the guest must set the DRIVER_OK status bit, or the host may
not process the queues. This affects vioscsi(4) and viogpu(4) in open
On Fri, May 19, 2023 at 07:58:47PM +0200, Jan Klemkow wrote:
> Hi,
>
> We use the wrong interface and mtu in tcp_mss() to calculate the mss if
> the destination address points is a local address. In ip_output() we
> use the correct interface and its mtu.
>
> This limits the mss to 1448 if the mt
