* e1000e driver stuck at 10Mbps after reconnection
@ 2018-08-06 11:59 ` Camille Bordignon
0 siblings, 0 replies; 20+ messages in thread
From: Camille Bordignon @ 2018-08-06 11:59 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: David S. Miller, intel-wired-lan, netdev
Hello,
Recently we experienced some issues with intel NIC (I219-LM and I219-V).
It seems that after a wire reconnection, auto-negotation "fails" and
link speed drips to 10 Mbps.
>From kernel logs:
[17616.346150] e1000e: enp0s31f6 NIC Link is Down
[17627.003322] e1000e: enp0s31f6 NIC Link is Up 10 Mbps Full Duplex, Flow Control: None
[17627.003325] e1000e 0000:00:1f.6 enp0s31f6: 10/100 speed: disabling TSO
$ethtool enp0s31f6
Settings for enp0s31f6:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 10Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: on (auto)
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
Notice that if disconnection last less than about 5 seconds,
nothing wrong happens.
And if after last failure, disconnection / connection occurs again and
last less than 5 seconds, link speed is back to 1000 Mbps.
[18075.350678] e1000e: enp0s31f6 NIC Link is Down
[18078.716245] e1000e: enp0s31f6 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
The following patch seems to fix this issue.
However I don't clearly understand why.
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 3ba0c90e7055..763c013960f1 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -5069,7 +5069,7 @@ static bool e1000e_has_link(struct e1000_adapter *adapter)
case e1000_media_type_copper:
if (hw->mac.get_link_status) {
ret_val = hw->mac.ops.check_for_link(hw);
- link_active = !hw->mac.get_link_status;
+ link_active = false;
} else {
link_active = true;
}
Maybe this is related to watchdog task.
I've found out this fix by comparing with last commit that works fine :
commit 0b76aae741abb9d16d2c0e67f8b1e766576f897d.
However I don't know if this information is relevant.
Thank you.
Camille Bordignon
^ permalink raw reply related [flat|nested] 20+ messages in thread
* [Intel-wired-lan] e1000e driver stuck at 10Mbps after reconnection
@ 2018-08-06 11:59 ` Camille Bordignon
0 siblings, 0 replies; 20+ messages in thread
From: Camille Bordignon @ 2018-08-06 11:59 UTC (permalink / raw)
To: intel-wired-lan
Hello,
Recently we experienced some issues with intel NIC (I219-LM and I219-V).
It seems that after a wire reconnection, auto-negotation "fails" and
link speed drips to 10 Mbps.
From kernel logs:
[17616.346150] e1000e: enp0s31f6 NIC Link is Down
[17627.003322] e1000e: enp0s31f6 NIC Link is Up 10 Mbps Full Duplex, Flow Control: None
[17627.003325] e1000e 0000:00:1f.6 enp0s31f6: 10/100 speed: disabling TSO
$ethtool enp0s31f6
Settings for enp0s31f6:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 10Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: on (auto)
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
Notice that if disconnection last less than about 5 seconds,
nothing wrong happens.
And if after last failure, disconnection / connection occurs again and
last less than 5 seconds, link speed is back to 1000 Mbps.
[18075.350678] e1000e: enp0s31f6 NIC Link is Down
[18078.716245] e1000e: enp0s31f6 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
The following patch seems to fix this issue.
However I don't clearly understand why.
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 3ba0c90e7055..763c013960f1 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -5069,7 +5069,7 @@ static bool e1000e_has_link(struct e1000_adapter *adapter)
case e1000_media_type_copper:
if (hw->mac.get_link_status) {
ret_val = hw->mac.ops.check_for_link(hw);
- link_active = !hw->mac.get_link_status;
+ link_active = false;
} else {
link_active = true;
}
Maybe this is related to watchdog task.
I've found out this fix by comparing with last commit that works fine :
commit 0b76aae741abb9d16d2c0e67f8b1e766576f897d.
However I don't know if this information is relevant.
Thank you.
Camille Bordignon
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: e1000e driver stuck at 10Mbps after reconnection
2018-08-06 11:59 ` [Intel-wired-lan] " Camille Bordignon
@ 2018-08-06 22:45 ` Alexander Duyck
-1 siblings, 0 replies; 20+ messages in thread
From: Alexander Duyck @ 2018-08-06 22:45 UTC (permalink / raw)
To: Camille Bordignon; +Cc: Jeff Kirsher, David S. Miller, intel-wired-lan, Netdev
On Mon, Aug 6, 2018 at 4:59 AM, Camille Bordignon
<camille.bordignon@easymile.com> wrote:
> Hello,
>
> Recently we experienced some issues with intel NIC (I219-LM and I219-V).
> It seems that after a wire reconnection, auto-negotation "fails" and
> link speed drips to 10 Mbps.
>
> From kernel logs:
> [17616.346150] e1000e: enp0s31f6 NIC Link is Down
> [17627.003322] e1000e: enp0s31f6 NIC Link is Up 10 Mbps Full Duplex, Flow Control: None
> [17627.003325] e1000e 0000:00:1f.6 enp0s31f6: 10/100 speed: disabling TSO
>
>
> $ethtool enp0s31f6
> Settings for enp0s31f6:
> Supported ports: [ TP ]
> Supported link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Full
> Supported pause frame use: No
> Supports auto-negotiation: Yes
> Supported FEC modes: Not reported
> Advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Full
> Advertised pause frame use: No
> Advertised auto-negotiation: Yes
> Advertised FEC modes: Not reported
> Speed: 10Mb/s
> Duplex: Full
> Port: Twisted Pair
> PHYAD: 1
> Transceiver: internal
> Auto-negotiation: on
> MDI-X: on (auto)
> Supports Wake-on: pumbg
> Wake-on: g
> Current message level: 0x00000007 (7)
> drv probe link
> Link detected: yes
>
>
> Notice that if disconnection last less than about 5 seconds,
> nothing wrong happens.
> And if after last failure, disconnection / connection occurs again and
> last less than 5 seconds, link speed is back to 1000 Mbps.
>
> [18075.350678] e1000e: enp0s31f6 NIC Link is Down
> [18078.716245] e1000e: enp0s31f6 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
>
> The following patch seems to fix this issue.
> However I don't clearly understand why.
>
> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
> index 3ba0c90e7055..763c013960f1 100644
> --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> @@ -5069,7 +5069,7 @@ static bool e1000e_has_link(struct e1000_adapter *adapter)
> case e1000_media_type_copper:
> if (hw->mac.get_link_status) {
> ret_val = hw->mac.ops.check_for_link(hw);
> - link_active = !hw->mac.get_link_status;
> + link_active = false;
> } else {
> link_active = true;
> }
>
> Maybe this is related to watchdog task.
>
> I've found out this fix by comparing with last commit that works fine :
> commit 0b76aae741abb9d16d2c0e67f8b1e766576f897d.
> However I don't know if this information is relevant.
>
> Thank you.
> Camille Bordignon
What kernel were you testing this on? I know there have been a number
of changes over the past few months in this area and it would be
useful to know exactly what code base you started out with and what
the latest version of the kernel is you have tested.
Looking over the code change the net effect of it should be to add a 2
second delay from the time the link has changed until you actually
check the speed/duplex configuration. It is possible we could be
seeing some sort of timing issue and adding the 2 second delay after
the link event is enough time for things to stabilize and detect the
link at 1000 instead of 10/100.
- Alex
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Intel-wired-lan] e1000e driver stuck at 10Mbps after reconnection
@ 2018-08-06 22:45 ` Alexander Duyck
0 siblings, 0 replies; 20+ messages in thread
From: Alexander Duyck @ 2018-08-06 22:45 UTC (permalink / raw)
To: intel-wired-lan
On Mon, Aug 6, 2018 at 4:59 AM, Camille Bordignon
<camille.bordignon@easymile.com> wrote:
> Hello,
>
> Recently we experienced some issues with intel NIC (I219-LM and I219-V).
> It seems that after a wire reconnection, auto-negotation "fails" and
> link speed drips to 10 Mbps.
>
> From kernel logs:
> [17616.346150] e1000e: enp0s31f6 NIC Link is Down
> [17627.003322] e1000e: enp0s31f6 NIC Link is Up 10 Mbps Full Duplex, Flow Control: None
> [17627.003325] e1000e 0000:00:1f.6 enp0s31f6: 10/100 speed: disabling TSO
>
>
> $ethtool enp0s31f6
> Settings for enp0s31f6:
> Supported ports: [ TP ]
> Supported link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Full
> Supported pause frame use: No
> Supports auto-negotiation: Yes
> Supported FEC modes: Not reported
> Advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Full
> Advertised pause frame use: No
> Advertised auto-negotiation: Yes
> Advertised FEC modes: Not reported
> Speed: 10Mb/s
> Duplex: Full
> Port: Twisted Pair
> PHYAD: 1
> Transceiver: internal
> Auto-negotiation: on
> MDI-X: on (auto)
> Supports Wake-on: pumbg
> Wake-on: g
> Current message level: 0x00000007 (7)
> drv probe link
> Link detected: yes
>
>
> Notice that if disconnection last less than about 5 seconds,
> nothing wrong happens.
> And if after last failure, disconnection / connection occurs again and
> last less than 5 seconds, link speed is back to 1000 Mbps.
>
> [18075.350678] e1000e: enp0s31f6 NIC Link is Down
> [18078.716245] e1000e: enp0s31f6 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
>
> The following patch seems to fix this issue.
> However I don't clearly understand why.
>
> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
> index 3ba0c90e7055..763c013960f1 100644
> --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> @@ -5069,7 +5069,7 @@ static bool e1000e_has_link(struct e1000_adapter *adapter)
> case e1000_media_type_copper:
> if (hw->mac.get_link_status) {
> ret_val = hw->mac.ops.check_for_link(hw);
> - link_active = !hw->mac.get_link_status;
> + link_active = false;
> } else {
> link_active = true;
> }
>
> Maybe this is related to watchdog task.
>
> I've found out this fix by comparing with last commit that works fine :
> commit 0b76aae741abb9d16d2c0e67f8b1e766576f897d.
> However I don't know if this information is relevant.
>
> Thank you.
> Camille Bordignon
What kernel were you testing this on? I know there have been a number
of changes over the past few months in this area and it would be
useful to know exactly what code base you started out with and what
the latest version of the kernel is you have tested.
Looking over the code change the net effect of it should be to add a 2
second delay from the time the link has changed until you actually
check the speed/duplex configuration. It is possible we could be
seeing some sort of timing issue and adding the 2 second delay after
the link event is enough time for things to stabilize and detect the
link at 1000 instead of 10/100.
- Alex
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: e1000e driver stuck at 10Mbps after reconnection
2018-08-06 22:45 ` [Intel-wired-lan] " Alexander Duyck
@ 2018-08-07 6:42 ` Camille Bordignon
-1 siblings, 0 replies; 20+ messages in thread
From: Camille Bordignon @ 2018-08-07 6:42 UTC (permalink / raw)
To: Alexander Duyck; +Cc: Jeff Kirsher, David S. Miller, intel-wired-lan, Netdev
Le lundi 06 août 2018 à 15:45:29 (-0700), Alexander Duyck a écrit :
> On Mon, Aug 6, 2018 at 4:59 AM, Camille Bordignon
> <camille.bordignon@easymile.com> wrote:
> > Hello,
> >
> > Recently we experienced some issues with intel NIC (I219-LM and I219-V).
> > It seems that after a wire reconnection, auto-negotation "fails" and
> > link speed drips to 10 Mbps.
> >
> > From kernel logs:
> > [17616.346150] e1000e: enp0s31f6 NIC Link is Down
> > [17627.003322] e1000e: enp0s31f6 NIC Link is Up 10 Mbps Full Duplex, Flow Control: None
> > [17627.003325] e1000e 0000:00:1f.6 enp0s31f6: 10/100 speed: disabling TSO
> >
> >
> > $ethtool enp0s31f6
> > Settings for enp0s31f6:
> > Supported ports: [ TP ]
> > Supported link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> > 1000baseT/Full
> > Supported pause frame use: No
> > Supports auto-negotiation: Yes
> > Supported FEC modes: Not reported
> > Advertised link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> > 1000baseT/Full
> > Advertised pause frame use: No
> > Advertised auto-negotiation: Yes
> > Advertised FEC modes: Not reported
> > Speed: 10Mb/s
> > Duplex: Full
> > Port: Twisted Pair
> > PHYAD: 1
> > Transceiver: internal
> > Auto-negotiation: on
> > MDI-X: on (auto)
> > Supports Wake-on: pumbg
> > Wake-on: g
> > Current message level: 0x00000007 (7)
> > drv probe link
> > Link detected: yes
> >
> >
> > Notice that if disconnection last less than about 5 seconds,
> > nothing wrong happens.
> > And if after last failure, disconnection / connection occurs again and
> > last less than 5 seconds, link speed is back to 1000 Mbps.
> >
> > [18075.350678] e1000e: enp0s31f6 NIC Link is Down
> > [18078.716245] e1000e: enp0s31f6 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
> >
> > The following patch seems to fix this issue.
> > However I don't clearly understand why.
> >
> > diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
> > index 3ba0c90e7055..763c013960f1 100644
> > --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> > +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> > @@ -5069,7 +5069,7 @@ static bool e1000e_has_link(struct e1000_adapter *adapter)
> > case e1000_media_type_copper:
> > if (hw->mac.get_link_status) {
> > ret_val = hw->mac.ops.check_for_link(hw);
> > - link_active = !hw->mac.get_link_status;
> > + link_active = false;
> > } else {
> > link_active = true;
> > }
> >
> > Maybe this is related to watchdog task.
> >
> > I've found out this fix by comparing with last commit that works fine :
> > commit 0b76aae741abb9d16d2c0e67f8b1e766576f897d.
> > However I don't know if this information is relevant.
> >
> > Thank you.
> > Camille Bordignon
>
> What kernel were you testing this on? I know there have been a number
> of changes over the past few months in this area and it would be
> useful to know exactly what code base you started out with and what
> the latest version of the kernel is you have tested.
>
> Looking over the code change the net effect of it should be to add a 2
> second delay from the time the link has changed until you actually
> check the speed/duplex configuration. It is possible we could be
> seeing some sort of timing issue and adding the 2 second delay after
> the link event is enough time for things to stabilize and detect the
> link at 1000 instead of 10/100.
>
> - Alex
We've found out this issue using Fedora 27 (4.17.11-100.fc27.x86_64).
Then I've tested wth a more recent version of the driver v4.18-rc7 but
behavior looks the same.
Thanks for you reply.
Camille Bordignon
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Intel-wired-lan] e1000e driver stuck at 10Mbps after reconnection
@ 2018-08-07 6:42 ` Camille Bordignon
0 siblings, 0 replies; 20+ messages in thread
From: Camille Bordignon @ 2018-08-07 6:42 UTC (permalink / raw)
To: intel-wired-lan
Le lundi 06 ao?t 2018 ? 15:45:29 (-0700), Alexander Duyck a ?crit :
> On Mon, Aug 6, 2018 at 4:59 AM, Camille Bordignon
> <camille.bordignon@easymile.com> wrote:
> > Hello,
> >
> > Recently we experienced some issues with intel NIC (I219-LM and I219-V).
> > It seems that after a wire reconnection, auto-negotation "fails" and
> > link speed drips to 10 Mbps.
> >
> > From kernel logs:
> > [17616.346150] e1000e: enp0s31f6 NIC Link is Down
> > [17627.003322] e1000e: enp0s31f6 NIC Link is Up 10 Mbps Full Duplex, Flow Control: None
> > [17627.003325] e1000e 0000:00:1f.6 enp0s31f6: 10/100 speed: disabling TSO
> >
> >
> > $ethtool enp0s31f6
> > Settings for enp0s31f6:
> > Supported ports: [ TP ]
> > Supported link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> > 1000baseT/Full
> > Supported pause frame use: No
> > Supports auto-negotiation: Yes
> > Supported FEC modes: Not reported
> > Advertised link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> > 1000baseT/Full
> > Advertised pause frame use: No
> > Advertised auto-negotiation: Yes
> > Advertised FEC modes: Not reported
> > Speed: 10Mb/s
> > Duplex: Full
> > Port: Twisted Pair
> > PHYAD: 1
> > Transceiver: internal
> > Auto-negotiation: on
> > MDI-X: on (auto)
> > Supports Wake-on: pumbg
> > Wake-on: g
> > Current message level: 0x00000007 (7)
> > drv probe link
> > Link detected: yes
> >
> >
> > Notice that if disconnection last less than about 5 seconds,
> > nothing wrong happens.
> > And if after last failure, disconnection / connection occurs again and
> > last less than 5 seconds, link speed is back to 1000 Mbps.
> >
> > [18075.350678] e1000e: enp0s31f6 NIC Link is Down
> > [18078.716245] e1000e: enp0s31f6 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
> >
> > The following patch seems to fix this issue.
> > However I don't clearly understand why.
> >
> > diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
> > index 3ba0c90e7055..763c013960f1 100644
> > --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> > +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> > @@ -5069,7 +5069,7 @@ static bool e1000e_has_link(struct e1000_adapter *adapter)
> > case e1000_media_type_copper:
> > if (hw->mac.get_link_status) {
> > ret_val = hw->mac.ops.check_for_link(hw);
> > - link_active = !hw->mac.get_link_status;
> > + link_active = false;
> > } else {
> > link_active = true;
> > }
> >
> > Maybe this is related to watchdog task.
> >
> > I've found out this fix by comparing with last commit that works fine :
> > commit 0b76aae741abb9d16d2c0e67f8b1e766576f897d.
> > However I don't know if this information is relevant.
> >
> > Thank you.
> > Camille Bordignon
>
> What kernel were you testing this on? I know there have been a number
> of changes over the past few months in this area and it would be
> useful to know exactly what code base you started out with and what
> the latest version of the kernel is you have tested.
>
> Looking over the code change the net effect of it should be to add a 2
> second delay from the time the link has changed until you actually
> check the speed/duplex configuration. It is possible we could be
> seeing some sort of timing issue and adding the 2 second delay after
> the link event is enough time for things to stabilize and detect the
> link at 1000 instead of 10/100.
>
> - Alex
We've found out this issue using Fedora 27 (4.17.11-100.fc27.x86_64).
Then I've tested wth a more recent version of the driver v4.18-rc7 but
behavior looks the same.
Thanks for you reply.
Camille Bordignon
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Intel-wired-lan] e1000e driver stuck at 10Mbps after reconnection
2018-08-07 6:42 ` [Intel-wired-lan] " Camille Bordignon
@ 2018-08-08 14:24 ` Neftin, Sasha
-1 siblings, 0 replies; 20+ messages in thread
From: Neftin, Sasha @ 2018-08-08 14:24 UTC (permalink / raw)
To: Camille Bordignon, Alexander Duyck
Cc: Netdev, intel-wired-lan, David S. Miller
On 8/7/2018 09:42, Camille Bordignon wrote:
> Le lundi 06 août 2018 à 15:45:29 (-0700), Alexander Duyck a écrit :
>> On Mon, Aug 6, 2018 at 4:59 AM, Camille Bordignon
>> <camille.bordignon@easymile.com> wrote:
>>> Hello,
>>>
>>> Recently we experienced some issues with intel NIC (I219-LM and I219-V).
>>> It seems that after a wire reconnection, auto-negotation "fails" and
>>> link speed drips to 10 Mbps.
>>>
>>> From kernel logs:
>>> [17616.346150] e1000e: enp0s31f6 NIC Link is Down
>>> [17627.003322] e1000e: enp0s31f6 NIC Link is Up 10 Mbps Full Duplex, Flow Control: None
>>> [17627.003325] e1000e 0000:00:1f.6 enp0s31f6: 10/100 speed: disabling TSO
>>>
>>>
>>> $ethtool enp0s31f6
>>> Settings for enp0s31f6:
>>> Supported ports: [ TP ]
>>> Supported link modes: 10baseT/Half 10baseT/Full
>>> 100baseT/Half 100baseT/Full
>>> 1000baseT/Full
>>> Supported pause frame use: No
>>> Supports auto-negotiation: Yes
>>> Supported FEC modes: Not reported
>>> Advertised link modes: 10baseT/Half 10baseT/Full
>>> 100baseT/Half 100baseT/Full
>>> 1000baseT/Full
>>> Advertised pause frame use: No
>>> Advertised auto-negotiation: Yes
>>> Advertised FEC modes: Not reported
>>> Speed: 10Mb/s
>>> Duplex: Full
>>> Port: Twisted Pair
>>> PHYAD: 1
>>> Transceiver: internal
>>> Auto-negotiation: on
>>> MDI-X: on (auto)
>>> Supports Wake-on: pumbg
>>> Wake-on: g
>>> Current message level: 0x00000007 (7)
>>> drv probe link
>>> Link detected: yes
>>>
>>>
>>> Notice that if disconnection last less than about 5 seconds,
>>> nothing wrong happens.
>>> And if after last failure, disconnection / connection occurs again and
>>> last less than 5 seconds, link speed is back to 1000 Mbps.
>>>
>>> [18075.350678] e1000e: enp0s31f6 NIC Link is Down
>>> [18078.716245] e1000e: enp0s31f6 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
>>>
>>> The following patch seems to fix this issue.
>>> However I don't clearly understand why.
>>>
>>> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
>>> index 3ba0c90e7055..763c013960f1 100644
>>> --- a/drivers/net/ethernet/intel/e1000e/netdev.c
>>> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
>>> @@ -5069,7 +5069,7 @@ static bool e1000e_has_link(struct e1000_adapter *adapter)
>>> case e1000_media_type_copper:
>>> if (hw->mac.get_link_status) {
>>> ret_val = hw->mac.ops.check_for_link(hw);
>>> - link_active = !hw->mac.get_link_status;
>>> + link_active = false;
>>> } else {
>>> link_active = true;
>>> }
>>>
>>> Maybe this is related to watchdog task.
>>>
>>> I've found out this fix by comparing with last commit that works fine :
>>> commit 0b76aae741abb9d16d2c0e67f8b1e766576f897d.
>>> However I don't know if this information is relevant.
>>>
>>> Thank you.
>>> Camille Bordignon
>>
>> What kernel were you testing this on? I know there have been a number
>> of changes over the past few months in this area and it would be
>> useful to know exactly what code base you started out with and what
>> the latest version of the kernel is you have tested.
>>
>> Looking over the code change the net effect of it should be to add a 2
>> second delay from the time the link has changed until you actually
>> check the speed/duplex configuration. It is possible we could be
>> seeing some sort of timing issue and adding the 2 second delay after
>> the link event is enough time for things to stabilize and detect the
>> link at 1000 instead of 10/100.
>>
>> - Alex
>
> We've found out this issue using Fedora 27 (4.17.11-100.fc27.x86_64).
>
> Then I've tested wth a more recent version of the driver v4.18-rc7 but
> behavior looks the same.
>
> Thanks for you reply.
>
> Camille Bordignon
> _______________________________________________
> Intel-wired-lan mailing list
> Intel-wired-lan@osuosl.org
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
>
I've agree with Alex. Let's try add 2s delay after a link event. Please,
let us know if it will solve your problem.
Also, I would like recommend try work with different link partner and
see if you see same problem.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Intel-wired-lan] e1000e driver stuck at 10Mbps after reconnection
@ 2018-08-08 14:24 ` Neftin, Sasha
0 siblings, 0 replies; 20+ messages in thread
From: Neftin, Sasha @ 2018-08-08 14:24 UTC (permalink / raw)
To: intel-wired-lan
On 8/7/2018 09:42, Camille Bordignon wrote:
> Le lundi 06 ao?t 2018 ? 15:45:29 (-0700), Alexander Duyck a ?crit :
>> On Mon, Aug 6, 2018 at 4:59 AM, Camille Bordignon
>> <camille.bordignon@easymile.com> wrote:
>>> Hello,
>>>
>>> Recently we experienced some issues with intel NIC (I219-LM and I219-V).
>>> It seems that after a wire reconnection, auto-negotation "fails" and
>>> link speed drips to 10 Mbps.
>>>
>>> From kernel logs:
>>> [17616.346150] e1000e: enp0s31f6 NIC Link is Down
>>> [17627.003322] e1000e: enp0s31f6 NIC Link is Up 10 Mbps Full Duplex, Flow Control: None
>>> [17627.003325] e1000e 0000:00:1f.6 enp0s31f6: 10/100 speed: disabling TSO
>>>
>>>
>>> $ethtool enp0s31f6
>>> Settings for enp0s31f6:
>>> Supported ports: [ TP ]
>>> Supported link modes: 10baseT/Half 10baseT/Full
>>> 100baseT/Half 100baseT/Full
>>> 1000baseT/Full
>>> Supported pause frame use: No
>>> Supports auto-negotiation: Yes
>>> Supported FEC modes: Not reported
>>> Advertised link modes: 10baseT/Half 10baseT/Full
>>> 100baseT/Half 100baseT/Full
>>> 1000baseT/Full
>>> Advertised pause frame use: No
>>> Advertised auto-negotiation: Yes
>>> Advertised FEC modes: Not reported
>>> Speed: 10Mb/s
>>> Duplex: Full
>>> Port: Twisted Pair
>>> PHYAD: 1
>>> Transceiver: internal
>>> Auto-negotiation: on
>>> MDI-X: on (auto)
>>> Supports Wake-on: pumbg
>>> Wake-on: g
>>> Current message level: 0x00000007 (7)
>>> drv probe link
>>> Link detected: yes
>>>
>>>
>>> Notice that if disconnection last less than about 5 seconds,
>>> nothing wrong happens.
>>> And if after last failure, disconnection / connection occurs again and
>>> last less than 5 seconds, link speed is back to 1000 Mbps.
>>>
>>> [18075.350678] e1000e: enp0s31f6 NIC Link is Down
>>> [18078.716245] e1000e: enp0s31f6 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
>>>
>>> The following patch seems to fix this issue.
>>> However I don't clearly understand why.
>>>
>>> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
>>> index 3ba0c90e7055..763c013960f1 100644
>>> --- a/drivers/net/ethernet/intel/e1000e/netdev.c
>>> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
>>> @@ -5069,7 +5069,7 @@ static bool e1000e_has_link(struct e1000_adapter *adapter)
>>> case e1000_media_type_copper:
>>> if (hw->mac.get_link_status) {
>>> ret_val = hw->mac.ops.check_for_link(hw);
>>> - link_active = !hw->mac.get_link_status;
>>> + link_active = false;
>>> } else {
>>> link_active = true;
>>> }
>>>
>>> Maybe this is related to watchdog task.
>>>
>>> I've found out this fix by comparing with last commit that works fine :
>>> commit 0b76aae741abb9d16d2c0e67f8b1e766576f897d.
>>> However I don't know if this information is relevant.
>>>
>>> Thank you.
>>> Camille Bordignon
>>
>> What kernel were you testing this on? I know there have been a number
>> of changes over the past few months in this area and it would be
>> useful to know exactly what code base you started out with and what
>> the latest version of the kernel is you have tested.
>>
>> Looking over the code change the net effect of it should be to add a 2
>> second delay from the time the link has changed until you actually
>> check the speed/duplex configuration. It is possible we could be
>> seeing some sort of timing issue and adding the 2 second delay after
>> the link event is enough time for things to stabilize and detect the
>> link at 1000 instead of 10/100.
>>
>> - Alex
>
> We've found out this issue using Fedora 27 (4.17.11-100.fc27.x86_64).
>
> Then I've tested wth a more recent version of the driver v4.18-rc7 but
> behavior looks the same.
>
> Thanks for you reply.
>
> Camille Bordignon
> _______________________________________________
> Intel-wired-lan mailing list
> Intel-wired-lan at osuosl.org
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
>
I've agree with Alex. Let's try add 2s delay after a link event. Please,
let us know if it will solve your problem.
Also, I would like recommend try work with different link partner and
see if you see same problem.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Intel-wired-lan] e1000e driver stuck at 10Mbps after reconnection
2018-08-08 14:24 ` Neftin, Sasha
@ 2018-08-08 15:00 ` Neftin, Sasha
-1 siblings, 0 replies; 20+ messages in thread
From: Neftin, Sasha @ 2018-08-08 15:00 UTC (permalink / raw)
To: Camille Bordignon, Alexander Duyck
Cc: Netdev, intel-wired-lan, David S. Miller
On 8/8/2018 17:24, Neftin, Sasha wrote:
> On 8/7/2018 09:42, Camille Bordignon wrote:
>> Le lundi 06 août 2018 à 15:45:29 (-0700), Alexander Duyck a écrit :
>>> On Mon, Aug 6, 2018 at 4:59 AM, Camille Bordignon
>>> <camille.bordignon@easymile.com> wrote:
>>>> Hello,
>>>>
>>>> Recently we experienced some issues with intel NIC (I219-LM and
>>>> I219-V).
>>>> It seems that after a wire reconnection, auto-negotation "fails" and
>>>> link speed drips to 10 Mbps.
>>>>
>>>> From kernel logs:
>>>> [17616.346150] e1000e: enp0s31f6 NIC Link is Down
>>>> [17627.003322] e1000e: enp0s31f6 NIC Link is Up 10 Mbps Full Duplex,
>>>> Flow Control: None
>>>> [17627.003325] e1000e 0000:00:1f.6 enp0s31f6: 10/100 speed:
>>>> disabling TSO
>>>>
>>>>
>>>> $ethtool enp0s31f6
>>>> Settings for enp0s31f6:
>>>> Supported ports: [ TP ]
>>>> Supported link modes: 10baseT/Half 10baseT/Full
>>>> 100baseT/Half 100baseT/Full
>>>> 1000baseT/Full
>>>> Supported pause frame use: No
>>>> Supports auto-negotiation: Yes
>>>> Supported FEC modes: Not reported
>>>> Advertised link modes: 10baseT/Half 10baseT/Full
>>>> 100baseT/Half 100baseT/Full
>>>> 1000baseT/Full
>>>> Advertised pause frame use: No
>>>> Advertised auto-negotiation: Yes
>>>> Advertised FEC modes: Not reported
>>>> Speed: 10Mb/s
>>>> Duplex: Full
>>>> Port: Twisted Pair
>>>> PHYAD: 1
>>>> Transceiver: internal
>>>> Auto-negotiation: on
>>>> MDI-X: on (auto)
>>>> Supports Wake-on: pumbg
>>>> Wake-on: g
>>>> Current message level: 0x00000007 (7)
>>>> drv probe link
>>>> Link detected: yes
>>>>
>>>>
>>>> Notice that if disconnection last less than about 5 seconds,
>>>> nothing wrong happens.
>>>> And if after last failure, disconnection / connection occurs again and
>>>> last less than 5 seconds, link speed is back to 1000 Mbps.
>>>>
>>>> [18075.350678] e1000e: enp0s31f6 NIC Link is Down
>>>> [18078.716245] e1000e: enp0s31f6 NIC Link is Up 1000 Mbps Full
>>>> Duplex, Flow Control: None
>>>>
>>>> The following patch seems to fix this issue.
>>>> However I don't clearly understand why.
>>>>
>>>> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
>>>> b/drivers/net/ethernet/intel/e1000e/netdev.c
>>>> index 3ba0c90e7055..763c013960f1 100644
>>>> --- a/drivers/net/ethernet/intel/e1000e/netdev.c
>>>> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
>>>> @@ -5069,7 +5069,7 @@ static bool e1000e_has_link(struct
>>>> e1000_adapter *adapter)
>>>> case e1000_media_type_copper:
>>>> if (hw->mac.get_link_status) {
>>>> ret_val = hw->mac.ops.check_for_link(hw);
>>>> - link_active = !hw->mac.get_link_status;
>>>> + link_active = false;
>>>> } else {
>>>> link_active = true;
>>>> }
>>>>
>>>> Maybe this is related to watchdog task.
>>>>
>>>> I've found out this fix by comparing with last commit that works fine :
>>>> commit 0b76aae741abb9d16d2c0e67f8b1e766576f897d.
>>>> However I don't know if this information is relevant.
>>>>
>>>> Thank you.
>>>> Camille Bordignon
>>>
>>> What kernel were you testing this on? I know there have been a number
>>> of changes over the past few months in this area and it would be
>>> useful to know exactly what code base you started out with and what
>>> the latest version of the kernel is you have tested.
>>>
>>> Looking over the code change the net effect of it should be to add a 2
>>> second delay from the time the link has changed until you actually
>>> check the speed/duplex configuration. It is possible we could be
>>> seeing some sort of timing issue and adding the 2 second delay after
>>> the link event is enough time for things to stabilize and detect the
>>> link at 1000 instead of 10/100.
>>>
>>> - Alex
>>
>> We've found out this issue using Fedora 27 (4.17.11-100.fc27.x86_64).
>>
>> Then I've tested wth a more recent version of the driver v4.18-rc7 but
>> behavior looks the same.
>>
>> Thanks for you reply.
>>
>> Camille Bordignon
>> _______________________________________________
>> Intel-wired-lan mailing list
>> Intel-wired-lan@osuosl.org
>> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
>>
> I've agree with Alex. Let's try add 2s delay after a link event. Please,
> let us know if it will solve your problem.
> Also, I would like recommend try work with different link partner and
> see if you see same problem.
> _______________________________________________
> Intel-wired-lan mailing list
> Intel-wired-lan@osuosl.org
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
Camille,
My apologies, I wrong understand Alex. Please, do not try add delay.
Please, check if you see same problem with different link partners.
Thanks,
Sasha
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Intel-wired-lan] e1000e driver stuck at 10Mbps after reconnection
@ 2018-08-08 15:00 ` Neftin, Sasha
0 siblings, 0 replies; 20+ messages in thread
From: Neftin, Sasha @ 2018-08-08 15:00 UTC (permalink / raw)
To: intel-wired-lan
On 8/8/2018 17:24, Neftin, Sasha wrote:
> On 8/7/2018 09:42, Camille Bordignon wrote:
>> Le lundi 06 ao?t 2018 ? 15:45:29 (-0700), Alexander Duyck a ?crit :
>>> On Mon, Aug 6, 2018 at 4:59 AM, Camille Bordignon
>>> <camille.bordignon@easymile.com> wrote:
>>>> Hello,
>>>>
>>>> Recently we experienced some issues with intel NIC (I219-LM and
>>>> I219-V).
>>>> It seems that after a wire reconnection, auto-negotation "fails" and
>>>> link speed drips to 10 Mbps.
>>>>
>>>> ?From kernel logs:
>>>> [17616.346150] e1000e: enp0s31f6 NIC Link is Down
>>>> [17627.003322] e1000e: enp0s31f6 NIC Link is Up 10 Mbps Full Duplex,
>>>> Flow Control: None
>>>> [17627.003325] e1000e 0000:00:1f.6 enp0s31f6: 10/100 speed:
>>>> disabling TSO
>>>>
>>>>
>>>> $ethtool enp0s31f6
>>>> Settings for enp0s31f6:
>>>> ???????? Supported ports: [ TP ]
>>>> ???????? Supported link modes:?? 10baseT/Half 10baseT/Full
>>>> ???????????????????????????????? 100baseT/Half 100baseT/Full
>>>> ???????????????????????????????? 1000baseT/Full
>>>> ???????? Supported pause frame use: No
>>>> ???????? Supports auto-negotiation: Yes
>>>> ???????? Supported FEC modes: Not reported
>>>> ???????? Advertised link modes:? 10baseT/Half 10baseT/Full
>>>> ???????????????????????????????? 100baseT/Half 100baseT/Full
>>>> ???????????????????????????????? 1000baseT/Full
>>>> ???????? Advertised pause frame use: No
>>>> ???????? Advertised auto-negotiation: Yes
>>>> ???????? Advertised FEC modes: Not reported
>>>> ???????? Speed: 10Mb/s
>>>> ???????? Duplex: Full
>>>> ???????? Port: Twisted Pair
>>>> ???????? PHYAD: 1
>>>> ???????? Transceiver: internal
>>>> ???????? Auto-negotiation: on
>>>> ???????? MDI-X: on (auto)
>>>> ???????? Supports Wake-on: pumbg
>>>> ???????? Wake-on: g
>>>> ???????? Current message level: 0x00000007 (7)
>>>> ??????????????????????????????? drv probe link
>>>> ???????? Link detected: yes
>>>>
>>>>
>>>> Notice that if disconnection last less than about 5 seconds,
>>>> nothing wrong happens.
>>>> And if after last failure, disconnection / connection occurs again and
>>>> last less than 5 seconds, link speed is back to 1000 Mbps.
>>>>
>>>> [18075.350678] e1000e: enp0s31f6 NIC Link is Down
>>>> [18078.716245] e1000e: enp0s31f6 NIC Link is Up 1000 Mbps Full
>>>> Duplex, Flow Control: None
>>>>
>>>> The following patch seems to fix this issue.
>>>> However I don't clearly understand why.
>>>>
>>>> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
>>>> b/drivers/net/ethernet/intel/e1000e/netdev.c
>>>> index 3ba0c90e7055..763c013960f1 100644
>>>> --- a/drivers/net/ethernet/intel/e1000e/netdev.c
>>>> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
>>>> @@ -5069,7 +5069,7 @@ static bool e1000e_has_link(struct
>>>> e1000_adapter *adapter)
>>>> ???????? case e1000_media_type_copper:
>>>> ???????????????? if (hw->mac.get_link_status) {
>>>> ???????????????????????? ret_val = hw->mac.ops.check_for_link(hw);
>>>> -?????????????????????? link_active = !hw->mac.get_link_status;
>>>> +?????????????????????? link_active = false;
>>>> ???????????????? } else {
>>>> ???????????????????????? link_active = true;
>>>> ???????????????? }
>>>>
>>>> Maybe this is related to watchdog task.
>>>>
>>>> I've found out this fix by comparing with last commit that works fine :
>>>> commit 0b76aae741abb9d16d2c0e67f8b1e766576f897d.
>>>> However I don't know if this information is relevant.
>>>>
>>>> Thank you.
>>>> Camille Bordignon
>>>
>>> What kernel were you testing this on? I know there have been a number
>>> of changes over the past few months in this area and it would be
>>> useful to know exactly what code base you started out with and what
>>> the latest version of the kernel is you have tested.
>>>
>>> Looking over the code change the net effect of it should be to add a 2
>>> second delay from the time the link has changed until you actually
>>> check the speed/duplex configuration. It is possible we could be
>>> seeing some sort of timing issue and adding the 2 second delay after
>>> the link event is enough time for things to stabilize and detect the
>>> link at 1000 instead of 10/100.
>>>
>>> - Alex
>>
>> We've found out this issue using Fedora 27 (4.17.11-100.fc27.x86_64).
>>
>> Then I've tested wth a more recent version of the driver v4.18-rc7 but
>> behavior looks the same.
>>
>> Thanks for you reply.
>>
>> Camille Bordignon
>> _______________________________________________
>> Intel-wired-lan mailing list
>> Intel-wired-lan at osuosl.org
>> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
>>
> I've agree with Alex. Let's try add 2s delay after a link event. Please,
> let us know if it will solve your problem.
> Also, I would like recommend try work with different link partner and
> see if you see same problem.
> _______________________________________________
> Intel-wired-lan mailing list
> Intel-wired-lan at osuosl.org
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
Camille,
My apologies, I wrong understand Alex. Please, do not try add delay.
Please, check if you see same problem with different link partners.
Thanks,
Sasha
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Intel-wired-lan] e1000e driver stuck at 10Mbps after reconnection
2018-08-08 15:00 ` Neftin, Sasha
@ 2018-08-14 9:14 ` Camille Bordignon
-1 siblings, 0 replies; 20+ messages in thread
From: Camille Bordignon @ 2018-08-14 9:14 UTC (permalink / raw)
To: Neftin, Sasha; +Cc: Alexander Duyck, Netdev, intel-wired-lan, David S. Miller
Le mercredi 08 août 2018 à 18:00:28 (+0300), Neftin, Sasha a écrit :
> On 8/8/2018 17:24, Neftin, Sasha wrote:
> > On 8/7/2018 09:42, Camille Bordignon wrote:
> > > Le lundi 06 août 2018 à 15:45:29 (-0700), Alexander Duyck a écrit :
> > > > On Mon, Aug 6, 2018 at 4:59 AM, Camille Bordignon
> > > > <camille.bordignon@easymile.com> wrote:
> > > > > Hello,
> > > > >
> > > > > Recently we experienced some issues with intel NIC (I219-LM
> > > > > and I219-V).
> > > > > It seems that after a wire reconnection, auto-negotation "fails" and
> > > > > link speed drips to 10 Mbps.
> > > > >
> > > > > From kernel logs:
> > > > > [17616.346150] e1000e: enp0s31f6 NIC Link is Down
> > > > > [17627.003322] e1000e: enp0s31f6 NIC Link is Up 10 Mbps Full
> > > > > Duplex, Flow Control: None
> > > > > [17627.003325] e1000e 0000:00:1f.6 enp0s31f6: 10/100 speed:
> > > > > disabling TSO
> > > > >
> > > > >
> > > > > $ethtool enp0s31f6
> > > > > Settings for enp0s31f6:
> > > > > Supported ports: [ TP ]
> > > > > Supported link modes: 10baseT/Half 10baseT/Full
> > > > > 100baseT/Half 100baseT/Full
> > > > > 1000baseT/Full
> > > > > Supported pause frame use: No
> > > > > Supports auto-negotiation: Yes
> > > > > Supported FEC modes: Not reported
> > > > > Advertised link modes: 10baseT/Half 10baseT/Full
> > > > > 100baseT/Half 100baseT/Full
> > > > > 1000baseT/Full
> > > > > Advertised pause frame use: No
> > > > > Advertised auto-negotiation: Yes
> > > > > Advertised FEC modes: Not reported
> > > > > Speed: 10Mb/s
> > > > > Duplex: Full
> > > > > Port: Twisted Pair
> > > > > PHYAD: 1
> > > > > Transceiver: internal
> > > > > Auto-negotiation: on
> > > > > MDI-X: on (auto)
> > > > > Supports Wake-on: pumbg
> > > > > Wake-on: g
> > > > > Current message level: 0x00000007 (7)
> > > > > drv probe link
> > > > > Link detected: yes
> > > > >
> > > > >
> > > > > Notice that if disconnection last less than about 5 seconds,
> > > > > nothing wrong happens.
> > > > > And if after last failure, disconnection / connection occurs again and
> > > > > last less than 5 seconds, link speed is back to 1000 Mbps.
> > > > >
> > > > > [18075.350678] e1000e: enp0s31f6 NIC Link is Down
> > > > > [18078.716245] e1000e: enp0s31f6 NIC Link is Up 1000 Mbps
> > > > > Full Duplex, Flow Control: None
> > > > >
> > > > > The following patch seems to fix this issue.
> > > > > However I don't clearly understand why.
> > > > >
> > > > > diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
> > > > > b/drivers/net/ethernet/intel/e1000e/netdev.c
> > > > > index 3ba0c90e7055..763c013960f1 100644
> > > > > --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> > > > > +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> > > > > @@ -5069,7 +5069,7 @@ static bool e1000e_has_link(struct
> > > > > e1000_adapter *adapter)
> > > > > case e1000_media_type_copper:
> > > > > if (hw->mac.get_link_status) {
> > > > > ret_val = hw->mac.ops.check_for_link(hw);
> > > > > - link_active = !hw->mac.get_link_status;
> > > > > + link_active = false;
> > > > > } else {
> > > > > link_active = true;
> > > > > }
> > > > >
> > > > > Maybe this is related to watchdog task.
> > > > >
> > > > > I've found out this fix by comparing with last commit that works fine :
> > > > > commit 0b76aae741abb9d16d2c0e67f8b1e766576f897d.
> > > > > However I don't know if this information is relevant.
> > > > >
> > > > > Thank you.
> > > > > Camille Bordignon
> > > >
> > > > What kernel were you testing this on? I know there have been a number
> > > > of changes over the past few months in this area and it would be
> > > > useful to know exactly what code base you started out with and what
> > > > the latest version of the kernel is you have tested.
> > > >
> > > > Looking over the code change the net effect of it should be to add a 2
> > > > second delay from the time the link has changed until you actually
> > > > check the speed/duplex configuration. It is possible we could be
> > > > seeing some sort of timing issue and adding the 2 second delay after
> > > > the link event is enough time for things to stabilize and detect the
> > > > link at 1000 instead of 10/100.
> > > >
> > > > - Alex
> > >
> > > We've found out this issue using Fedora 27 (4.17.11-100.fc27.x86_64).
> > >
> > > Then I've tested wth a more recent version of the driver v4.18-rc7 but
> > > behavior looks the same.
> > >
> > > Thanks for you reply.
> > >
> > > Camille Bordignon
> > > _______________________________________________
> > > Intel-wired-lan mailing list
> > > Intel-wired-lan@osuosl.org
> > > https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
> > >
> > I've agree with Alex. Let's try add 2s delay after a link event. Please,
> > let us know if it will solve your problem.
> > Also, I would like recommend try work with different link partner and
> > see if you see same problem.
> > _______________________________________________
> > Intel-wired-lan mailing list
> > Intel-wired-lan@osuosl.org
> > https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
> Camille,
> My apologies, I wrong understand Alex. Please, do not try add delay. Please,
> check if you see same problem with different link partners.
> Thanks,
> Sasha
I tried to reproduce the issue with differents devices.
On computer side :
- HP ZBook 14u G5 (Intel NIC I219-V)
- Dell Tower 3620 (Intel NIC I219-LM)
On network side :
- TP-LINK TL-SG108E
- Advantech EKI-2728I
- Freebox v6 (https://en.wikipedia.org/wiki/Freebox)
It always happens with any configuration.
Thanks.
Camille Bordignon
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Intel-wired-lan] e1000e driver stuck at 10Mbps after reconnection
@ 2018-08-14 9:14 ` Camille Bordignon
0 siblings, 0 replies; 20+ messages in thread
From: Camille Bordignon @ 2018-08-14 9:14 UTC (permalink / raw)
To: intel-wired-lan
Le mercredi 08 ao?t 2018 ? 18:00:28 (+0300), Neftin, Sasha a ?crit :
> On 8/8/2018 17:24, Neftin, Sasha wrote:
> > On 8/7/2018 09:42, Camille Bordignon wrote:
> > > Le lundi 06 ao?t 2018 ? 15:45:29 (-0700), Alexander Duyck a ?crit :
> > > > On Mon, Aug 6, 2018 at 4:59 AM, Camille Bordignon
> > > > <camille.bordignon@easymile.com> wrote:
> > > > > Hello,
> > > > >
> > > > > Recently we experienced some issues with intel NIC (I219-LM
> > > > > and I219-V).
> > > > > It seems that after a wire reconnection, auto-negotation "fails" and
> > > > > link speed drips to 10 Mbps.
> > > > >
> > > > > ?From kernel logs:
> > > > > [17616.346150] e1000e: enp0s31f6 NIC Link is Down
> > > > > [17627.003322] e1000e: enp0s31f6 NIC Link is Up 10 Mbps Full
> > > > > Duplex, Flow Control: None
> > > > > [17627.003325] e1000e 0000:00:1f.6 enp0s31f6: 10/100 speed:
> > > > > disabling TSO
> > > > >
> > > > >
> > > > > $ethtool enp0s31f6
> > > > > Settings for enp0s31f6:
> > > > > ???????? Supported ports: [ TP ]
> > > > > ???????? Supported link modes:?? 10baseT/Half 10baseT/Full
> > > > > ???????????????????????????????? 100baseT/Half 100baseT/Full
> > > > > ???????????????????????????????? 1000baseT/Full
> > > > > ???????? Supported pause frame use: No
> > > > > ???????? Supports auto-negotiation: Yes
> > > > > ???????? Supported FEC modes: Not reported
> > > > > ???????? Advertised link modes:? 10baseT/Half 10baseT/Full
> > > > > ???????????????????????????????? 100baseT/Half 100baseT/Full
> > > > > ???????????????????????????????? 1000baseT/Full
> > > > > ???????? Advertised pause frame use: No
> > > > > ???????? Advertised auto-negotiation: Yes
> > > > > ???????? Advertised FEC modes: Not reported
> > > > > ???????? Speed: 10Mb/s
> > > > > ???????? Duplex: Full
> > > > > ???????? Port: Twisted Pair
> > > > > ???????? PHYAD: 1
> > > > > ???????? Transceiver: internal
> > > > > ???????? Auto-negotiation: on
> > > > > ???????? MDI-X: on (auto)
> > > > > ???????? Supports Wake-on: pumbg
> > > > > ???????? Wake-on: g
> > > > > ???????? Current message level: 0x00000007 (7)
> > > > > ??????????????????????????????? drv probe link
> > > > > ???????? Link detected: yes
> > > > >
> > > > >
> > > > > Notice that if disconnection last less than about 5 seconds,
> > > > > nothing wrong happens.
> > > > > And if after last failure, disconnection / connection occurs again and
> > > > > last less than 5 seconds, link speed is back to 1000 Mbps.
> > > > >
> > > > > [18075.350678] e1000e: enp0s31f6 NIC Link is Down
> > > > > [18078.716245] e1000e: enp0s31f6 NIC Link is Up 1000 Mbps
> > > > > Full Duplex, Flow Control: None
> > > > >
> > > > > The following patch seems to fix this issue.
> > > > > However I don't clearly understand why.
> > > > >
> > > > > diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
> > > > > b/drivers/net/ethernet/intel/e1000e/netdev.c
> > > > > index 3ba0c90e7055..763c013960f1 100644
> > > > > --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> > > > > +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> > > > > @@ -5069,7 +5069,7 @@ static bool e1000e_has_link(struct
> > > > > e1000_adapter *adapter)
> > > > > ???????? case e1000_media_type_copper:
> > > > > ???????????????? if (hw->mac.get_link_status) {
> > > > > ???????????????????????? ret_val = hw->mac.ops.check_for_link(hw);
> > > > > -?????????????????????? link_active = !hw->mac.get_link_status;
> > > > > +?????????????????????? link_active = false;
> > > > > ???????????????? } else {
> > > > > ???????????????????????? link_active = true;
> > > > > ???????????????? }
> > > > >
> > > > > Maybe this is related to watchdog task.
> > > > >
> > > > > I've found out this fix by comparing with last commit that works fine :
> > > > > commit 0b76aae741abb9d16d2c0e67f8b1e766576f897d.
> > > > > However I don't know if this information is relevant.
> > > > >
> > > > > Thank you.
> > > > > Camille Bordignon
> > > >
> > > > What kernel were you testing this on? I know there have been a number
> > > > of changes over the past few months in this area and it would be
> > > > useful to know exactly what code base you started out with and what
> > > > the latest version of the kernel is you have tested.
> > > >
> > > > Looking over the code change the net effect of it should be to add a 2
> > > > second delay from the time the link has changed until you actually
> > > > check the speed/duplex configuration. It is possible we could be
> > > > seeing some sort of timing issue and adding the 2 second delay after
> > > > the link event is enough time for things to stabilize and detect the
> > > > link at 1000 instead of 10/100.
> > > >
> > > > - Alex
> > >
> > > We've found out this issue using Fedora 27 (4.17.11-100.fc27.x86_64).
> > >
> > > Then I've tested wth a more recent version of the driver v4.18-rc7 but
> > > behavior looks the same.
> > >
> > > Thanks for you reply.
> > >
> > > Camille Bordignon
> > > _______________________________________________
> > > Intel-wired-lan mailing list
> > > Intel-wired-lan at osuosl.org
> > > https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
> > >
> > I've agree with Alex. Let's try add 2s delay after a link event. Please,
> > let us know if it will solve your problem.
> > Also, I would like recommend try work with different link partner and
> > see if you see same problem.
> > _______________________________________________
> > Intel-wired-lan mailing list
> > Intel-wired-lan at osuosl.org
> > https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
> Camille,
> My apologies, I wrong understand Alex. Please, do not try add delay. Please,
> check if you see same problem with different link partners.
> Thanks,
> Sasha
I tried to reproduce the issue with differents devices.
On computer side :
- HP ZBook 14u G5 (Intel NIC I219-V)
- Dell Tower 3620 (Intel NIC I219-LM)
On network side :
- TP-LINK TL-SG108E
- Advantech EKI-2728I
- Freebox v6 (https://en.wikipedia.org/wiki/Freebox)
It always happens with any configuration.
Thanks.
Camille Bordignon
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Intel-wired-lan] e1000e driver stuck at 10Mbps after reconnection
2018-08-08 15:00 ` Neftin, Sasha
@ 2018-09-07 6:28 ` Camille Bordignon
-1 siblings, 0 replies; 20+ messages in thread
From: Camille Bordignon @ 2018-09-07 6:28 UTC (permalink / raw)
To: Neftin, Sasha
Cc: Alexander Duyck, Netdev, intel-wired-lan, David S. Miller, linux-kernel
Le mercredi 08 août 2018 à 18:00:28 (+0300), Neftin, Sasha a écrit :
> On 8/8/2018 17:24, Neftin, Sasha wrote:
> > On 8/7/2018 09:42, Camille Bordignon wrote:
> > > Le lundi 06 août 2018 à 15:45:29 (-0700), Alexander Duyck a écrit :
> > > > On Mon, Aug 6, 2018 at 4:59 AM, Camille Bordignon
> > > > <camille.bordignon@easymile.com> wrote:
> > > > > Hello,
> > > > >
> > > > > Recently we experienced some issues with intel NIC (I219-LM
> > > > > and I219-V).
> > > > > It seems that after a wire reconnection, auto-negotation "fails" and
> > > > > link speed drips to 10 Mbps.
> > > > >
> > > > > From kernel logs:
> > > > > [17616.346150] e1000e: enp0s31f6 NIC Link is Down
> > > > > [17627.003322] e1000e: enp0s31f6 NIC Link is Up 10 Mbps Full
> > > > > Duplex, Flow Control: None
> > > > > [17627.003325] e1000e 0000:00:1f.6 enp0s31f6: 10/100 speed:
> > > > > disabling TSO
> > > > >
> > > > >
> > > > > $ethtool enp0s31f6
> > > > > Settings for enp0s31f6:
> > > > > Supported ports: [ TP ]
> > > > > Supported link modes: 10baseT/Half 10baseT/Full
> > > > > 100baseT/Half 100baseT/Full
> > > > > 1000baseT/Full
> > > > > Supported pause frame use: No
> > > > > Supports auto-negotiation: Yes
> > > > > Supported FEC modes: Not reported
> > > > > Advertised link modes: 10baseT/Half 10baseT/Full
> > > > > 100baseT/Half 100baseT/Full
> > > > > 1000baseT/Full
> > > > > Advertised pause frame use: No
> > > > > Advertised auto-negotiation: Yes
> > > > > Advertised FEC modes: Not reported
> > > > > Speed: 10Mb/s
> > > > > Duplex: Full
> > > > > Port: Twisted Pair
> > > > > PHYAD: 1
> > > > > Transceiver: internal
> > > > > Auto-negotiation: on
> > > > > MDI-X: on (auto)
> > > > > Supports Wake-on: pumbg
> > > > > Wake-on: g
> > > > > Current message level: 0x00000007 (7)
> > > > > drv probe link
> > > > > Link detected: yes
> > > > >
> > > > >
> > > > > Notice that if disconnection last less than about 5 seconds,
> > > > > nothing wrong happens.
> > > > > And if after last failure, disconnection / connection occurs again and
> > > > > last less than 5 seconds, link speed is back to 1000 Mbps.
> > > > >
> > > > > [18075.350678] e1000e: enp0s31f6 NIC Link is Down
> > > > > [18078.716245] e1000e: enp0s31f6 NIC Link is Up 1000 Mbps
> > > > > Full Duplex, Flow Control: None
> > > > >
> > > > > The following patch seems to fix this issue.
> > > > > However I don't clearly understand why.
> > > > >
> > > > > diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
> > > > > b/drivers/net/ethernet/intel/e1000e/netdev.c
> > > > > index 3ba0c90e7055..763c013960f1 100644
> > > > > --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> > > > > +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> > > > > @@ -5069,7 +5069,7 @@ static bool e1000e_has_link(struct
> > > > > e1000_adapter *adapter)
> > > > > case e1000_media_type_copper:
> > > > > if (hw->mac.get_link_status) {
> > > > > ret_val = hw->mac.ops.check_for_link(hw);
> > > > > - link_active = !hw->mac.get_link_status;
> > > > > + link_active = false;
> > > > > } else {
> > > > > link_active = true;
> > > > > }
> > > > >
> > > > > Maybe this is related to watchdog task.
> > > > >
> > > > > I've found out this fix by comparing with last commit that works fine :
> > > > > commit 0b76aae741abb9d16d2c0e67f8b1e766576f897d.
> > > > > However I don't know if this information is relevant.
> > > > >
> > > > > Thank you.
> > > > > Camille Bordignon
> > > >
> > > > What kernel were you testing this on? I know there have been a number
> > > > of changes over the past few months in this area and it would be
> > > > useful to know exactly what code base you started out with and what
> > > > the latest version of the kernel is you have tested.
> > > >
> > > > Looking over the code change the net effect of it should be to add a 2
> > > > second delay from the time the link has changed until you actually
> > > > check the speed/duplex configuration. It is possible we could be
> > > > seeing some sort of timing issue and adding the 2 second delay after
> > > > the link event is enough time for things to stabilize and detect the
> > > > link at 1000 instead of 10/100.
> > > >
> > > > - Alex
> > >
> > > We've found out this issue using Fedora 27 (4.17.11-100.fc27.x86_64).
> > >
> > > Then I've tested wth a more recent version of the driver v4.18-rc7 but
> > > behavior looks the same.
> > >
> > > Thanks for you reply.
> > >
> > > Camille Bordignon
> > > _______________________________________________
> > > Intel-wired-lan mailing list
> > > Intel-wired-lan@osuosl.org
> > > https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
> > >
> > I've agree with Alex. Let's try add 2s delay after a link event. Please,
> > let us know if it will solve your problem.
> > Also, I would like recommend try work with different link partner and
> > see if you see same problem.
> > _______________________________________________
> > Intel-wired-lan mailing list
> > Intel-wired-lan@osuosl.org
> > https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
> Camille,
> My apologies, I wrong understand Alex. Please, do not try add delay. Please,
> check if you see same problem with different link partners.
> Thanks,
> Sasha
Hello,
I recently figured out that neither the previous patch nor commit
0b76aae741abb9d16d2c0e67f8b1e766576f897d fix this issue.
In these cases, after reproducing the issue, when ethernet wire is connected
kernel logs mention full speed (1000 Mbps) but actually it seems it is not.
The problem persists.
I made some simple tests with a web browser and a dowload speed test
site (fast.com). As a result speed was always around 8 Mbps.
And again after a quick ethernet wire disconnection / reconnection, same
test is around 500 Mbps.
I feel very confused.
Camille Bordignon
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Intel-wired-lan] e1000e driver stuck at 10Mbps after reconnection
@ 2018-09-07 6:28 ` Camille Bordignon
0 siblings, 0 replies; 20+ messages in thread
From: Camille Bordignon @ 2018-09-07 6:28 UTC (permalink / raw)
To: intel-wired-lan
Le mercredi 08 ao?t 2018 ? 18:00:28 (+0300), Neftin, Sasha a ?crit :
> On 8/8/2018 17:24, Neftin, Sasha wrote:
> > On 8/7/2018 09:42, Camille Bordignon wrote:
> > > Le lundi 06 ao?t 2018 ? 15:45:29 (-0700), Alexander Duyck a ?crit :
> > > > On Mon, Aug 6, 2018 at 4:59 AM, Camille Bordignon
> > > > <camille.bordignon@easymile.com> wrote:
> > > > > Hello,
> > > > >
> > > > > Recently we experienced some issues with intel NIC (I219-LM
> > > > > and I219-V).
> > > > > It seems that after a wire reconnection, auto-negotation "fails" and
> > > > > link speed drips to 10 Mbps.
> > > > >
> > > > > ?From kernel logs:
> > > > > [17616.346150] e1000e: enp0s31f6 NIC Link is Down
> > > > > [17627.003322] e1000e: enp0s31f6 NIC Link is Up 10 Mbps Full
> > > > > Duplex, Flow Control: None
> > > > > [17627.003325] e1000e 0000:00:1f.6 enp0s31f6: 10/100 speed:
> > > > > disabling TSO
> > > > >
> > > > >
> > > > > $ethtool enp0s31f6
> > > > > Settings for enp0s31f6:
> > > > > ???????? Supported ports: [ TP ]
> > > > > ???????? Supported link modes:?? 10baseT/Half 10baseT/Full
> > > > > ???????????????????????????????? 100baseT/Half 100baseT/Full
> > > > > ???????????????????????????????? 1000baseT/Full
> > > > > ???????? Supported pause frame use: No
> > > > > ???????? Supports auto-negotiation: Yes
> > > > > ???????? Supported FEC modes: Not reported
> > > > > ???????? Advertised link modes:? 10baseT/Half 10baseT/Full
> > > > > ???????????????????????????????? 100baseT/Half 100baseT/Full
> > > > > ???????????????????????????????? 1000baseT/Full
> > > > > ???????? Advertised pause frame use: No
> > > > > ???????? Advertised auto-negotiation: Yes
> > > > > ???????? Advertised FEC modes: Not reported
> > > > > ???????? Speed: 10Mb/s
> > > > > ???????? Duplex: Full
> > > > > ???????? Port: Twisted Pair
> > > > > ???????? PHYAD: 1
> > > > > ???????? Transceiver: internal
> > > > > ???????? Auto-negotiation: on
> > > > > ???????? MDI-X: on (auto)
> > > > > ???????? Supports Wake-on: pumbg
> > > > > ???????? Wake-on: g
> > > > > ???????? Current message level: 0x00000007 (7)
> > > > > ??????????????????????????????? drv probe link
> > > > > ???????? Link detected: yes
> > > > >
> > > > >
> > > > > Notice that if disconnection last less than about 5 seconds,
> > > > > nothing wrong happens.
> > > > > And if after last failure, disconnection / connection occurs again and
> > > > > last less than 5 seconds, link speed is back to 1000 Mbps.
> > > > >
> > > > > [18075.350678] e1000e: enp0s31f6 NIC Link is Down
> > > > > [18078.716245] e1000e: enp0s31f6 NIC Link is Up 1000 Mbps
> > > > > Full Duplex, Flow Control: None
> > > > >
> > > > > The following patch seems to fix this issue.
> > > > > However I don't clearly understand why.
> > > > >
> > > > > diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
> > > > > b/drivers/net/ethernet/intel/e1000e/netdev.c
> > > > > index 3ba0c90e7055..763c013960f1 100644
> > > > > --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> > > > > +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> > > > > @@ -5069,7 +5069,7 @@ static bool e1000e_has_link(struct
> > > > > e1000_adapter *adapter)
> > > > > ???????? case e1000_media_type_copper:
> > > > > ???????????????? if (hw->mac.get_link_status) {
> > > > > ???????????????????????? ret_val = hw->mac.ops.check_for_link(hw);
> > > > > -?????????????????????? link_active = !hw->mac.get_link_status;
> > > > > +?????????????????????? link_active = false;
> > > > > ???????????????? } else {
> > > > > ???????????????????????? link_active = true;
> > > > > ???????????????? }
> > > > >
> > > > > Maybe this is related to watchdog task.
> > > > >
> > > > > I've found out this fix by comparing with last commit that works fine :
> > > > > commit 0b76aae741abb9d16d2c0e67f8b1e766576f897d.
> > > > > However I don't know if this information is relevant.
> > > > >
> > > > > Thank you.
> > > > > Camille Bordignon
> > > >
> > > > What kernel were you testing this on? I know there have been a number
> > > > of changes over the past few months in this area and it would be
> > > > useful to know exactly what code base you started out with and what
> > > > the latest version of the kernel is you have tested.
> > > >
> > > > Looking over the code change the net effect of it should be to add a 2
> > > > second delay from the time the link has changed until you actually
> > > > check the speed/duplex configuration. It is possible we could be
> > > > seeing some sort of timing issue and adding the 2 second delay after
> > > > the link event is enough time for things to stabilize and detect the
> > > > link at 1000 instead of 10/100.
> > > >
> > > > - Alex
> > >
> > > We've found out this issue using Fedora 27 (4.17.11-100.fc27.x86_64).
> > >
> > > Then I've tested wth a more recent version of the driver v4.18-rc7 but
> > > behavior looks the same.
> > >
> > > Thanks for you reply.
> > >
> > > Camille Bordignon
> > > _______________________________________________
> > > Intel-wired-lan mailing list
> > > Intel-wired-lan at osuosl.org
> > > https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
> > >
> > I've agree with Alex. Let's try add 2s delay after a link event. Please,
> > let us know if it will solve your problem.
> > Also, I would like recommend try work with different link partner and
> > see if you see same problem.
> > _______________________________________________
> > Intel-wired-lan mailing list
> > Intel-wired-lan at osuosl.org
> > https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
> Camille,
> My apologies, I wrong understand Alex. Please, do not try add delay. Please,
> check if you see same problem with different link partners.
> Thanks,
> Sasha
Hello,
I recently figured out that neither the previous patch nor commit
0b76aae741abb9d16d2c0e67f8b1e766576f897d fix this issue.
In these cases, after reproducing the issue, when ethernet wire is connected
kernel logs mention full speed (1000 Mbps) but actually it seems it is not.
The problem persists.
I made some simple tests with a web browser and a dowload speed test
site (fast.com). As a result speed was always around 8 Mbps.
And again after a quick ethernet wire disconnection / reconnection, same
test is around 500 Mbps.
I feel very confused.
Camille Bordignon
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Intel-wired-lan] e1000e driver stuck at 10Mbps after reconnection
2018-09-07 6:28 ` Camille Bordignon
@ 2018-09-11 8:31 ` Benjamin Poirier
-1 siblings, 0 replies; 20+ messages in thread
From: Benjamin Poirier @ 2018-09-11 8:31 UTC (permalink / raw)
To: Camille Bordignon
Cc: Neftin, Sasha, Alexander Duyck, Netdev, intel-wired-lan,
David S. Miller, linux-kernel
On 2018/09/07 08:28, Camille Bordignon wrote:
> Le mercredi 08 août 2018 à 18:00:28 (+0300), Neftin, Sasha a écrit :
> > On 8/8/2018 17:24, Neftin, Sasha wrote:
> > > On 8/7/2018 09:42, Camille Bordignon wrote:
> > > > Le lundi 06 août 2018 à 15:45:29 (-0700), Alexander Duyck a écrit :
> > > > > On Mon, Aug 6, 2018 at 4:59 AM, Camille Bordignon
> > > > > <camille.bordignon@easymile.com> wrote:
> > > > > > Hello,
> > > > > >
> > > > > > Recently we experienced some issues with intel NIC (I219-LM
> > > > > > and I219-V).
> > > > > > It seems that after a wire reconnection, auto-negotation "fails" and
> > > > > > link speed drips to 10 Mbps.
> > > > > >
[...]
>
> I recently figured out that neither the previous patch nor commit
> 0b76aae741abb9d16d2c0e67f8b1e766576f897d fix this issue.
>
> In these cases, after reproducing the issue, when ethernet wire is connected
> kernel logs mention full speed (1000 Mbps) but actually it seems it is not.
> The problem persists.
>
Hmm, so the newer (post 4110e02eb45e) kernels are actually "better", in
that they accurately report that link speed is 10Mb/s.
In the end, do you know of a kernel version that doesn't exhibit the
problem of slower actual link speed?
I had a look at the code and I tried to reproduce the problem on the
hardware that I have (I217) but could not.
Also, out of curiosity, have you tried playing with the speed, autoneg
and advertise settings via ethtool -s to force the link to 1000Mb/s?
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Intel-wired-lan] e1000e driver stuck at 10Mbps after reconnection
@ 2018-09-11 8:31 ` Benjamin Poirier
0 siblings, 0 replies; 20+ messages in thread
From: Benjamin Poirier @ 2018-09-11 8:31 UTC (permalink / raw)
To: intel-wired-lan
On 2018/09/07 08:28, Camille Bordignon wrote:
> Le mercredi 08 ao?t 2018 ? 18:00:28 (+0300), Neftin, Sasha a ?crit :
> > On 8/8/2018 17:24, Neftin, Sasha wrote:
> > > On 8/7/2018 09:42, Camille Bordignon wrote:
> > > > Le lundi 06 ao?t 2018 ? 15:45:29 (-0700), Alexander Duyck a ?crit :
> > > > > On Mon, Aug 6, 2018 at 4:59 AM, Camille Bordignon
> > > > > <camille.bordignon@easymile.com> wrote:
> > > > > > Hello,
> > > > > >
> > > > > > Recently we experienced some issues with intel NIC (I219-LM
> > > > > > and I219-V).
> > > > > > It seems that after a wire reconnection, auto-negotation "fails" and
> > > > > > link speed drips to 10 Mbps.
> > > > > >
[...]
>
> I recently figured out that neither the previous patch nor commit
> 0b76aae741abb9d16d2c0e67f8b1e766576f897d fix this issue.
>
> In these cases, after reproducing the issue, when ethernet wire is connected
> kernel logs mention full speed (1000 Mbps) but actually it seems it is not.
> The problem persists.
>
Hmm, so the newer (post 4110e02eb45e) kernels are actually "better", in
that they accurately report that link speed is 10Mb/s.
In the end, do you know of a kernel version that doesn't exhibit the
problem of slower actual link speed?
I had a look at the code and I tried to reproduce the problem on the
hardware that I have (I217) but could not.
Also, out of curiosity, have you tried playing with the speed, autoneg
and advertise settings via ethtool -s to force the link to 1000Mb/s?
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [Intel-wired-lan] e1000e driver stuck at 10Mbps after reconnection
2018-09-11 8:31 ` Benjamin Poirier
@ 2018-09-11 11:46 ` Camille Bordignon
-1 siblings, 0 replies; 20+ messages in thread
From: Camille Bordignon @ 2018-09-11 11:46 UTC (permalink / raw)
To: Benjamin Poirier
Cc: Neftin, Sasha, Alexander Duyck, Netdev, intel-wired-lan,
David S. Miller, linux-kernel
Le mardi 11 sept. 2018 à 17:31:47 (+0900), Benjamin Poirier a écrit :
> On 2018/09/07 08:28, Camille Bordignon wrote:
> > Le mercredi 08 août 2018 à 18:00:28 (+0300), Neftin, Sasha a écrit :
> > > On 8/8/2018 17:24, Neftin, Sasha wrote:
> > > > On 8/7/2018 09:42, Camille Bordignon wrote:
> > > > > Le lundi 06 août 2018 à 15:45:29 (-0700), Alexander Duyck a écrit :
> > > > > > On Mon, Aug 6, 2018 at 4:59 AM, Camille Bordignon
> > > > > > <camille.bordignon@easymile.com> wrote:
> > > > > > > Hello,
> > > > > > >
> > > > > > > Recently we experienced some issues with intel NIC (I219-LM
> > > > > > > and I219-V).
> > > > > > > It seems that after a wire reconnection, auto-negotation "fails" and
> > > > > > > link speed drips to 10 Mbps.
> > > > > > >
> [...]
> >
> > I recently figured out that neither the previous patch nor commit
> > 0b76aae741abb9d16d2c0e67f8b1e766576f897d fix this issue.
> >
> > In these cases, after reproducing the issue, when ethernet wire is connected
> > kernel logs mention full speed (1000 Mbps) but actually it seems it is not.
> > The problem persists.
> >
>
> Hmm, so the newer (post 4110e02eb45e) kernels are actually "better", in
> that they accurately report that link speed is 10Mb/s.
>
Exactly.
> In the end, do you know of a kernel version that doesn't exhibit the
> problem of slower actual link speed?
>
No. I've tried older version but at some point API has changed and
it fails to compile.
> I had a look at the code and I tried to reproduce the problem on the
> hardware that I have (I217) but could not.
>
> Also, out of curiosity, have you tried playing with the speed, autoneg
> and advertise settings via ethtool -s to force the link to 1000Mb/s?
Forcing the speed fixes the issue in any case (I mean even when speed is
wronly reported to 1000Mb/s).
Done this way:
#ethtool -s enp0s31f6 speed 1000 duplex full autoneg off
Thanks.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Intel-wired-lan] e1000e driver stuck at 10Mbps after reconnection
@ 2018-09-11 11:46 ` Camille Bordignon
0 siblings, 0 replies; 20+ messages in thread
From: Camille Bordignon @ 2018-09-11 11:46 UTC (permalink / raw)
To: intel-wired-lan
Le mardi 11 sept. 2018 ? 17:31:47 (+0900), Benjamin Poirier a ?crit :
> On 2018/09/07 08:28, Camille Bordignon wrote:
> > Le mercredi 08 ao?t 2018 ? 18:00:28 (+0300), Neftin, Sasha a ?crit :
> > > On 8/8/2018 17:24, Neftin, Sasha wrote:
> > > > On 8/7/2018 09:42, Camille Bordignon wrote:
> > > > > Le lundi 06 ao?t 2018 ? 15:45:29 (-0700), Alexander Duyck a ?crit :
> > > > > > On Mon, Aug 6, 2018 at 4:59 AM, Camille Bordignon
> > > > > > <camille.bordignon@easymile.com> wrote:
> > > > > > > Hello,
> > > > > > >
> > > > > > > Recently we experienced some issues with intel NIC (I219-LM
> > > > > > > and I219-V).
> > > > > > > It seems that after a wire reconnection, auto-negotation "fails" and
> > > > > > > link speed drips to 10 Mbps.
> > > > > > >
> [...]
> >
> > I recently figured out that neither the previous patch nor commit
> > 0b76aae741abb9d16d2c0e67f8b1e766576f897d fix this issue.
> >
> > In these cases, after reproducing the issue, when ethernet wire is connected
> > kernel logs mention full speed (1000 Mbps) but actually it seems it is not.
> > The problem persists.
> >
>
> Hmm, so the newer (post 4110e02eb45e) kernels are actually "better", in
> that they accurately report that link speed is 10Mb/s.
>
Exactly.
> In the end, do you know of a kernel version that doesn't exhibit the
> problem of slower actual link speed?
>
No. I've tried older version but at some point API has changed and
it fails to compile.
> I had a look at the code and I tried to reproduce the problem on the
> hardware that I have (I217) but could not.
>
> Also, out of curiosity, have you tried playing with the speed, autoneg
> and advertise settings via ethtool -s to force the link to 1000Mb/s?
Forcing the speed fixes the issue in any case (I mean even when speed is
wronly reported to 1000Mb/s).
Done this way:
#ethtool -s enp0s31f6 speed 1000 duplex full autoneg off
Thanks.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Intel-wired-lan] e1000e driver stuck at 10Mbps after reconnection
2019-01-03 21:28 Jan-Marek Glogowski
@ 2019-01-18 15:32 ` Jan-Marek Glogowski
0 siblings, 0 replies; 20+ messages in thread
From: Jan-Marek Glogowski @ 2019-01-18 15:32 UTC (permalink / raw)
To: intel-wired-lan
So I've updated both my test notebooks (U757 and U727).
Both latest BIOS + a new ME (11.8.55.3510) I got from Fujitsu.
"Unconfigured" ME in the BIOS - again, just in case.
I think 1000Mbps became more stable. But then I saw 10Mbps when I first connected the port late
during boot, way after the driver is loaded. Now that seems to be the most reliable way to trigger
the bug. Most time reconnect works keeping 1000 Mbits, which is definitely an improvement.
Just tested:
* unplug
* rmmod e1000e
* modprobe e1000e
* connect
* => always 10 Mbps
Still:
* plugged
* rmmod e1000e
* modprobe e1000e
* => always 1000 Mbps
On 10 MBits I can get back to 1000 Mbits, if I just unplug for a very short time, keeping the cable
still in the port; so maybe the poll worker doesn't yet kick in to break something?
No difference between 4.15 and 5.0-rc2 vanilla, FWIW.
My broken patch still works. I sometimes get a "0x40080003" and ignore that and then react to the
correct "0x80083". Compared to my other HW the 0x40000000 is just set in the "error" case, not always.
FWIW current intelmetool -m output diff is:
@@ -1,7 +1,7 @@
MEI found: [8086:9d3a] Sunrise Point-LP CSME HECI #1
ME Status : 0x90000245
-ME Status 2 : 0x89108106
+ME Status 2 : 0x89118106
ME: FW Partition Table : OK
ME: Bringup Loader Failure : NO
@@ -15,11 +15,11 @@
ME: Error Code : No Error
ME: Progress Phase : Clean Moff->Mx wake
ME: Power Management Event : Non-power cycle reset
-ME: Progress Phase State : Unknown 0x10
+ME: Progress Phase State : Unknown 0x11
ME: Extend Register not valid
-ME: Firmware Version 11.8.3425.50 (code) 11.8.3425.50 (recovery) 11.8.3425.50 (fitc)
+ME: Firmware Version 11.8.3510.55 (code) 11.8.3510.55 (recovery) 11.8.3425.50 (fitc)
ME Capability: Full Network manageability : ON
ME Capability: Regular Network manageability : OFF
And I tried to blacklist mei and mei_me kernel modules, not really expecting a change. Also no
difference.
I'm thinking of simply providing some kind of DMI-based-quirk to enable my special code path just
for this HW. I'm open for any additional suggestions.
Fujitsu has basically the same info and I'm waiting for an answer next week, as it's almost weekend.
I guess because of the 0x40000000 bit it's still a ME related problem.
Enough network plugging for this week. Hope I have more luck with my usb-c problem?
Jan-Marek
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Intel-wired-lan] e1000e driver stuck at 10Mbps after reconnection
@ 2019-01-03 21:28 Jan-Marek Glogowski
2019-01-18 15:32 ` Jan-Marek Glogowski
0 siblings, 1 reply; 20+ messages in thread
From: Jan-Marek Glogowski @ 2019-01-03 21:28 UTC (permalink / raw)
To: intel-wired-lan
Hi
I'm seeing the same problem as Camille Bordignon in August
https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20180806/013606.html
I'm on Ubuntu 18.04 (Kernel 4.15) and Ubuntu 12.04 + 14.04 HWE (Kernel 4.4).
My hardware is a Fujitsu laptop, u757 series, Skylake based.
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection I219-LM (rev 21)
Subsystem: Fujitsu Limited. Ethernet Connection I219-LM
Flags: bus master, fast devsel, latency 0, IRQ 128
Memory at c1200000 (32-bit, non-prefetchable) [size=128K]
Capabilities: [c8] Power Management version 3
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [e0] PCI Advanced Features
Kernel driver in use: e1000e
Kernel modules: e1000e
Almost always a reconnect brings the connection down to 10M. It seems to work correctly from an
initramfs, if no traffic is send (almost always). Starting the dhclient for the interface brings it
down on reconnect.
All the following stuff is from running the Ubuntu 4.20 vanilla kernel build and an extra patched
e1000e module. I've not yet compiled current master.
I put the following debug output into the module:
diff --git a/mac.c b/mac.c
index 4abd55d..7eae7ae 100644
--- a/mac.c
+++ b/mac.c
@@ -1308,6 +1308,7 @@ s32 e1000e_get_speed_and_duplex_copper(struct e1000_hw *hw, u16 *speed,
u32 status;
status = er32(STATUS);
+ pr_info("e1000e_get_speed_and_duplex_copper::status %x\n", status);
if (status & E1000_STATUS_SPEED_1000)
*speed = SPEED_1000;
else if (status & E1000_STATUS_SPEED_100)
diff --git a/netdev.c b/netdev.c
index 16a73bd..3016ac1 100644
--- a/netdev.c
+++ b/netdev.c
@@ -5070,6 +5070,7 @@ static bool e1000e_has_link(struct e1000_adapter *adapter)
if (hw->mac.get_link_status) {
ret_val = hw->mac.ops.check_for_link(hw);
link_active = !hw->mac.get_link_status;
+ pr_info("e1000e_has_link::check_for_link %i\n", ret_val);
} else {
link_active = true;
}
Some "evidence" I discovered:
* Link state is always correct when I have a link before module load (on boot or with rmmod + modprobe)
* It doesn't matter if I connect to a switch or simply cross-connect two U7x7
* Booting just the initramfs and re-connecting seems to work (very often) until data is transmitted.
From the debug info I took the following:
* The check_for_link is always 0 / ok.
* The working status is always 0x80083 and the broken most time 0x40080003. Once out of 50 I had a
0x80003 following the 0x40080003.
I also have some older Skylake HW (Fujitsu e737)
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection I219-V (rev 21)
Subsystem: Fujitsu Limited. Ethernet Connection I219-V
Flags: bus master, fast devsel, latency 0, IRQ 125
Memory at a1200000 (32-bit, non-prefetchable) [size=128K]
Capabilities: [c8] Power Management version 3
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [e0] PCI Advanced Features
Kernel driver in use: e1000e
Kernel modules: e1000e
where I couldn't reproduce with the problem with Ubuntu 12.04 + 14.04 HWE (Kernel 4.4).
If I remember correctly my colleague could reproduce the problem with the u727 hardware (should be
the same then u757, just smaller) and the 12.04 based installation (kernel 4.4). I will test this
tomorrow again with my u757 hardware.
There was some discussion about putting some sleep somewhere, which was later dropped again.
Is a status matching 0x40000000 valid? At least there isn't a definition for a match.
And I noticed the "PHYAD" value from ethtool changes. The rule of thumb it 1 with link and 2
without. It instantly changes to 2 on lost link, but it takes some time after a link to change back
to 1 after the auto-negotiation.
Jan-Marek
P.S. I also tired the following patch, after I found the duplicate code. Didn't change anything for
me and I don't know if the new check in e1000e_get_speed_and_duplex_copper is always correct.
From bcd0ec30383698f0da14a9f675ae7475175f979a Mon Sep 17 00:00:00 2001
From: Jan-Marek Glogowski <glogow@fbihome.de>
Date: Thu, 3 Jan 2019 22:11:25 +0100
Subject: [PATCH] e1000e: drop duplicate speed + duplex decoding code
Signed-off-by: Jan-Marek Glogowski <glogow@fbihome.de>
---
80003es2lan.c | 4 ++--
e1000.h | 2 +-
ethtool.c | 21 +++++----------------
hw.h | 2 +-
ich8lan.c | 8 +++++---
mac.c | 11 ++++++++---
mac.h | 4 ++--
7 files changed, 24 insertions(+), 28 deletions(-)
diff --git a/80003es2lan.c b/80003es2lan.c
index 257bd59..7779346 100644
--- a/80003es2lan.c
+++ b/80003es2lan.c
@@ -638,7 +638,7 @@ static s32 e1000_get_cable_length_80003es2lan(struct e1000_hw *hw)
* Retrieve the current speed and duplex configuration.
**/
static s32 e1000_get_link_up_info_80003es2lan(struct e1000_hw *hw, u16 *speed,
- u16 *duplex)
+ u8 *duplex)
{
s32 ret_val;
@@ -1068,7 +1068,7 @@ static s32 e1000_cfg_on_link_up_80003es2lan(struct e1000_hw *hw)
{
s32 ret_val = 0;
u16 speed;
- u16 duplex;
+ u8 duplex;
if (hw->phy.media_type == e1000_media_type_copper) {
ret_val = e1000e_get_speed_and_duplex_copper(hw, &speed,
diff --git a/e1000.h b/e1000.h
index c760dc7..190a4cd 100644
--- a/e1000.h
+++ b/e1000.h
@@ -200,7 +200,7 @@ struct e1000_adapter {
u32 rx_buffer_len;
u16 mng_vlan_id;
u16 link_speed;
- u16 link_duplex;
+ u8 link_duplex;
u16 eeprom_vers;
/* track device up/down/testing state */
diff --git a/ethtool.c b/ethtool.c
index 02ebf20..dafdeed 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -105,7 +105,8 @@ static int e1000_get_link_ksettings(struct net_device *netdev,
{
struct e1000_adapter *adapter = netdev_priv(netdev);
struct e1000_hw *hw = &adapter->hw;
- u32 speed, supported, advertising;
+ u32 supported, advertising;
+ u16 speed;
if (hw->phy.media_type == e1000_media_type_copper) {
supported = (SUPPORTED_10baseT_Half |
@@ -148,21 +149,9 @@ static int e1000_get_link_ksettings(struct net_device *netdev,
cmd->base.duplex = adapter->link_duplex - 1;
}
} else if (!pm_runtime_suspended(netdev->dev.parent)) {
- u32 status = er32(STATUS);
-
- if (status & E1000_STATUS_LU) {
- if (status & E1000_STATUS_SPEED_1000)
- speed = SPEED_1000;
- else if (status & E1000_STATUS_SPEED_100)
- speed = SPEED_100;
- else
- speed = SPEED_10;
-
- if (status & E1000_STATUS_FD)
- cmd->base.duplex = DUPLEX_FULL;
- else
- cmd->base.duplex = DUPLEX_HALF;
- }
+ if (!e1000e_get_speed_and_duplex_copper(hw, &speed,
+ &cmd->base.duplex))
+ cmd->base.speed = SPEED_UNKNOWN;
}
cmd->base.speed = speed;
diff --git a/hw.h b/hw.h
index eff75bd..d3c18ce 100644
--- a/hw.h
+++ b/hw.h
@@ -460,7 +460,7 @@ struct e1000_mac_operations {
void (*clear_vfta)(struct e1000_hw *);
s32 (*get_bus_info)(struct e1000_hw *);
void (*set_lan_id)(struct e1000_hw *);
- s32 (*get_link_up_info)(struct e1000_hw *, u16 *, u16 *);
+ s32 (*get_link_up_info)(struct e1000_hw *, u16 *, u8 *);
s32 (*led_on)(struct e1000_hw *);
s32 (*led_off)(struct e1000_hw *);
void (*update_mc_addr_list)(struct e1000_hw *, u8 *, u32);
diff --git a/ich8lan.c b/ich8lan.c
index cdae0ef..fd59970 100644
--- a/ich8lan.c
+++ b/ich8lan.c
@@ -998,7 +998,8 @@ static s32 e1000_platform_pm_pch_lpt(struct e1000_hw *hw, bool link)
u16 lat_enc = 0; /* latency encoded */
if (link) {
- u16 speed, duplex, scale = 0;
+ u16 speed, scale = 0;
+ u8 duplex;
u16 max_snoop, max_nosnoop;
u16 max_ltr_enc; /* max LTR latency encoded */
u64 value;
@@ -1386,7 +1387,8 @@ static s32 e1000_check_for_copper_link_ich8lan(struct e1000_hw *hw)
* the IPG and reduce Rx latency in the PHY.
*/
if ((hw->mac.type >= e1000_pch2lan) && link) {
- u16 speed, duplex;
+ u16 speed;
+ u8 duplex;
e1000e_get_speed_and_duplex_copper(hw, &speed, &duplex);
tipg_reg = er32(TIPG);
@@ -5074,7 +5076,7 @@ static s32 e1000_setup_copper_link_pch_lpt(struct e1000_hw *hw)
* gigabit speeds.
**/
static s32 e1000_get_link_up_info_ich8lan(struct e1000_hw *hw, u16 *speed,
- u16 *duplex)
+ u8 *duplex)
{
s32 ret_val;
diff --git a/mac.c b/mac.c
index 4abd55d..19c816c 100644
--- a/mac.c
+++ b/mac.c
@@ -1004,7 +1004,8 @@ s32 e1000e_config_fc_after_link_up(struct e1000_hw *hw)
s32 ret_val = 0;
u32 pcs_status_reg, pcs_adv_reg, pcs_lp_ability_reg, pcs_ctrl_reg;
u16 mii_status_reg, mii_nway_adv_reg, mii_nway_lp_ability_reg;
- u16 speed, duplex;
+ u16 speed;
+ u8 duplex;
/* Check for the case where we have fiber media and auto-neg failed
* so we had to force link. In this case, we need to force the
@@ -1303,11 +1304,15 @@ s32 e1000e_config_fc_after_link_up(struct e1000_hw *hw)
* speed and duplex for copper connections.
**/
s32 e1000e_get_speed_and_duplex_copper(struct e1000_hw *hw, u16 *speed,
- u16 *duplex)
+ u8 *duplex)
{
u32 status;
status = er32(STATUS);
+
+ if (!(status & E1000_STATUS_LU))
+ return 1;
+
if (status & E1000_STATUS_SPEED_1000)
*speed = SPEED_1000;
else if (status & E1000_STATUS_SPEED_100)
@@ -1337,7 +1342,7 @@ s32 e1000e_get_speed_and_duplex_copper(struct e1000_hw *hw, u16 *speed,
* for fiber/serdes links.
**/
s32 e1000e_get_speed_and_duplex_fiber_serdes(struct e1000_hw __always_unused
- *hw, u16 *speed, u16 *duplex)
+ *hw, u16 *speed, u8 *duplex)
{
*speed = SPEED_1000;
*duplex = FULL_DUPLEX;
diff --git a/mac.h b/mac.h
index 6ab2611..c4416e8 100644
--- a/mac.h
+++ b/mac.h
@@ -17,9 +17,9 @@ s32 e1000e_get_bus_info_pcie(struct e1000_hw *hw);
void e1000_set_lan_id_single_port(struct e1000_hw *hw);
s32 e1000e_get_hw_semaphore(struct e1000_hw *hw);
s32 e1000e_get_speed_and_duplex_copper(struct e1000_hw *hw, u16 *speed,
- u16 *duplex);
+ u8 *duplex);
s32 e1000e_get_speed_and_duplex_fiber_serdes(struct e1000_hw *hw,
- u16 *speed, u16 *duplex);
+ u16 *speed, u8 *duplex);
s32 e1000e_id_led_init_generic(struct e1000_hw *hw);
s32 e1000e_led_on_generic(struct e1000_hw *hw);
s32 e1000e_led_off_generic(struct e1000_hw *hw);
--
2.17.1
^ permalink raw reply related [flat|nested] 20+ messages in thread
end of thread, other threads:[~2019-01-18 15:32 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-08-06 11:59 e1000e driver stuck at 10Mbps after reconnection Camille Bordignon
2018-08-06 11:59 ` [Intel-wired-lan] " Camille Bordignon
2018-08-06 22:45 ` Alexander Duyck
2018-08-06 22:45 ` [Intel-wired-lan] " Alexander Duyck
2018-08-07 6:42 ` Camille Bordignon
2018-08-07 6:42 ` [Intel-wired-lan] " Camille Bordignon
2018-08-08 14:24 ` Neftin, Sasha
2018-08-08 14:24 ` Neftin, Sasha
2018-08-08 15:00 ` Neftin, Sasha
2018-08-08 15:00 ` Neftin, Sasha
2018-08-14 9:14 ` Camille Bordignon
2018-08-14 9:14 ` Camille Bordignon
2018-09-07 6:28 ` Camille Bordignon
2018-09-07 6:28 ` Camille Bordignon
2018-09-11 8:31 ` Benjamin Poirier
2018-09-11 8:31 ` Benjamin Poirier
2018-09-11 11:46 ` Camille Bordignon
2018-09-11 11:46 ` Camille Bordignon
2019-01-03 21:28 Jan-Marek Glogowski
2019-01-18 15:32 ` Jan-Marek Glogowski
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.