Date: Fri, 8 Nov 2019 14:18:57 -0300 From: Renato Botelho <garga@FreeBSD.org> To: Gleb Smirnoff <glebius@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r354149 - head/sys/net Message-ID: <abde9de1-84f8-c34f-ff36-34908d263db4@FreeBSD.org> In-Reply-To: <781d285f-0b6d-45f1-f4b4-4bab60b789ae@FreeBSD.org> References: <201910291736.x9THa6Gd018030@repo.freebsd.org> <781d285f-0b6d-45f1-f4b4-4bab60b789ae@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 08/11/19 13:27, Renato Botelho wrote: > On 29/10/19 14:36, Gleb Smirnoff wrote: >> Author: glebius >> Date: Tue Oct 29 17:36:06 2019 >> New Revision: 354149 >> URL: https://svnweb.freebsd.org/changeset/base/354149 >> >> Log: >> There is a long standing problem with multicast programming for NICs >> and IPv6. With IPv6 we may call if_addmulti() in context of processing >> of an incoming packet. Usually this is interrupt context. While most >> of the NIC drivers are able to reprogram multicast filters without >> sleeping, some of them can't. An example is e1000 family of drivers. >> With iflib conversion the problem was somewhat hidden. Iflib processes >> packets in private taskqueue, so going to sleep doesn't trigger an >> assertion. However, the sleep would block operation of the driver and >> following incoming packets would fill the ring and eventually would >> start being dropped. Enabling epoch for the full time of a packet >> processing again started to trigger assertions for e1000. >> >> Fix this problem once and for all using a general taskqueue to call >> if_ioctl() method in all cases when if_addmulti() is called in a >> non sleeping context. Note that nobody cares about returned value. >> >> Reviewed by: hselasky, kib >> Differential Revision: https://reviews.freebsd.org/D22154 > > Hi Gleb, > > I upgraded my laptop running 13-CURRENT from r354133 to r354437 and it > crashed during boot as you can see in the pictures [1]. It seems like > it crashed while it was configuring network. > > After bisect I managed to boot fine with r354148 and reproduce the crash > with this revision applied. > > Here is the relevant portion of my /etc/rc.conf: > > # Lagg > ifconfig_em0="up" > wlans_iwn0="wlan0" > ifconfig_wlan0="WPA" > create_args_wlan0="wlanaddr 3c:97:0e:48:3f:f8 up" > cloned_interfaces="lagg0" > ifconfig_lagg0="up laggproto failover laggport em0 laggport wlan0 DHCP" > ifconfig_lagg0_ipv6="inet6 accept_rtadv" > rtsold_enable="YES" > > [1] https://imgur.com/a/lBtq3FW I forgot to mention. If I disable IPv6 on lagg interface the crash is gone. -- Renato Botelho
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?abde9de1-84f8-c34f-ff36-34908d263db4>