Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 20 Oct 2018 11:15:03 +0000
From:      bugzilla-noreply@freebsd.org
To:        net@FreeBSD.org
Subject:   [Bug 232362] if_lagg(4)+if_vlan(4) panic: sleeping in an epoch section (igb, e1000_82575, actiall 82576 in use)
Message-ID:  <bug-232362-7501-GOBL4UZB4L@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-232362-7501@https.bugs.freebsd.org/bugzilla/>
References:  <bug-232362-7501@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D232362

--- Comment #2 from Harald Schmalzbauer <bugzilla.freebsd@omnilan.de> ---
The problem seems to be iflib/igb specific, I guess.
Using if_lagg(4) as parent with one USB ethernet (axge(4)/ue) port doesn't
crash the system!
Manually configuring a if_vlan(4) child on a if_lagg(4) parent with a if_ig=
b(4)
port also leads to a panic, like when rc(8) is doing it.  I tested with i210
and 82576.

Here's the i210 backtrace:
panic: sleeping in an epoch section
cpuid =3D 2
time =3D 1539941673
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffffff819e2=
360
vpanic() at vpanic+0x1a3/frame 0xffffffff819e23c0
panic() at panic+0x43/frame 0xffffffff819e2420
_sleep() at _sleep+0x456/frame 0xffffffff819e24c0
pause_sbt() at pause_sbt+0x11f/frame 0xffffffff819e2500
e1000_reset_hw_82580() at e1000_reset_hw_82580+0x1d6/frame 0xffffffff819e25=
40
em_if_stop() at em_if_stop+0x1b/frame 0xffffffff819e2560
iflib_stop() at iflib_stop+0xb1/frame 0xffffffff819e25b0
iflib_vlan_register() at iflib_vlan_register+0xad/frame 0xffffffff819e25f0
lagg_register_vlan() at lagg_register_vlan+0xda/frame 0xffffffff819e2650
vlan_config() at vlan_config+0x51e/frame 0xffffffff819e26b0
vlan_ioctl() at vlan_ioctl+0x32e/frame 0xffffffff819e2710
ifhwioctl() at ifhwioctl+0x20e/frame 0xffffffff819e2790
ifioctl() at ifioctl+0x757/frame 0xffffffff819e2850
kern_ioctl() at kern_ioctl+0x2ba/frame 0xffffffff819e28b0
sys_ioctl() at sys_ioctl+0x16a/frame 0xffffffff819e2980
amd64_syscall() at amd64_syscall+0x28c/frame 0xffffffff819e2ab0
fast_syscall_common() at fast_syscall_common+0x101/frame 0xffffffff819e2ab0
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip =3D 0x800485f6a, rsp =3D
0x7fffffffe0e8, rbp =3D 0x7fffffffe120 ---
KDB: enter: panic
#5  0xffffffff807b7aa3 in kdb_trap (type=3D3, code=3D0, tf=3D<value optimiz=
ed out>)
    at /usr/local/share/deploy-tools/HEAD/src/sys/kern/subr_kdb.c:693
#6  0xffffffff80adef00 in trap (frame=3D0xffffffff819e2290) at
/usr/local/share/deploy-tools/HEAD/src/sys/amd64/amd64/trap.c:619
#7  0xffffffff80ab8915 in calltrap () at
/usr/local/share/deploy-tools/HEAD/src/sys/amd64/amd64/exception.S:232
#8  0xffffffff807b717b in kdb_enter (why=3D0xffffffff80c25469 "panic", msg=
=3D<value
optimized out>) at cpufunc.h:65
#9  0xffffffff80770670 in vpanic (fmt=3D<value optimized out>,
ap=3D0xffffffff819e2400)
    at /usr/local/share/deploy-tools/HEAD/src/sys/kern/kern_shutdown.c:861
#10 0xffffffff80770413 in panic (fmt=3D<value optimized out>)
    at /usr/local/share/deploy-tools/HEAD/src/sys/kern/kern_shutdown.c:799
#11 0xffffffff8077b256 in _sleep (ident=3D0xffffffff81101762, lock=3D0x0,
priority=3D0, wmesg=3D0xc5 <Address 0xc5 out of bounds>,=20
    sbt=3D<value optimized out>, pr=3D-2136234978, flags=3D256) at
/usr/local/share/deploy-tools/HEAD/src/sys/kern/kern_synch.c:150
#12 0xffffffff8077b65f in pause_sbt (wmesg=3D<value optimized out>, sbt=3D4=
2949670,
pr=3D<value optimized out>,=20
    flags=3D<value optimized out>) at
/usr/local/share/deploy-tools/HEAD/src/sys/kern/kern_synch.c:332
#13 0xffffffff80558516 in e1000_reset_hw_82580 (hw=3D0xffffffff81b84008) at
e1000_osdep.h:97
#14 0xffffffff8054014b in em_if_stop (ctx=3D<value optimized out>)
    at /usr/local/share/deploy-tools/HEAD/src/sys/dev/e1000/if_em.c:1842
#15 0xffffffff80896b01 in iflib_stop (ctx=3D0xfffff80002b52c00) at ifdi_if.=
h:268
#16 0xffffffff808a41ad in iflib_vlan_register (arg=3D0xfffff80002b52c00,
ifp=3D0xfffff80002a9e000, vtag=3D232)
    at /usr/local/share/deploy-tools/HEAD/src/sys/net/iflib.c:3949
#17 0xffffffff8088a7ea in lagg_register_vlan (arg=3D<value optimized out>,
ifp=3D<value optimized out>, vtag=3D<value optimized out>)
    at /usr/local/share/deploy-tools/HEAD/src/sys/net/if_lagg.c:451
#18 0xffffffff8089600e in vlan_config (ifv=3D0xfffff800150f4180,
p=3D0xfffff80002a25000, vid=3D<value optimized out>)
    at /usr/local/share/deploy-tools/HEAD/src/sys/net/if_vlan.c:1439
#19 0xffffffff8089579e in vlan_ioctl (ifp=3D<value optimized out>, cmd=3D<v=
alue
optimized out>, data=3D0xffffffff819e28d0 "lagg1egn")
    at /usr/local/share/deploy-tools/HEAD/src/sys/net/if_vlan.c:1828
#20 0xffffffff8087640e in ifhwioctl (cmd=3D2149607737, ifp=3D<value optimiz=
ed out>,
data=3D0xffffffff819e28d0 "lagg1egn",=20
    td=3D0xfffff80015496000) at
/usr/local/share/deploy-tools/HEAD/src/sys/net/if.c:2861
#21 0xffffffff808782a7 in ifioctl (so=3D0xfffff8001580ca38, cmd=3D214960773=
7,
data=3D<value optimized out>, td=3D0xfffff80015496000)
    at /usr/local/share/deploy-tools/HEAD/src/sys/net/if.c:3081
#22 0xffffffff807dc82a in kern_ioctl (td=3D0xfffff80015496000, fd=3D3, com=
=3D<value
optimized out>, data=3D<value optimized out>)
    at file.h:330
#23 0xffffffff807dc4ea in sys_ioctl (td=3D0xfffff80015496000,
uap=3D0xfffff800154963c0)
---Type <return> to continue, or q <return> to quit---
    at /usr/local/share/deploy-tools/HEAD/src/sys/kern/sys_generic.c:712
#24 0xffffffff80adfd7c in amd64_syscall (td=3D0xfffff80015496000, traced=3D=
0) at
subr_syscall.c:135
#25 0xffffffff80ab91fd in fast_syscall_common () at
/usr/local/share/deploy-tools/HEAD/src/sys/amd64/amd64/exception.S:504
#26 0x0000000800485f6a in ?? ()

I don't think this will be fixable with a one liner...
Can somebody with more knowledge estimate when this can be fixed? Hopefully
before 12.0-RELEASE?
I don't have any other NICs available for testing, like bnxt(4), which is a=
lso
iflib based.  Can somebody with mlx4en(4) or cxgb(4) check? I guess these a=
re
non-iflib based NICs.

Thanks,
-harry

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-232362-7501-GOBL4UZB4L>