On Tue, Dec 06, 2022 at 11:33:06PM +0300, Vitaliy Makkoveev wrote:
> On Tue, Dec 06, 2022 at 07:56:13PM +0100, Paul de Weerd wrote:
> > I was playing with the USB NIC that's in my (USB-C) monitor. As soon
> > as I do traffic over the interface, I get a kernel panic:
> >
> > panic: kernel
Hi Vitaliy,
Thanks - this fixes the panic for me.
Paul
On Tue, Dec 06, 2022 at 11:33:06PM +0300, Vitaliy Makkoveev wrote:
| On Tue, Dec 06, 2022 at 07:56:13PM +0100, Paul de Weerd wrote:
| > I was playing with the USB NIC that's in my (USB-C) monitor. As soon
| > as I do traffic over the
On Tue, Dec 06, 2022 at 11:33:06PM +0300, Vitaliy Makkoveev wrote:
> On Tue, Dec 06, 2022 at 07:56:13PM +0100, Paul de Weerd wrote:
> > I was playing with the USB NIC that's in my (USB-C) monitor. As soon
> > as I do traffic over the interface, I get a kernel panic:
> >
> > panic: kernel
On Tue, Dec 06, 2022 at 07:56:13PM +0100, Paul de Weerd wrote:
> I was playing with the USB NIC that's in my (USB-C) monitor. As soon
> as I do traffic over the interface, I get a kernel panic:
>
> panic: kernel diagnostic assertion "timo || _kernel_lock_held()" failed: file
>
I was playing with the USB NIC that's in my (USB-C) monitor. As soon
as I do traffic over the interface, I get a kernel panic:
panic: kernel diagnostic assertion "timo || _kernel_lock_held()" failed: file
"/usr/src/sys/kern/kern_synch.c", line 127
This is the hostname.if(5) file for ure0:
---
On 6 Dec 2022, at 18:20, Mike Larkin wrote:
> As dv@ pointed out in a previous mail, the eptviolation exit message can
> be ignored (and as he points out, should probably be removed or
[...]
> packets. You could experiment with raising that (it's in
> src/usr.sbin/vmd/virtio.h) to a higher power
On Tue, Dec 06, 2022 at 11:02:51AM +0100, Arrigo Triulzi wrote:
> >Synopsis:VMM vcpu_exit_eptviolation and repeated vionet_enq_rx buffer
> >issues
> >Category:system amd64
> >Environment:
> System : OpenBSD 7.2
> Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24
On 6 Dec 2022, at 14:59, Dave Voutila wrote:
> The functional changes between releases include driving more vm exits to
> be handled by vmd and not vmm in the kernel. vmd is already quite
> chatty, so it's time to revisit which messages add value.
>
> vcpu_ext_eptviolation sounds more ominous
