On 04/27/2016 03:47 PM, Laszlo Fekete wrote:
>
> [ 211.955239] i40e 0000:04:00.0 enp4s0f0: speed changed to 0 for port
> enp4s0f0
>
> [ 211.956912] bond0: link status up again after 0 ms for interface
> enp4s0f0
>
Hi,
I can not reproduce your problem because I have no i40e device.
But from the following dmesg message.
"
...
[ 211.955239] i40e 0000:04:00.0 enp4s0f0: speed changed to 0 for port
enp4s0f0
[ 211.956912] bond0: link status up again after 0 ms for interface enp4s0f0
...
"
I think the i40e nic is up while the speed remain 0. IMHO, your problem
is similar to mine.
I think this problem only occurs with 802.3ad. Am I correct?
If so, I think the latest bonding driver should fix this problem.
You can try these patches:
1.
commit 266b495f11d6706018f66250cb02a788ff2490d7
Author: Jay Vosburgh <jay.vosbu...@canonical.com>
Date: Mon Feb 8 12:10:02 2016 -0800
bonding: don't use stale speed and duplex information
There is presently a race condition between the bonding periodic
link monitor and the updating of a slave's speed and duplex. The former
occurs on a periodic basis, and the latter in response to a driver's
calling of netif_carrier_on.
It is possible for the periodic monitor to run between the
driver call of netif_carrier_on and the receipt of the NETDEV_CHANGE
event that causes bonding to update the slave's speed and duplex. This
manifests most notably as a report that a slave is up and "0 Mbps full
duplex" after enslavement, but in principle could report an incorrect
speed and duplex after any link up event if the device comes up with a
different speed or duplex. This affects the 802.3ad aggregator
selection, as the speed and duplex are selection criteria.
This is fixed by updating the speed and duplex in the periodic
monitor, prior to using that information.
This was done historically in bonding, but the call to
bond_update_speed_duplex was removed in commit 876254ae2758 ("bonding:
don't call update_speed_duplex() under spinlocks"), as it might sleep
under lock. Later, the locking was changed to only hold RTNL, and so
after commit 876254ae2758 ("bonding: don't call update_speed_duplex()
under spinlocks") this call is again safe.
Tested-by: "Tantilov, Emil S" <emil.s.tanti...@intel.com>
Cc: Veaceslav Falico <vfal...@gmail.com>
Cc: dingtianhong <dingtianh...@huawei.com>
Fixes: 876254ae2758 ("bonding: don't call update_speed_duplex()
under spinlocks")
Signed-off-by: Jay Vosburgh <jay.vosbu...@canonical.com>
Acked-by: Ding Tianhong <dingtianh...@huawei.com>
Signed-off-by: David S. Miller <da...@davemloft.net>
2. the patches for ixgbe drivers. You can use them in i40e driver.
commit 0e4d422f5f7249324ac8d1b8e12772e530787a66
Author: Emil Tantilov <emil.s.tanti...@intel.com>
Date: Thu Dec 3 15:20:06 2015 -0800
ixgbe: do not call check_link for ethtool in ixgbe_get_settings()
In ixgbe_get_settings() the link status and speed of the interface
are determined based on a read from the LINKS register via the call
to mac.ops.check.link(). This can cause issues where external drivers
may end up with unknown speed when calling ethtool_get_setings().
Instead of calling the mac.ops.check_link() we can report the speed
from the adapter structure which is populated by the driver.
Signed-off-by: Emil Tantilov <emil.s.tanti...@intel.com>
Tested-by: Phil Schmitt <phillip.j.schm...@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirs...@intel.com>
3. The patch in the link is applied for ixgbe nic driver. You can try it
in i40e nic.
http://patchwork.ozlabs.org/patch/561848/
All the patches are applied in bonding and i40e. I think this problem
should be resolved.
In the end, add emil.s.tanti...@intel.com and jay.vosbu...@canonical.com.
Please let me know the test result.
Thanks a lot.
Zhu Yanjun
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit
http://communities.intel.com/community/wired
