Project

General

Profile

Bug #846

if_bridge triggers link state cycling on em(4)

Added by Chris Buechler over 8 years ago. Updated about 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Operating System
Target version:
Start date:
08/25/2010
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.0
Affected Architecture:

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.

Associated revisions

Revision 69695597 (diff)
Added by Ermal Luçi over 8 years ago

Ticket #846. Do not reconfigure an 'none' configured interface.

Revision 7413cbfd (diff)
Added by Ermal Luçi over 8 years ago

Ticket #846. Do not try to add an interface to the bridge during an event of LINK_UP.

History

#1 Updated by Ermal Luçi over 8 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.

#2 Updated by Chris Buechler over 8 years ago

no change with latest em(4) driver

#3 Updated by Ermal Luçi over 8 years ago

It is just that on some enable/disable of capabilities the em(4) needs to reinit itself(according to code).

#4 Updated by Ermal Luçi over 8 years ago

  • Status changed from New to Feedback

#5 Updated by Ermal Luçi over 8 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.

#6 Updated by Ermal Luçi about 8 years ago

  • Status changed from Feedback to Closed

Also available in: Atom PDF