Date: Fri, 8 Nov 2019 13:27:30 -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: <781d285f-0b6d-45f1-f4b4-4bab60b789ae@FreeBSD.org> In-Reply-To: <201910291736.x9THa6Gd018030@repo.freebsd.org> References: <201910291736.x9THa6Gd018030@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 -- Renato Botelho
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?781d285f-0b6d-45f1-f4b4-4bab60b789ae>