There is a problem in the ixgbe driver with the reporting of the flow
control
parameters. The autoneg parameter is shown to be of if *either* it really
is
off, or current modes for both tx and rx are off.
The problem is seen when the parameters are read or set when the link is
down.
In this case, the driver sees that tx and rx are currently off and
therefore
autoneg parameter is incorrectly reported to be off too. Also, the ethtool
binary can not set the autoneg off since it sees that it already is. When a
link later comes up, the autonegotiation is carried out normally and the
driver later on reports the autoneg parameter to be on (as it is) and then
it
can also be changed with ethtool.
The patch is made against v3.0 kernel, but the problem seems to be there
since
v2.6.30-rc1.
Reviewer comments: What we are trying to do is to disable flow control
while
the cable is disconnected. Since ixgbe defaults to full flow control, we
call
ethtool -A autoneg off rx off tx off while the cable is disconnected. This
doesn't work, because the driver sets hw->fc.current_mode = ixgbe_fc_none
if
the cable is unplugged. ixgbe_get_pauseparam() then reports to ethtool that
nothing needs to be done. The code fixes this, but it might have some
unknown
consequences.
Signed-off-by: Mika Lansirinne <mika.lansiri...@stonesoft.com>
Reviewed-by: Esa-Pekka Pyokkimies <esa-pekka.pyokkim...@stonesoft.com>
---
diff --git a/drivers/net/ixgbe/ixgbe_ethtool.c
b/drivers/net/ixgbe/ixgbe_ethtool.c
index 82d4244..db27c24 100644
--- a/drivers/net/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ixgbe/ixgbe_ethtool.c
@@ -368,13 +368,7 @@ static void ixgbe_get_pauseparam(struct net_device
*netdev,
struct ixgbe_adapter *adapter = netdev_priv(netdev);
struct ixgbe_hw *hw = &adapter->hw;
- /*
- * Flow Control Autoneg isn't on if
- * - we didn't ask for it OR
- * - it failed, we know this by tx & rx being off
- */
- if (hw->fc.disable_fc_autoneg ||
- (hw->fc.current_mode == ixgbe_fc_none))
+ if (hw->fc.disable_fc_autoneg)
pause->autoneg = 0;
else
pause->autoneg = 1;
------------------------------------------------------------------------------
Doing More with Less: The Next Generation Virtual Desktop
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops? How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
_______________________________________________
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
