Bug 222108 - adding bridge interface causes kernel panic
Summary: adding bridge interface causes kernel panic
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: arm (show other bugs)
Version: CURRENT
Hardware: arm64 Any
: --- Affects Some People
Assignee: Sean Bruno
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-09-06 18:34 UTC by Heinz N. Gies
Modified: 2017-11-20 16:11 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Heinz N. Gies 2017-09-06 18:34:34 UTC
Adding a bridge interface as part of the rc.conf causes a kernel panic on startup:

bridge0: Ethernet address: 02:a1:f3:11:3d:00
Created clon: bridge0.
Kernel page fault with the following non-sleepable locks held:
exclusive sleep mutex em0 (iflib ctx lock) r = 0 (0xfffffd00041f2d40) locked @ /usr/src/sys/net/iflib.c:3873
stack backtrace:
#0 0xffff00000036d390 at witness_debugger+0x64
#1 0xffff00000036e6a0 at witness_warn+0x3fc
#2 0xffff0000005fcb3c at data_abort+0xe0
#3 0xffff0000005fc968 at do_el1h_sync+0xfc
#4 0xffff0000005e5874 at handle_el1h_sync+0x74
#5 0xffff00000040e9e0 at _iflib_fl_refill+0x370
#6 0xffff00000040e9e0 at _iflib_fl_refill+0x370
#7 0xffff00000040a770 at iflib_init_locked+0x3e0
#8 0xffff00000040f490 at iflib_if_ioctl+0x698
#9 0xffff0000464abcdc at bridge_set_ifcap+0x78
#10 0xffff0000464abc08 at bridge_mutecaps+0xcc
#11 0xffff0000464a840c at bridge_ioctl_add+0x40c
#12 0xffff0000464a9ca0 at bridge_ioctl+0x174
#13 0xffff0000003f64e4 at ifioctl+0xf14
#14 0xffff000000372d28 at kern_ioctl+0x358
#15 0xffff000000372980 at sys_ioctl+0x158
#16 0xffff0000005fd548 at do_el0_sync+0x898
#17 0xffff0000005e59f4 at handle_el0_sync+0x74
  x0: fffffd000434ce00
  x1: fffffd0004155200
  x2:                1
  x3:                0
  x4:                0
  x5:                0
  x6:                0
  x7: ffff00062365942c
  x8:               10
  x9: ffff0000005e2524
 x10:        100000000
 x11: ffff000000a949d8
 x12:                1
 x13: fffffd00041f2d40
 x14: ffff000040687e80
 x15: ffff00000085a078
 x16:         dc318819
 x17:         9f8f3c75
 x18: ffff0006236593f0
 x19: deadc0dedeadc0de
 x20: fffffd0004155200
 x21: fffffd000434ce00
 x22:                0
 x23:                1
 x24:                0
 x25: fffffd001b319800
 x26:                0
 x27: ffff0000419ea000
 x28:                0
 x29: ffff000623659460
  sp: ffff0006236593f0
  lr: ffff00000040e9e4
 elr: ffff0000005e2584
spsr:         80000345
 far: deadc0dedeadc10e
 esr:         96000004
panic: data abort in critical section or under mutex
cpuid = 1
time = 1504643393
KDB: stack backtrace:
db_trace_self() at db_trace_self_wrapper+0x28
	 pc = 0xffff0000005e3ab8  lr = 0xffff000000087228
	 sp = 0xffff000623658e10  fp = 0xffff000623659020

db_trace_self_wrapper() at vpanic+0x184
	 pc = 0xffff000000087228  lr = 0xffff00000030fd84
	 sp = 0xffff000623659030  fp = 0xffff0006236590b0

vpanic() at panic+0x44
	 pc = 0xffff00000030fd84  lr = 0xffff00000030fe0c
	 sp = 0xffff0006236590c0  fp = 0xffff000623659140

panic() at data_abort+0x250
	 pc = 0xffff00000030fe0c  lr = 0xffff0000005fccac
	 sp = 0xffff000623659150  fp = 0xffff000623659200

data_abort() at do_el1h_sync+0xfc
	 pc = 0xffff0000005fccac  lr = 0xffff0000005fc968
	 sp = 0xffff000623659210  fp = 0xffff000623659240

do_el1h_sync() at handle_el1h_sync+0x74
	 pc = 0xffff0000005fc968  lr = 0xffff0000005e5874
	 sp = 0xffff000623659250  fp = 0xffff000623659360

handle_el1h_sync() at _iflib_fl_refill+0x370
	 pc = 0xffff0000005e5874  lr = 0xffff00000040e9e0
	 sp = 0xffff000623659370  fp = 0xffff000623659460

_iflib_fl_refill() at _iflib_fl_refill+0x370
	 pc = 0xffff00000040e9e0  lr = 0xffff00000040e9e0
	 sp = 0xffff000623659470  fp = 0xffff000623659530

_iflib_fl_refill() at iflib_init_locked+0x3e0
	 pc = 0xffff00000040e9e0  lr = 0xffff00000040a770
	 sp = 0xffff000623659540  fp = 0xffff0006236595a0

iflib_init_locked() at iflib_if_ioctl+0x698
	 pc = 0xffff00000040a770  lr = 0xffff00000040f490
	 sp = 0xffff0006236595b0  fp = 0xffff000623659600

iflib_if_ioctl() at bridge_set_ifcap+0x78
	 pc = 0xffff00000040f490  lr = 0xffff0000464abcdc
	 sp = 0xffff000623659610  fp = 0xffff000623659660

bridge_set_ifcap() at bridge_mutecaps+0xcc
	 pc = 0xffff0000464abcdc  lr = 0xffff0000464abc08
	 sp = 0xffff000623659670  fp = 0xffff0006236596b0

bridge_mutecaps() at bridge_ioctl_add+0x40c
	 pc = 0xffff0000464abc08  lr = 0xffff0000464a840c
	 sp = 0xffff0006236596c0  fp = 0xffff000623659700

bridge_ioctl_add() at bridge_ioctl+0x174
	 pc = 0xffff0000464a840c  lr = 0xffff0000464a9ca0
	 sp = 0xffff000623659710  fp = 0xffff0006236597b0

bridge_ioctl() at ifioctl+0xf14
	 pc = 0xffff0000464a9ca0  lr = 0xffff0000003f64e4
	 sp = 0xffff0006236597c0  fp = 0xffff000623659860

ifioctl() at kern_ioctl+0x358
	 pc = 0xffff0000003f64e4  lr = 0xffff000000372d28
	 sp = 0xffff000623659870  fp = 0xffff0006236598c0

kern_ioctl() at sys_ioctl+0x158
	 pc = 0xffff000000372d28  lr = 0xffff000000372980
	 sp = 0xffff0006236598d0  fp = 0xffff0006236599a0

sys_ioctl() at do_el0_sync+0x898
	 pc = 0xffff000000372980  lr = 0xffff0000005fd548
	 sp = 0xffff0006236599b0  fp = 0xffff000623659a70

do_el0_sync() at handle_el0_sync+0x74
	 pc = 0xffff0000005fd548  lr = 0xffff0000005e59f4
	 sp = 0xffff000623659a80  fp = 0xffff000623659b90

handle_el0_sync() at 0x38e60
	 pc = 0xffff0000005e59f4  lr = 0x0000000000038e60
	 sp = 0xffff000623659ba0  fp = 0x0000ffffffffe470

KDB: enter: panic
Comment 1 Heinz N. Gies 2017-10-10 13:42:08 UTC
I noticed the following, this only happens when VNET is enabled in the kernel. If it's not enabled bridges work w/ panicking.
Comment 2 Ed Maste freebsd_committer 2017-11-17 15:32:41 UTC
bz@ and I have been working on the 2 socket ThunderX systems at packet.net and have found a similar type of panic when creating a lagg interface, iff the kernel is built with VNET.