Bug 1038156 - Intel I218-LM picking 10mb instead of 1000mb
Intel I218-LM picking 10mb instead of 1000mb
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
20
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-12-04 09:18 EST by Havoc Pennington
Modified: 2015-02-02 23:06 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-03-17 14:44:19 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
dropwatch, ifacemon, logs from a lossy ping (23.96 KB, application/gzip)
2013-12-11 09:00 EST, Havoc Pennington
no flags Details

  None (edit)
Description Havoc Pennington 2013-12-04 09:18:39 EST
Description of problem:

Ethernet connects at 10Mb on the same cable/network that another laptop uses 1000Mb for.

00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I218-LM (rev 04)

This is on a thinkpad T440s.

Version-Release number of selected component (if applicable):

kernel-3.11.9-300.fc20.x86_64

How reproducible:

Don't know if it's somehow specific to my network, but just plug in the network cable (with wired connection set to automatic in networkmanager). Use ethtool or GNOME network settings, both show 10Mb/s.

Plug same cable into another laptop and it works fine (it picks 1000).
Comment 1 Michele Baldessari 2013-12-05 06:49:22 EST
Hi Havoc,

could you paste the relevant bits of 'lspci -vvvn -k' for this card?
Also the output of 'ethtool <iface>', 'ethtool -i <iface>' and 'ethtool -a <iface>'

Thanks,
Michele
Comment 2 Havoc Pennington 2013-12-05 09:25:43 EST
00:19.0 0200: 8086:155a (rev 04)
        Subsystem: 17aa:2214
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 63
        Region 0: Memory at f0600000 (32-bit, non-prefetchable) [size=128K]
        Region 1: Memory at f063e000 (32-bit, non-prefetchable) [size=4K]
        Region 2: I/O ports at 3080 [size=32]
        Capabilities: <access denied>
        Kernel driver in use: e1000e

Settings for enp0s25:
	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
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Advertised pause frame use: No
	Advertised auto-negotiation: Yes
	Speed: Unknown!
	Duplex: Unknown! (255)
	Port: Twisted Pair
	PHYAD: 2
	Transceiver: internal
	Auto-negotiation: on
	MDI-X: Unknown (auto)
Cannot get wake-on-lan settings: Operation not permitted
	Current message level: 0x00000007 (7)
			       drv probe link
	Link detected: no

$ ethtool -i enp0s25
driver: e1000e
version: 2.3.2-k
firmware-version: 0.6-3
bus-info: 0000:00:19.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

$ ethtool -a enp0s25
Pause parameters for enp0s25:
Autonegotiate:	on
RX:		on
TX:		on
Comment 3 Ferry Huberts 2013-12-05 11:04:34 EST
I don't have this problem on my T440s, I'm on F19, upgraded from F18. BIOS 2.14
Comment 4 Michele Baldessari 2013-12-05 17:22:11 EST
Hi Havoc,

could you try a 3.12 kernel or later. As those have:
commit 16b095a413fc6567a56e6e41909a8757e74acbc3
Author: Bruce Allan <bruce.w.allan@intel.com>
Date:   Sat Jun 29 07:42:39 2013 +0000

    e1000e: fix I217/I218 PHY initialization flow

You could try it from here:
http://alt.fedoraproject.org/pub/alt/rawhide-kernel-nodebug/x86_64/

Also, I see that ethtool returns speed unknown. Did you get the 10Mb from
mii-tool (and NM)? What does mii-tool output? 

thanks,
Michele
Comment 5 Havoc Pennington 2013-12-05 17:37:59 EST
I gathered the ethtool without a cable plugged in, apologies. I was in a meeting and needed to stay on wifi :-)

Here is the output with the link up. I'll try the kernel.


$ ethtool enp0s25
Settings for enp0s25:
	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
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Advertised pause frame use: No
	Advertised auto-negotiation: Yes
	Speed: 10Mb/s
	Duplex: Full
	Port: Twisted Pair
	PHYAD: 2
	Transceiver: internal
	Auto-negotiation: on
	MDI-X: on (auto)
Cannot get wake-on-lan settings: Operation not permitted
	Current message level: 0x00000007 (7)
			       drv probe link
	Link detected: yes

$ ethtool -i enp0s25
driver: e1000e
version: 2.3.2-k
firmware-version: 0.6-3
bus-info: 0000:00:19.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

$ ethtool -a enp0s25
Pause parameters for enp0s25:
Autonegotiate:	on
RX:		on
TX:		on
Comment 6 Havoc Pennington 2013-12-05 17:51:02 EST
(still on 3.11.9 kernel, rebooting into 3.12 shortly)

mii-tool says 100baseTx-FD interestingly, but ethtool at this same moment still says 10Mb/s.

$ sudo mii-tool --verbose enp0s25
enp0s25: negotiated 100baseTx-FD flow-control, link ok
  product info: vendor 00:55:00, model 10 rev 0
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  advertising:  1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
  link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
Comment 7 Havoc Pennington 2013-12-05 18:32:22 EST
Interesting. Now testing with 3.12.3-1.fc21.x86_64

1. It now reports 1000Mb/s
2. It still seems to not work

So, I didn't elaborate before about not working; the network connection was slow/lossy when it was reporting 10Mb/s, so web pages would mostly not load, and for example when pinging www.gnome.org it always dropped all packets after the 8th ping.

I was attributing this to the same problem as the 10Mb/s, but I guess it might be separate, because with 3.12.3 I get the right speed but still the failure to load pages and the ping breakdown. Here's a cut-and-paste from the terminal.

So maybe this is a new or different bug and the speed report is fixed, but the ethernet controller still seems wonky.

[hp@localhost tmp]$ # starting on wifi, ping works fine
[hp@localhost tmp]$ ping www.gnome.org
PING socket.gnome.org (91.189.93.3) 56(84) bytes of data.
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=1 ttl=48 time=139 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=2 ttl=48 time=162 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=3 ttl=48 time=184 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=4 ttl=48 time=104 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=5 ttl=48 time=127 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=6 ttl=48 time=149 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=7 ttl=48 time=102 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=8 ttl=48 time=194 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=9 ttl=48 time=114 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=10 ttl=48 time=136 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=11 ttl=48 time=159 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=12 ttl=48 time=182 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=13 ttl=48 time=204 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=14 ttl=48 time=125 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=15 ttl=48 time=147 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=16 ttl=48 time=170 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=17 ttl=48 time=192 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=18 ttl=48 time=112 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=19 ttl=48 time=134 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=20 ttl=48 time=157 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=21 ttl=48 time=179 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=22 ttl=48 time=202 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=23 ttl=48 time=122 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=24 ttl=48 time=144 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=25 ttl=48 time=103 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=26 ttl=48 time=163 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=27 ttl=48 time=110 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=28 ttl=48 time=133 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=29 ttl=48 time=103 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=30 ttl=48 time=179 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=31 ttl=48 time=110 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=32 ttl=48 time=121 ms
^C
--- socket.gnome.org ping statistics ---
32 packets transmitted, 32 received, 0% packet loss, time 31044ms
rtt min/avg/max/mdev = 102.590/146.211/204.596/31.548 ms
[hp@localhost tmp]$ ethtool enp0s25 | grep Speed
Cannot get wake-on-lan settings: Operation not permitted
	Speed: Unknown!
[hp@localhost tmp]$ # now plugging in the network cable, going on ethernet
[hp@localhost tmp]$ ethtool enp0s25 | grep Speed
Cannot get wake-on-lan settings: Operation not permitted
	Speed: 1000Mb/s
[hp@localhost tmp]$ # note with this kernel it does report 1000Mb/s
[hp@localhost tmp]$ ping www.gnome.org
PING socket.gnome.org (91.189.93.3) 56(84) bytes of data.
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=1 ttl=48 time=101 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=2 ttl=48 time=103 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=3 ttl=48 time=102 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=4 ttl=48 time=102 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=5 ttl=48 time=102 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=6 ttl=48 time=101 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=7 ttl=48 time=103 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=8 ttl=48 time=102 ms
^C
--- socket.gnome.org ping statistics ---
27 packets transmitted, 8 received, 70% packet loss, time 26010ms
rtt min/avg/max/mdev = 101.811/102.365/103.248/0.622 ms
[hp@localhost tmp]$ # failure after 8 pings seems consistent
[hp@localhost tmp]$ # wgets and firefox are hopeless too though, not just ping
[hp@localhost tmp]$ # still on ethernet
[hp@localhost tmp]$ ethtool enp0s25 | grep Speed
Cannot get wake-on-lan settings: Operation not permitted
	Speed: 1000Mb/s
[hp@localhost tmp]$ # unplugged cable here, back on wifi
[hp@localhost tmp]$ ethtool enp0s25 | grep Speed
Cannot get wake-on-lan settings: Operation not permitted
	Speed: Unknown!
[hp@localhost tmp]$ # ping works again
[hp@localhost tmp]$ # this is the exact same network, just wifi vs. ethernet
[hp@localhost tmp]$ ping www.gnome.org
PING socket.gnome.org (91.189.93.3) 56(84) bytes of data.
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=1 ttl=48 time=204 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=2 ttl=48 time=124 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=3 ttl=48 time=147 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=4 ttl=48 time=170 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=5 ttl=48 time=193 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=6 ttl=48 time=113 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=7 ttl=48 time=135 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=8 ttl=48 time=158 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=9 ttl=48 time=180 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=10 ttl=48 time=203 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=11 ttl=48 time=123 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=12 ttl=48 time=145 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=13 ttl=48 time=168 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=14 ttl=48 time=191 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=15 ttl=48 time=111 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=16 ttl=48 time=134 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=17 ttl=48 time=156 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=18 ttl=48 time=179 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=19 ttl=48 time=201 ms
64 bytes from cobalt.canonical.com (91.189.93.3): icmp_seq=20 ttl=48 time=121 ms
^C
--- socket.gnome.org ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19026ms
rtt min/avg/max/mdev = 111.358/158.279/204.535/30.687 ms
[hp@localhost tmp]$ uname -a
Linux localhost.localdomain 3.12.3-1.fc21.x86_64 #1 SMP Wed Dec 4 23:08:47 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Comment 8 Michele Baldessari 2013-12-07 05:35:07 EST
Hi Havoc,

ok, so the speed reporting issue, whatever it was, got fixed in 3.12. Let's
see what's up with the packet loss.

Can you start the following script before launching the ping on the wired
interface: http://people.redhat.com/~fleitner/ifacemon/ifacemon.sh

That will collect some stats that can clue us in.

Also before starting the ping, launch 'sudo dropwatch -l kas' and capture the output

Btw. Does /var/log/messages mention any watchdog nic hangs or somesuch?

Can you attach the output of dropwatch and ifacemon to this bz?

Thanks,
Michele
Comment 9 Havoc Pennington 2013-12-11 09:00:08 EST
Created attachment 835281 [details]
dropwatch, ifacemon, logs from a lossy ping
Comment 10 Havoc Pennington 2013-12-11 09:07:23 EST
I have the /var/log/messages during the ping in the tarball as logs.txt, there's also dropwatch.log and the directory ifacemon creates in there.

Two things made this tricky to collect:

1) the ping is not ALWAYS lossy (though it seems to be a matter of, you need some network activity before it starts to break... I've never had the network keep working for long enough to load more than one or two web pages so it is pretty easy to reproduce).

2) ctrl+C from ifacemon always rebooted the system.

I suppose 2) might be a clue pointing to some sort of bug, though whether it's the same bug I don't know.

There are probably things other than the ping mixed in to the dropwatch and ifacemon, since it's hard to track down and eliminate everything that might touch network.
Comment 11 Michele Baldessari 2013-12-26 16:16:41 EST
Hi Havoc,

apologies for the delay. 2) could be related yes although it is hard to say.
Did you see any oops messages with Ctrl-C? Any chance of a picture or to collect
a crash dump (https://fedoraproject.org/wiki/How_to_use_kdump_to_debug_kernel_crashes) ?

In ethtool -S we see zero drops or errors:
$ grep -i -E "err|drop" ethtool-S.log |grep -v ": 0$"
$

I see that in the timings of the script we have the following:
Wed Dec 11 08:44:58 EST 2013
Wed Dec 11 08:45:00 EST 2013
Wed Dec 11 08:45:02 EST 2013
Wed Dec 11 08:45:04 EST 2013
Wed Dec 11 08:45:06 EST 2013
Wed Dec 11 08:51:45 EST 2013
Wed Dec 11 08:51:47 EST 2013
Wed Dec 11 08:51:49 EST 2013
Wed Dec 11 08:51:51 EST 2013
Wed Dec 11 08:51:53 EST 2013
Wed Dec 11 08:51:55 EST 2013

I assume that between 08:45:06 and 08:51:45 the script was stopped and then restarted yes? (I assume that is when the laptop rebooted after the Ctrl-C)

Wed Dec 11 08:51:45 EST 2013        Wed Dec 11 08:51:45 EST 2013        
    858 segments received                rx_packets: 634
    892 segments send out                tx_packets: 994
    280 segments retransmited                         
Wed Dec 11 08:51:47 EST 2013        Wed Dec 11 08:51:47 EST 2013
    858 segments received                rx_packets: 634
    896 segments send out                tx_packets: 1000
    282 segments retransmited                         
Wed Dec 11 08:51:49 EST 2013        Wed Dec 11 08:51:49 EST 2013
    858 segments received                rx_packets: 634
    896 segments send out                tx_packets: 1003
    284 segments retransmited                         
Wed Dec 11 08:51:51 EST 2013        Wed Dec 11 08:51:51 EST 2013
    858 segments received                rx_packets: 634
    896 segments send out                tx_packets: 1003
    284 segments retransmited                         
Wed Dec 11 08:51:53 EST 2013        Wed Dec 11 08:51:53 EST 2013
    858 segments received                rx_packets: 634
    896 segments send out                tx_packets: 1005
    286 segments retransmited                         
Wed Dec 11 08:51:55 EST 2013        Wed Dec 11 08:51:55 EST 2013
    858 segments received                rx_packets: 634
    899 segments send out                tx_packets: 1009
    287 segments retransmited                         
Wed Dec 11 08:51:57 EST 2013        Wed Dec 11 08:51:57 EST 2013
    858 segments received                rx_packets: 634
    899 segments send out                tx_packets: 1010
    287 segments retransmited                         
Wed Dec 11 08:51:59 EST 2013        Wed Dec 11 08:51:59 EST 2013
    858 segments received                rx_packets: 634
    900 segments send out                tx_packets: 1014
    287 segments retransmited                         
Wed Dec 11 08:52:01 EST 2013        Wed Dec 11 08:52:01 EST 2013
    858 segments received                rx_packets: 634
    900 segments send out                tx_packets: 1016
    287 segments retransmited                         

I would have expected some of the errors counters in ethtool to increase tbh.
Given comment #3 is there a chance that there is a bios update around?

regards,
Michele
Comment 12 Justin M. Forbes 2014-02-24 09:01:38 EST
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs.

Fedora 20 has now been rebased to 3.13.4-200.fc20.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.
Comment 13 Justin M. Forbes 2014-03-17 14:44:19 EDT
*********** MASS BUG UPDATE **************

This bug has been in a needinfo state for several weeks and is being closed with insufficient data due to inactivity. If this is still an issue with Fedora 20, please feel free to reopen the bug and provide the additional information requested.
Comment 14 Kir Kolyshkin 2015-02-02 23:06:28 EST
I have the same issue as reported earlier in comment #7. For me, there are no pings (nor other network activity) for periods of 40 seconds or less (as can be easily seen with ping). Sometimes it works just fine, sometimes it dies intermittently. Nothing in logs. Tried changing both the Ethernet cable and the switch.

I am running Fedora 20 with kernel 3.17.8-200.fc20.x86_64 on a Lenovo T440s. Alas, now it is not reproducible, but it was half an hour ago.

Can provide any details once I'll be able to reproduce it.

Note You need to log in before you can comment on or make changes to this bug.