Date: Sun, 13 Oct 2019 23:45:46 -0700 From: Xin Li <delphij@delphij.net> To: Gleb Smirnoff <glebius@freebsd.org>, Mark Johnston <markj@freebsd.org> Cc: Hans Petter Selasky <hps@selasky.org>, Yuri Pankov <yuripv@yuripv.net>, freebsd-net <freebsd-net@freebsd.org>, erj@freebsd.org Subject: Re: panic: sleeping in an epoch section Message-ID: <528fec5c-9b36-6f6a-5ba7-3237f56103a1@delphij.net> In-Reply-To: <20191009150757.GI1249@FreeBSD.org> References: <86cc5d82-50d0-93eb-5900-54e8b0032a08@yuripv.net> <050ba95e-d0d5-dd1a-db6f-9a5c07142efe@selasky.org> <20191009135616.GC66126@raichu> <a2075acc-243c-da14-180e-686eaf59cfd6@selasky.org> <20191009144704.GD66126@raichu> <20191009150757.GI1249@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--zwucuWf6vqUBnH6is2eCISz6n2J9M63Ix
Content-Type: multipart/mixed; boundary="T3FT6OuZ8jsjs4c596j8vX0cL62NgO190";
protected-headers="v1"
From: Xin Li <delphij@delphij.net>
Reply-To: d@delphij.net
To: Gleb Smirnoff <glebius@freebsd.org>, Mark Johnston <markj@freebsd.org>
Cc: Hans Petter Selasky <hps@selasky.org>, Yuri Pankov <yuripv@yuripv.net>,
freebsd-net <freebsd-net@freebsd.org>, erj@freebsd.org
Message-ID: <528fec5c-9b36-6f6a-5ba7-3237f56103a1@delphij.net>
Subject: Re: panic: sleeping in an epoch section
References: <86cc5d82-50d0-93eb-5900-54e8b0032a08@yuripv.net>
<050ba95e-d0d5-dd1a-db6f-9a5c07142efe@selasky.org>
<20191009135616.GC66126@raichu>
<a2075acc-243c-da14-180e-686eaf59cfd6@selasky.org>
<20191009144704.GD66126@raichu> <20191009150757.GI1249@FreeBSD.org>
In-Reply-To: <20191009150757.GI1249@FreeBSD.org>
--T3FT6OuZ8jsjs4c596j8vX0cL62NgO190
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
On 2019-10-09 08:07, Gleb Smirnoff wrote:
> Yes, I we should allow sleep in ifioctl handlers. So this is my fault, =
I'll
> handle it today.
It seems that -CURRENT as of today would panic with:
(kgdb) #0 doadump (textdump=3D1) at src/sys/amd64/include/pcpu_aux.h:55
#1 0xffffffff80bbe550 in kern_reboot (howto=3D260)
at /usr/src/sys/kern/kern_shutdown.c:479
#2 0xffffffff80bbe9a6 in vpanic (fmt=3D<value optimized out>,
ap=3D<value optimized out>) at /usr/src/sys/kern/kern_shutdown.c:908
#3 0xffffffff80bbe703 in panic (fmt=3D<value optimized out>)
at /usr/src/sys/kern/kern_shutdown.c:835
#4 0xffffffff80e0d1f8 in in6ifa_llaonifp (ifp=3D<value optimized out>)
at /usr/src/sys/netinet6/in6.c:1554
#5 0xffffffff84cb3bcd in lagg_ioctl (ifp=3D0xfffff80019322000,
cmd=3D<value optimized out>, data=3D<value optimized out>)
at /usr/src/sys/net/if_lagg.c:1427
#6 0xffffffff80d4c281 in in_control (cmd=3D2152229261,
data=3D0xfffffe00e01fd7d0 "lagg0", ifp=3D0xfffff80019322000,
td=3D0xfffff80019675000) at /usr/src/sys/netinet/in.c:262
#7 0xffffffff80ccc6be in ifioctl (so=3D0xfffff8001c15c710, cmd=3D2152229=
261,
data=3D0xfffffe00e01fd7d0 "lagg0", td=3D0xfffff80019675000)
at /usr/src/sys/net/if.c:3106
#8 0xffffffff80c2fc35 in kern_ioctl (td=3D<value optimized out>,
fd=3D<value optimized out>, com=3D<value optimized out>,
data=3D<value optimized out>) at src/sys/sys/file.h:340
#9 0xffffffff80c2f92c in sys_ioctl (td=3D0xfffff80019675000,
uap=3D0xfffff800196753c8) at /usr/src/sys/kern/sys_generic.c:709
#10 0xffffffff8102ee45 in amd64_syscall (td=3D0xfffff80019675000, traced=3D=
0)
at src/sys/amd64/amd64/../../kern/subr_syscall.c:144
#11 0xffffffff810054e0 in fast_syscall_common ()
at /usr/src/sys/amd64/amd64/exception.S:581
#12 0x000000080047db8a in ?? ()
Previous frame inner to this frame (corrupt stack?)
Current language: auto; currently minimal
My configuration is somewhat special: I have a lagg0 (failover) group
containing em0 and wlan0:
ifconfig_wlan0=3D"WPA"
ifconfig_em0=3D"ether (ethernet address of wlan0) up"
cloned_interfaces=3D"lagg0"
ifconfig_lagg0=3D"laggproto failover laggport em0 laggport wlan0 DHCP"
ifconfig_lagg0_ipv6=3D"inet6 accept_rtadv"
Without that lagg0 setup, with only wlan0 configured to DHCP and
accept_rtadv, the system would boot further and network access appears
to work.
By the way I think there are some recent change (not sure when, but it
happen since August) to either e1000 or iflib have made the driver to
expose its e1000_delay state quite a bit when ifconfig or dhclient is
trying to configure the lagg0 group, when the wired connection is not
available.
Cheers,
--T3FT6OuZ8jsjs4c596j8vX0cL62NgO190--
--zwucuWf6vqUBnH6is2eCISz6n2J9M63Ix
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.2.17 (FreeBSD)
iQIzBAEBCgAdFiEEceNg5NEMZIki80nQQHl/fJX0g08FAl2kGZ8ACgkQQHl/fJX0
g09JQBAAl8/R9vqqW4ivRVcKzJapE6gnqbLIDorMxJa6MNQhdpWPWG3X2yH/9gNg
j8SSR96VI3fJs9REzLABBV1x29w8BdTcuOhiwRr6azUdBwxCugL47G8QUldypnEg
ltp7WpqORL4Oz95K7c4L1bpDmoWQwvRy7nxHHvgn0UOYVA2XBADGhRXSZRQM/rdN
Nc4ma3SYwk3lPCT3IMVkJhk3qeodjtQ6h3XJzeIqN/FCTvLnBVo9eIVwE2M/fjK8
DJpgg/7IyRA9qbOC9l5dGD7Vpz02dy0UR9VwWmgHLExi9Hju+bu8Ae+UeX/Zmt63
ON8X11nfn+GIi0BvPGVUTyCjpxaPgEoOI6tgG8Vv06CJVxVrF/tgTKhLqWTycsKf
8+n6jgWG18ChvcnB6Zaac5c8VJtCZFL890TT+Pdp4IRP99+TtPWUmLN1ULT/VLK7
BCo+EGq+GCkKPt3cgXcceocgZsU19Q7wvMXQ5OhO6sI+AHoRw7Q9Ewlazb0XfMdS
1XJ0FWZcBjZuTMPrzUNqVu8HwSPSc2ke0foW/JqhnCuM+DigIpeOhLq3l3UXgIvm
okmfmydFixy4QK2o8ZMlQM0+9IKlgd+oSnPkYWyav7srEJkUeLtHJEDTFuJ8fytC
fQaLmOkqAhJVrTJgvcqnEoVldjll28+XTNsNzFRitZI60y11+7Y=
=MVoX
-----END PGP SIGNATURE-----
--zwucuWf6vqUBnH6is2eCISz6n2J9M63Ix--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?528fec5c-9b36-6f6a-5ba7-3237f56103a1>