Bug #846
closed
if_bridge triggers link state cycling on em(4)
0%
Description
This is primarily a reminder to figure out more about this and report it upstream. Another question arises here - should check_reload_status do anything when IP is "none"? It skips the process when it's static IP, and hence this is not a problem with static.
To replicate, bridge two em(4) interfaces with at least one set to IP "none", and the link state will go up and down every 30 seconds roughly. The ifconfig output, the NIC's link light, and the NIC link of the connected device all show the link going down and up repeatedly.
em0: <Intel(R) PRO/1000 Network Connection 7.0.5> port 0xdc00-0xdc1f mem 0xfeae0000-0xfeafffff,0xfeadc000-0xfeadffff irq 16 at device 0.0 on pci4 em0: Using MSIX interrupts with 5 vectors
# ifconfig em0
em0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=2098<VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC>
ether 00:90:0b:12:01:66
inet6 fe80::290:bff:fe12:166%em0 prefixlen 64 scopeid 0x1
nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
media: Ethernet autoselect
status: no carrier
# ifconfig em0
em0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=2098<VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC>
ether 00:90:0b:12:01:66
inet6 fe80::290:bff:fe12:166%em0 prefixlen 64 scopeid 0x1
nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
Aug 25 01:48:27 hamakua kernel: em0: link state changed to DOWN Aug 25 01:48:29 hamakua kernel: em0: link state changed to UP Aug 25 01:48:58 hamakua php: : The command '/sbin/ifconfig bridge1 addm em0' returned exit code '1', the output was 'ifconfig: BRDGADD em0: File exists' Aug 25 01:48:58 hamakua kernel: em0: link state changed to DOWN Aug 25 01:49:00 hamakua kernel: em0: link state changed to UP Aug 25 01:49:29 hamakua php: : The command '/sbin/ifconfig bridge1 addm em0' returned exit code '1', the output was 'ifconfig: BRDGADD em0: File exists' Aug 25 01:49:29 hamakua kernel: em0: link state changed to DOWN Aug 25 01:49:31 hamakua kernel: em0: link state changed to UP Aug 25 01:50:00 hamakua php: : The command '/sbin/ifconfig bridge1 addm em0' returned exit code '1', the output was 'ifconfig: BRDGADD em0: File exists' Aug 25 01:50:00 hamakua kernel: em0: link state changed to DOWN Aug 25 01:50:02 hamakua kernel: em0: link state changed to UP Aug 25 01:50:31 hamakua php: : The command '/sbin/ifconfig bridge1 addm em0' returned exit code '1', the output was 'ifconfig: BRDGADD em0: File exists' Aug 25 01:50:31 hamakua kernel: em0: link state changed to DOWN Aug 25 01:50:33 hamakua kernel: em0: link state changed to UP Aug 25 01:51:02 hamakua php: : The command '/sbin/ifconfig bridge1 addm em0' returned exit code '1', the output was 'ifconfig: BRDGADD em0: File exists' Aug 25 01:51:02 hamakua kernel: em0: link state changed to DOWN Aug 25 01:51:04 hamakua kernel: em0: link state changed to UP
This appears to be the issue described by Andrew Thompson here:
http://www.mail-archive.com/freebsd-stable@freebsd.org/msg87816.html
though back on 6.2. Seems to have regressed back to that in 8.1.
It appears disabling hardware checksum offloading fixes this problem, or works around it at least.
Updated by Ermal Luçi about 14 years ago
This should be retested with the latest drivers in 2.0.
Otherwise mostly this is a bug of em(4) ioctl handling of SETCAPs.
Updated by
Updated by Ermal Luçi about 14 years ago
It is just that on some enable/disable of capabilities the em(4) needs to reinit itself(according to code).
Updated by Ermal Luçi almost 14 years ago
I will close this if no more input comes.
This is only related to how if_bridge works, while it is questionable why all members should have all settings the same as far as hw capabilities are concerned it needs testing and investigation for fixing this from if_bridge point of view.
Otherwise this is em(4) driver issue and not related to bridge.