From: Holger Schurig <holgerschurig@gmail.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [BUG] igb: reconnecting of cable not always detected
Date: Thu, 26 Apr 2018 09:54:27 +0200 [thread overview]
Message-ID: <8736zio11o.fsf@gmail.com> (raw)
In-Reply-To: <CAKgT0UdTf5pf53==hB71Ba_N1gJ-TH_3uMajozr1wykLEbK80g@mail.gmail.com>
> Was the orange LED on the igb NIC or on the TL SG-108? Based on the
> comment below I am assuming it is the switch.
The LEDs were on the switch.
When everything works, the switch says green == 1000 MB/s.
When cable is disconnected, switch doesn't light any LED.
When cable is inserted and things fail, the switch says orange LED == 100 MB/s.
Sometimes the insertion process works, then the switch will go, of
course, to the green LED == 1000 MB/s.
I must admit that I didn't look at the LEDs of the device.
Now I looked there, and the device the left+green LED is on. In the
failed case (so, in the dmesg output the last thing I see is "Link is
Down", but the device still has left+green LED on.
The right+orange LED on the device seems to indicate traffic, and it is
constantly off in the failed case.
> I assume you mean "ethtool -r" since that is what is supposed to be
> restarting negotiation. The "ethtool -i" is what you provided above.
Maybe I've edited my text too much and moved output along. Anyway, in
the failed case neither "ethtool- r eth0" nor "ethtool -i eth0" nor
"mii-tool eth0" work at all, they all emit error warning.
> Thanks. I'm suspecting we may need to instrument igb_rd32 at this
> point. In order to trigger what you are seeing I am assuming the
> device has been detached due to a read failure of some sort.
I'll do that and reply later. I first need to understand this source
part :-)
> Another thing you could look at doing is narrowing down the possible
> factors involved. You could go through and limit phy settings and look
> at possibly dropping features such as EEE if it is enabled on the
> device.
I actually tried a driver patch to remove 1000 GB/s from the driver, in
the assumption that maybe this specific hardware has a bad layout and
thus trouble (I don't really think that, because I never observed any
data transfer problem).
So, is the following patch (that didn't help) what in the line of what
you suggested?
Index: linux-4.16/drivers/net/ethernet/intel/igb/igb_main.c
===================================================================
--- linux-4.16.orig/drivers/net/ethernet/intel/igb/igb_main.c 2018-04-01 23:20:27.000000000 +0200
+++ linux-4.16/drivers/net/ethernet/intel/igb/igb_main.c 2018-04-24 11:35:17.420760650 +0200
@@ -2080,7 +2080,7 @@
if ((adapter->flags & IGB_FLAG_EEE) &&
(!hw->dev_spec._82575.eee_disable))
- adapter->eee_advert = MDIO_EEE_100TX | MDIO_EEE_1000T;
+ adapter->eee_advert = MDIO_EEE_100TX /* | MDIO_EEE_1000T */;
return 0;
}
@@ -2908,7 +2908,7 @@
/* Initialize link properties that are user-changeable */
adapter->fc_autoneg = true;
hw->mac.autoneg = true;
- hw->phy.autoneg_advertised = 0x2f;
+ hw->phy.autoneg_advertised = 0x0f;
hw->fc.requested_mode = e1000_fc_default;
hw->fc.current_mode = e1000_fc_default;
@@ -3099,7 +3099,7 @@
if ((!err) &&
(!hw->dev_spec._82575.eee_disable)) {
adapter->eee_advert =
- MDIO_EEE_100TX | MDIO_EEE_1000T;
+ MDIO_EEE_100TX /* | MDIO_EEE_1000T */;
adapter->flags |= IGB_FLAG_EEE;
}
break;
@@ -3110,7 +3110,7 @@
if ((!err) &&
(!hw->dev_spec._82575.eee_disable)) {
adapter->eee_advert =
- MDIO_EEE_100TX | MDIO_EEE_1000T;
+ MDIO_EEE_100TX /* | MDIO_EEE_1000T */;
adapter->flags |= IGB_FLAG_EEE;
}
}
Index: linux-4.16/drivers/net/ethernet/intel/igb/igb_ethtool.c
===================================================================
--- linux-4.16.orig/drivers/net/ethernet/intel/igb/igb_ethtool.c 2018-04-01 23:20:27.000000000 +0200
+++ linux-4.16/drivers/net/ethernet/intel/igb/igb_ethtool.c 2018-04-24 11:42:36.737959749 +0200
@@ -170,7 +170,7 @@
SUPPORTED_10baseT_Full |
SUPPORTED_100baseT_Half |
SUPPORTED_100baseT_Full |
- SUPPORTED_1000baseT_Full|
+ /* SUPPORTED_1000baseT_Full| */
SUPPORTED_Autoneg |
SUPPORTED_TP |
SUPPORTED_Pause);
@@ -3003,7 +3003,7 @@
(hw->phy.media_type != e1000_media_type_copper))
return -EOPNOTSUPP;
- edata->supported = (SUPPORTED_1000baseT_Full |
+ edata->supported = (/* SUPPORTED_1000baseT_Full | */
SUPPORTED_100baseT_Full);
if (!hw->dev_spec._82575.eee_disable)
edata->advertised =
WARNING: multiple messages have this Message-ID (diff)
From: Holger Schurig <holgerschurig@gmail.com>
To: Alexander Duyck <alexander.duyck@gmail.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
intel-wired-lan <intel-wired-lan@lists.osuosl.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [BUG] igb: reconnecting of cable not always detected
Date: Thu, 26 Apr 2018 09:54:27 +0200 [thread overview]
Message-ID: <8736zio11o.fsf@gmail.com> (raw)
In-Reply-To: <CAKgT0UdTf5pf53==hB71Ba_N1gJ-TH_3uMajozr1wykLEbK80g@mail.gmail.com>
> Was the orange LED on the igb NIC or on the TL SG-108? Based on the
> comment below I am assuming it is the switch.
The LEDs were on the switch.
When everything works, the switch says green == 1000 MB/s.
When cable is disconnected, switch doesn't light any LED.
When cable is inserted and things fail, the switch says orange LED == 100 MB/s.
Sometimes the insertion process works, then the switch will go, of
course, to the green LED == 1000 MB/s.
I must admit that I didn't look at the LEDs of the device.
Now I looked there, and the device the left+green LED is on. In the
failed case (so, in the dmesg output the last thing I see is "Link is
Down", but the device still has left+green LED on.
The right+orange LED on the device seems to indicate traffic, and it is
constantly off in the failed case.
> I assume you mean "ethtool -r" since that is what is supposed to be
> restarting negotiation. The "ethtool -i" is what you provided above.
Maybe I've edited my text too much and moved output along. Anyway, in
the failed case neither "ethtool- r eth0" nor "ethtool -i eth0" nor
"mii-tool eth0" work at all, they all emit error warning.
> Thanks. I'm suspecting we may need to instrument igb_rd32 at this
> point. In order to trigger what you are seeing I am assuming the
> device has been detached due to a read failure of some sort.
I'll do that and reply later. I first need to understand this source
part :-)
> Another thing you could look at doing is narrowing down the possible
> factors involved. You could go through and limit phy settings and look
> at possibly dropping features such as EEE if it is enabled on the
> device.
I actually tried a driver patch to remove 1000 GB/s from the driver, in
the assumption that maybe this specific hardware has a bad layout and
thus trouble (I don't really think that, because I never observed any
data transfer problem).
So, is the following patch (that didn't help) what in the line of what
you suggested?
Index: linux-4.16/drivers/net/ethernet/intel/igb/igb_main.c
===================================================================
--- linux-4.16.orig/drivers/net/ethernet/intel/igb/igb_main.c 2018-04-01 23:20:27.000000000 +0200
+++ linux-4.16/drivers/net/ethernet/intel/igb/igb_main.c 2018-04-24 11:35:17.420760650 +0200
@@ -2080,7 +2080,7 @@
if ((adapter->flags & IGB_FLAG_EEE) &&
(!hw->dev_spec._82575.eee_disable))
- adapter->eee_advert = MDIO_EEE_100TX | MDIO_EEE_1000T;
+ adapter->eee_advert = MDIO_EEE_100TX /* | MDIO_EEE_1000T */;
return 0;
}
@@ -2908,7 +2908,7 @@
/* Initialize link properties that are user-changeable */
adapter->fc_autoneg = true;
hw->mac.autoneg = true;
- hw->phy.autoneg_advertised = 0x2f;
+ hw->phy.autoneg_advertised = 0x0f;
hw->fc.requested_mode = e1000_fc_default;
hw->fc.current_mode = e1000_fc_default;
@@ -3099,7 +3099,7 @@
if ((!err) &&
(!hw->dev_spec._82575.eee_disable)) {
adapter->eee_advert =
- MDIO_EEE_100TX | MDIO_EEE_1000T;
+ MDIO_EEE_100TX /* | MDIO_EEE_1000T */;
adapter->flags |= IGB_FLAG_EEE;
}
break;
@@ -3110,7 +3110,7 @@
if ((!err) &&
(!hw->dev_spec._82575.eee_disable)) {
adapter->eee_advert =
- MDIO_EEE_100TX | MDIO_EEE_1000T;
+ MDIO_EEE_100TX /* | MDIO_EEE_1000T */;
adapter->flags |= IGB_FLAG_EEE;
}
}
Index: linux-4.16/drivers/net/ethernet/intel/igb/igb_ethtool.c
===================================================================
--- linux-4.16.orig/drivers/net/ethernet/intel/igb/igb_ethtool.c 2018-04-01 23:20:27.000000000 +0200
+++ linux-4.16/drivers/net/ethernet/intel/igb/igb_ethtool.c 2018-04-24 11:42:36.737959749 +0200
@@ -170,7 +170,7 @@
SUPPORTED_10baseT_Full |
SUPPORTED_100baseT_Half |
SUPPORTED_100baseT_Full |
- SUPPORTED_1000baseT_Full|
+ /* SUPPORTED_1000baseT_Full| */
SUPPORTED_Autoneg |
SUPPORTED_TP |
SUPPORTED_Pause);
@@ -3003,7 +3003,7 @@
(hw->phy.media_type != e1000_media_type_copper))
return -EOPNOTSUPP;
- edata->supported = (SUPPORTED_1000baseT_Full |
+ edata->supported = (/* SUPPORTED_1000baseT_Full | */
SUPPORTED_100baseT_Full);
if (!hw->dev_spec._82575.eee_disable)
edata->advertised =
next prev parent reply other threads:[~2018-04-26 7:54 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-24 15:14 [Intel-wired-lan] [BUG] igb: reconnecting of cable not always detected Holger Schurig
2018-04-24 15:14 ` Holger Schurig
2018-04-24 18:09 ` [Intel-wired-lan] " Alexander Duyck
2018-04-24 18:09 ` Alexander Duyck
2018-04-25 3:30 ` [Intel-wired-lan] " Richard Cochran
2018-04-25 3:30 ` Richard Cochran
2018-04-25 9:47 ` [Intel-wired-lan] " Holger Schurig
2018-04-25 9:47 ` Holger Schurig
2018-04-25 16:01 ` [Intel-wired-lan] " Alexander Duyck
2018-04-25 16:01 ` Alexander Duyck
2018-04-26 7:54 ` Holger Schurig [this message]
2018-04-26 7:54 ` Holger Schurig
2018-04-26 9:08 ` [Intel-wired-lan] " Holger Schurig
2018-04-26 9:08 ` Holger Schurig
2018-04-26 16:02 ` [Intel-wired-lan] " Alexander Duyck
2018-04-26 16:02 ` Alexander Duyck
2018-04-27 10:39 ` [Intel-wired-lan] " Holger Schurig
2018-04-27 10:39 ` Holger Schurig
2018-05-18 7:35 ` [Intel-wired-lan] " Holger Schurig
2018-05-18 7:35 ` Holger Schurig
2019-01-17 21:55 ` [Intel-wired-lan] " Jeff Kirsher
2019-01-17 21:55 ` Jeff Kirsher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8736zio11o.fsf@gmail.com \
--to=holgerschurig@gmail.com \
--cc=intel-wired-lan@osuosl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.