I still can’t reproduce that panic.
Does it happen immediately after you start a vnet jail?
Does it also happen with a GENERIC kernel?
Regards,
Kristof
On 20 Nov 2020, at 14:53, Peter Blok wrote:
The panic with ipsec code in the backtrace was already very strange. I
was using IPsec, but only
The panic with ipsec code in the backtrace was already very strange. I was
using IPsec, but only on one interface totally separate from the members of the
bridge as well as the bridge itself. The jails were not doing any ipsec as
well. Note that panic was a while ago and it was after the 1st bri
Can you share your kernel config file (and src.conf / make.conf if they
exist)?
This second panic is in the IPSec code. My current thinking is that your
kernel config is triggering a bug that’s manifesting in multiple
places, but not actually caused by those places.
I’d like to be able to re
Hi Kristof,
This is 12-stable. With the previous bridge epochification that was backed out
my config had a panic too.
I don’t have any local modifications. I did a clean rebuild after removing
/usr/obj/usr
My kernel is custom - I only have zfs.ko, opensolaris.ko, vmm.ko and nmdm.ko as
modules
On 20 Nov 2020, at 11:18, peter.b...@bsd4all.org wrote:
I’m afraid the last Epoch fix for bridge is not solving the problem
( or perhaps creates a new ).
We’re talking about the stable/12 branch, right?
This seems to happen when the jail epair is added to the bridge.
There must be something
Hi,
I’m afraid the last Epoch fix for bridge is not solving the problem ( or
perhaps creates a new ).
This seems to happen when the jail epair is added to the bridge.
Removing both fixes solves the problem.
Peter
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in ke
