From owner-freebsd-net@freebsd.org Mon Oct 14 15:34:19 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 00DA2FE94F for ; Mon, 14 Oct 2019 15:34:19 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (glebi.us [162.251.186.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 46sMzt3Syzz4VQ1; Mon, 14 Oct 2019 15:34:17 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.15.2/8.15.2) with ESMTPS id x9EFYAE1025219 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 14 Oct 2019 08:34:11 -0700 (PDT) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.15.2/8.15.2/Submit) id x9EFYACh025218; Mon, 14 Oct 2019 08:34:10 -0700 (PDT) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Mon, 14 Oct 2019 08:34:10 -0700 From: Gleb Smirnoff To: d@delphij.net Cc: Mark Johnston , Hans Petter Selasky , Yuri Pankov , freebsd-net , erj@freebsd.org Subject: Re: panic: sleeping in an epoch section Message-ID: <20191014153410.GC4086@FreeBSD.org> References: <86cc5d82-50d0-93eb-5900-54e8b0032a08@yuripv.net> <050ba95e-d0d5-dd1a-db6f-9a5c07142efe@selasky.org> <20191009135616.GC66126@raichu> <20191009144704.GD66126@raichu> <20191009150757.GI1249@FreeBSD.org> <528fec5c-9b36-6f6a-5ba7-3237f56103a1@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <528fec5c-9b36-6f6a-5ba7-3237f56103a1@delphij.net> User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 46sMzt3Syzz4VQ1 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.18 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.18)[-0.179,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:27348, ipnet:162.251.186.0/24, country:US] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2019 15:34:19 -0000 Xin, fixed by r353492 On Sun, Oct 13, 2019 at 11:45:46PM -0700, Xin Li wrote: X> X> X> On 2019-10-09 08:07, Gleb Smirnoff wrote: X> > Yes, I we should allow sleep in ifioctl handlers. So this is my fault, I'll X> > handle it today. X> X> It seems that -CURRENT as of today would panic with: X> X> (kgdb) #0 doadump (textdump=1) at src/sys/amd64/include/pcpu_aux.h:55 X> #1 0xffffffff80bbe550 in kern_reboot (howto=260) X> at /usr/src/sys/kern/kern_shutdown.c:479 X> #2 0xffffffff80bbe9a6 in vpanic (fmt=, X> ap=) at /usr/src/sys/kern/kern_shutdown.c:908 X> #3 0xffffffff80bbe703 in panic (fmt=) X> at /usr/src/sys/kern/kern_shutdown.c:835 X> #4 0xffffffff80e0d1f8 in in6ifa_llaonifp (ifp=) X> at /usr/src/sys/netinet6/in6.c:1554 X> #5 0xffffffff84cb3bcd in lagg_ioctl (ifp=0xfffff80019322000, X> cmd=, data=) X> at /usr/src/sys/net/if_lagg.c:1427 X> #6 0xffffffff80d4c281 in in_control (cmd=2152229261, X> data=0xfffffe00e01fd7d0 "lagg0", ifp=0xfffff80019322000, X> td=0xfffff80019675000) at /usr/src/sys/netinet/in.c:262 X> #7 0xffffffff80ccc6be in ifioctl (so=0xfffff8001c15c710, cmd=2152229261, X> data=0xfffffe00e01fd7d0 "lagg0", td=0xfffff80019675000) X> at /usr/src/sys/net/if.c:3106 X> #8 0xffffffff80c2fc35 in kern_ioctl (td=, X> fd=, com=, X> data=) at src/sys/sys/file.h:340 X> #9 0xffffffff80c2f92c in sys_ioctl (td=0xfffff80019675000, X> uap=0xfffff800196753c8) at /usr/src/sys/kern/sys_generic.c:709 X> #10 0xffffffff8102ee45 in amd64_syscall (td=0xfffff80019675000, traced=0) X> at src/sys/amd64/amd64/../../kern/subr_syscall.c:144 X> #11 0xffffffff810054e0 in fast_syscall_common () X> at /usr/src/sys/amd64/amd64/exception.S:581 X> #12 0x000000080047db8a in ?? () X> Previous frame inner to this frame (corrupt stack?) X> Current language: auto; currently minimal X> X> My configuration is somewhat special: I have a lagg0 (failover) group X> containing em0 and wlan0: X> X> ifconfig_wlan0="WPA" X> ifconfig_em0="ether (ethernet address of wlan0) up" X> cloned_interfaces="lagg0" X> ifconfig_lagg0="laggproto failover laggport em0 laggport wlan0 DHCP" X> ifconfig_lagg0_ipv6="inet6 accept_rtadv" X> X> Without that lagg0 setup, with only wlan0 configured to DHCP and X> accept_rtadv, the system would boot further and network access appears X> to work. X> X> By the way I think there are some recent change (not sure when, but it X> happen since August) to either e1000 or iflib have made the driver to X> expose its e1000_delay state quite a bit when ifconfig or dhclient is X> trying to configure the lagg0 group, when the wired connection is not X> available. X> X> Cheers, X> -- Gleb Smirnoff