Ah -- I didn't implement the fix I had in that bugzilla correctly -- em and igb devices will use the same function instead of using two different ones even though it seems em devices generally require the interface restart yet igb devices do not. The other issue is that I still don't know which devices need a restart / which devices do not, or whether a restart is strictly necessary and if there is another way to do this without worrying about restarting the device. - Eric On Fri, Nov 6, 2020 at 3:35 PM mike tancsa <mike_at_sentex.net> wrote: > On 11/6/2020 5:32 PM, Eric Joyner wrote: > > Could you reply to that issue with what you've found? > > > > Though, as far as I can recall, igb(4) devices are not supposed to do > > the iflib reset talked about in the bug, so I wouldn't expect to see a > > link flap on those. > > > Hi Eric, > > I have added my findings to > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818 > > I tried it on 3 different vendor's boards. All I210 variants it seems. > > I am testing with > > --- if_em.c 2020-11-06 15:00:22.120953000 -0500 > +++ /tmp/if_em.c 2020-11-06 14:59:55.678195000 -0500 > _at__at_ -4047,6 +4047,7 _at__at_ > { > switch (event) { > case IFLIB_RESTART_VLAN_CONFIG: > + return (false); > default: > return (true); > } > > And if fixes the problem, but not quite sure if it introduces any > regressions or other issues ? > > ---Mike > > > > - Eric > > > > On Fri, Nov 6, 2020 at 12:48 PM mike tancsa <mike_at_sentex.net > > <mailto:mike_at_sentex.net>> wrote: > > > > On 11/6/2020 2:17 PM, mike tancsa wrote: > > > On 5/31/2020 5:39 PM, Lev Serebryakov wrote: > > >> Hello Ian, > > >> > > >> Thursday, May 28, 2020, 2:45:48 AM, you wrote: > > >> > > >>> I noticed that my VLAN interfaces stopped working after a > > recent build. > > >>> tcpdump showed traffic leaving leaving and entering the > > interface but no > > >>> host on the network actually received any packets from this > > host. A > > >>> binary search led me to r360902 and indeed the following > > change fixed > > >>> the issue for me: > > >> Problem is, this change will return terrible situation when > > adding new VLAN > > >> will flap connection status. > > >> > > >> It all worked before iflib: hardware VLAN filtering worked, and > > >> adding/removing new VLAN didn't cause link to flap. > > >> > > >> Now, with iflib, looks like we can not have all good things at > > once :( > > > > > > Looks like this is captured in > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818 > > <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818> > > > > > > > Hi All, > > > > > > Just came across this thread as I am running into this behaviour on > > > RELENG_12. Adding a new vlan causes all vlans on the parent > > interface > > > to flap. Not the greatest thing as it bounces a LOT of traffic > > > potentially, flaps routing etc. Is there a way around this ? > > > > > > This is on r367411 releng12 > > > > > > igb0_at_pci0:2:0:0: class=0x020000 card=0x153315d9 > > chip=0x15338086 > > > rev=0x03 hdr=0x00 > > > vendor = 'Intel Corporation' > > > device = 'I210 Gigabit Network Connection' > > > class = network > > > subclass = ethernet > > > > > > eg. just something simple like > > > > > > ifconfig vlan16 create 10.1.2.3/29 <http://10.1.2.3/29> vlandev > > igb1 vlan 16 > > > > > > # dmesg | tail -8 > > > igb1: link state changed to DOWN > > > vlan16: link state changed to DOWN > > > vlan2049: link state changed to DOWN > > > vlan15: link state changed to DOWN > > > igb1: link state changed to UP > > > vlan16: link state changed to UP > > > vlan2049: link state changed to UP > > > vlan15: link state changed to UP > > > > > > > > > ---Mike > > > > > > > > > > > > > > > _______________________________________________ > > > freebsd-current_at_freebsd.org <mailto:freebsd-current_at_freebsd.org> > > mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > <https://lists.freebsd.org/mailman/listinfo/freebsd-current> > > > To unsubscribe, send any mail to > > "freebsd-current-unsubscribe_at_freebsd.org > > <mailto:freebsd-current-unsubscribe_at_freebsd.org>" > > > > > _______________________________________________ > > freebsd-current_at_freebsd.org <mailto:freebsd-current_at_freebsd.org> > > mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > <https://lists.freebsd.org/mailman/listinfo/freebsd-current> > > To unsubscribe, send any mail to > > "freebsd-current-unsubscribe_at_freebsd.org > > <mailto:freebsd-current-unsubscribe_at_freebsd.org>" > > >Received on Fri Nov 06 2020 - 22:46:21 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:25 UTC