Date: Mon, 20 Aug 2018 17:44:35 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 230510] iflib/vlan panic: sleeping thread Message-ID: <bug-230510-7501-d97qDqNniD@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-230510-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-230510-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230510 --- Comment #3 from Harald Schmalzbauer <bugzilla.freebsd@omnilan.de> --- Kudos! No more LORs and the described problem is solved with D16808 against r33809= 3. But vlan(4) doesn't work as expected. I have to reduce MTU to 1468 on the vlan(4) device to get frames passed out. I haven't really checked much, since there were some offloading changes recently and I'm not sure if if_valn(4) is known to be under rework/broken. I have if_em(4) (I217-V) as parent device. For the moment I haven't disabled any offloading feature, so the interfaces involved read like this: em0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 9000 options=3D81249b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LRO,WOL_= MAGIC,VLAN_HWFILTER> ether 56:be:f7:0b:d7:4e hwaddr=20 inet 192.0.2.1 netmask 0xffffff00 broadcast 192.0.2.255=20 inet6 2001:db8:1::3:1 prefixlen 64=20 inet6 fe80::54be:f7ff:fe0b:d74e%em0 prefixlen 64 scopeid 0x1=20 media: Ethernet autoselect (1000baseT <full-duplex>) status: active nd6 options=3D21<PERFORMNUD,AUTO_LINKLOCAL> vlegn: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 14= 68 options=3D403<RXCSUM,TXCSUM,LRO> ether 56:be:f7:0b:d7:4e inet 169.254.0.1 netmask 0xffffff00 broadcast 169.254.0.255=20 inet6 2001:db8:2::3:2 prefixlen 64=20 inet6 fe80::54be:f7ff:fe0b:d74e%vlegn prefixlen 64 scopeid 0x3=20 groups: vlan=20 vlan: 1234 vlanpcp: 0 parent interface: em0 media: Ethernet autoselect (1000baseT <full-duplex>) status: active nd6 options=3D21<PERFORMNUD,AUTO_LINKLOCAL> Usually vlegn (if_vlan(4) child of em0) should work with the inherited MTU = of 9000 Shall I file a different PR? And test with different offloading scenarios before doing so? Thanks, -harry --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-230510-7501-d97qDqNniD>