Kristof,
It’s from the 2nd situation. It is so weird. Last time there was ipsec code in
the backtrace, which wasn’t used on the bridge+members.
This is from my own kernel config, but during testing with the GENERIC kernel I
had similar backtraces at reboot.
I can’t do a lot right now, but I’m
Peter,
Is that backtrace from the first or the second situation you describe?
What kernel config are you using with that backtrace?
This backtrace does not appear to involve the bridge. Given that part of
the panic message is cut off it’s very hard to conclude anything at
all from it.
Best
Kristof,
With commit 367705+367706 and if_bridge statically linked. It crashes while
adding an epair of a jail.
With commit 367705+367706 and if_bridge dynamically loaded there is a crash at
reboot
#0 0x8069ddc5 at kdb_backtrace+0x65
#1 0x80652c8b at vpanic+0x17b
#2 0x8
Kristof,
With a GENERIC kernel it does NOT happen. I do have a different iflib related
panic at reboot, but I’ll report that separately.
I brought the two config files closer together and found out that if I remove
if_bridge from the config file and have it loaded dynamically when the bridge
i
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
10 matches
Mail list logo
