Intel I219-V Ethernet Interface on Ubuntu Linux Using e1000e Driver keeps Dropping Internet Connection

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1785171/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1785171

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Did this issue start happening after an update/upgrade? Was there a prior kernel version where you were not having this particular problem?

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.18 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.18-rc7

Thanks for the replies.

The "Internet dropping" issue started as soon as I installed this complete new Ubuntu Server 18.04 on the ASRock z370m Pro4 motherboard. Then added the GNOME Desktop, and had to change the Ethernet network configuration to use Netplan and NetworkManager service.

Note: I know the motherboard and the I219-V network interface work perfectly as the same new motherboard ran CentOS Server 7.4 (minimal) with an XFCE Desktop flawlessly for over a week. CentOS 7.4 uses NetworkManager service by default (unlike Ubuntu Server which does things very different than CentOS Server for the network connection. I only decided to try Ubuntu Server 18.04 to gain access to a package that had a newer version than CentOS Server had (CentOS focuses on stability over features and it shows).

I can't use the upstream Ubuntu kernel for fear too much of my server setup (Nvidia graphics, etc) will break. I've already seen bugs in the Nvidia graphics driver from the Ubuntu PPA (a separate issue), so I don't want to add more issues to this Ubuntu server setup. This Ethernet interface dropping Internet connectivity network issue is all I want to focus on right now.

Maybe this additional information will help:

*-network
       description: Ethernet interface
       product: Ethernet Connection (2) I219-V
       vendor: Intel Corporation
       physical id: 1f.6
       bus info: pci@0000:00:1f.6
       logical name: enp0s31f6
       version: 00
       serial: "removed"
       size: 1Gbit/s
       capacity: 1Gbit/s
       width: 32 bits
       clock: 33MHz
       capabilities: pm msi bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=e1000e driverversion=3.2.6-k duplex=full firmware=0.2-4 ip="removed" latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
       resources: irq:125 memory:df300000-df31ffff

dmesg | grep e1000e
[ 2.404883] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
[ 2.415926] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[ 2.427096] e1000e 0000:00:1f.6: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
[ 2.690764] e1000e 0000:00:1f.6 0000:00:1f.6 (uninitialized): registered PHC clock
[ 2.762812] e1000e 0000:00:1f.6 eth0: (PCI Express:2.5GT/s:Width x1) 70:85:c2:7d:b6:b5
[ 2.762813] e1000e 0000:00:1f.6 eth0: Intel(R) PRO/1000 Network Connection
[ 2.762867] e1000e 0000:00:1f.6 eth0: MAC: 12, PHY: 12, PBA No: FFFFFF-0FF
[ 2.866293] e1000e 0000:00:1f.6 enp0s31f6: renamed from eth0
[ 13.818417] e1000e: enp0s31f6 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx

Here's the logs from the NetworkManager service over the last few days.

Aug 01 03:47:21 t2trvs01 NetworkManager[1358]: <info> [1533109641.5958] manager: NetworkManager state is now CONNECTED_SITE
Aug 01 03:47:23 t2trvs01 NetworkManager[1358]: <info> [1533109643.5981] device (enp0s31f6): state change: activated -> deactivating (reason 'user-requested', sys-iface-state: 'managed')
Aug 01 03:47:23 t2trvs01 NetworkManager[1358]: <info> [1533109643.5986] manager: NetworkManager state is now DISCONNECTING
Aug 01 03:47:23 t2trvs01 NetworkManager[1358]: <info> [1533109643.6514] audit: op="device-disconnect" interface="enp0s31f6" ifindex=2 pid=2705 uid=1000 result="success"
Aug 01 03:47:23 t2trvs01 NetworkManager[1358]: <info> [1533109643.6517] device (enp0s31f6): state change: deactivating -> disconnected (reason 'user-requested', sys-iface-state: 'managed')
Aug 01 03:47:23 t2trvs01 NetworkManager[1358]: <info> [1533109643.6844] dhcp4 (enp0s31f6): canceled DHCP transaction, DHCP client pid 1840
Aug 01 03:47:23 t2trvs01 NetworkManager[1358]: <info> [1533109643.6845] dhcp4 (enp0s31f6): state changed bound -> done
Aug 01 03:47:23 t2trvs01 NetworkManager[1358]: <info> [1533109643.6853] manager: NetworkManager state is now DISCONNECTED
Aug 01 03:47:30 t2trvs01 NetworkManager[1358]: <info> [1533109650.9943] device (enp0s31f6): Activation: starting connection 'netplan-enp0s31f6' (0fb5685d-476e-39b6-8090-4f5b35b00deb)
Aug 01 03:47:30 t2trvs01 NetworkManager[1358]: <info> [1533109650.9944] audit: op="connection-activate" uuid="0fb5685d-476e-39b6-8090-4f5b35b00deb" name="netplan-enp0s31f6" pid=2705 uid=1000 result="s
Aug 01 03:47:30 t2trvs01 ...

Some more notes on Ubuntu 18.04 and Intel i219-v onboard wired ethernet interface performance.

The same problematic patterns continue with the dropping of the Internet connectivity through normal browser use (Chrome is more stable than Firefox). I have to disable and then re-enable the wired Ethernet interface, and then I can resume network activities again until the next connectivity drop.

I have multiple servers/work stations and multiple high speed Internet accesses to verify this new Ubuntu server's performance (commercial grade network and servers/work stations...I built them myself) and they (networking and Internet connectivity) are all 100% stable.

Keep in mind, I ran this same i219-v Ethernet interface under CentOS Server 7.4 for over a week (before converting the server to Ubuntu Server 18.04) and the network and Internet connectivity were 100% perfect on CentOS 7.4 with an Xfce desktop.

I did some more performance tests on this problematic Ubuntu 18.04 server and the i219-v performance.

I noticed the wired download speed on the Ubuntu 18.04 server via the i219-v NIC is half what it should be (verified by all the other computers on the network). The Ubuntu 18.04 server does not come close to matching the download speed on my high end laptop using the wifi. The wired upload speed on the i219-v on the Ubuntu 18.04 server is OK though.

This confirms to me that something is definitely not right with the new Ubuntu 18.04 server running this i219-v onboard NIC.

My review of similar reported issues with the i219-v on Linux (granted, on various Linux distributions, not necessarily Ubuntu) seem to indicate that some have resorted to using the Intel e1000e driver directly from the Intel site versus from the driver from the distribution.

Note: The is not Linux driver from Intel that specific supports the i219-v. Seems people use the e1000e driver anyway as that's all there is. The e1000e driver specs do state the i218-v is supported.

Here's the link to the Intel e1000e driver (for Linux) on the Intel site.

https://downloadcenter.intel.com/download/15817/Intel-Network-Adapter-Driver-for-PCIe-Intel-Gigabit-Ethernet-Network-Connections-Under-Linux-?product=71305

My Ubuntu Server 18.04 server currently packages the e1000e driver version 3.2.6-k

Intel's latest version of this Linux driver is version 3.4.0.2. Is there a package for this e1000e that Ubuntu has developed for the 18.04 distro based on 3.4.0.2 that can be installed so that I can test the performance of this version on my Ubuntu 18.04 server? (rather than me download it directly from Intel).

Basically a kernel issue like this requires kernel bisection, which includes testing on different kernel version.

We can't do much if we don't have the hardware and bisection is not an option.

Thanks for the reply.

Maybe I'm not correctly interpreting the reply referring to "a kernel issue like this requires kernel bisection" and "We can't do much if we don't have the hardware".

Why would the internet connectivity issues I'm seeing with Ubuntu 18.04 Server running the Intel onboard i219-v Ethernet adapter be a kernel issue?

As I've stated multiple times already, this i219-v Ethernet adapter ran perfectly on CentOS Server 7.4 for over a week (and we know CentOS is much more conservation with the Linux kernels used in their distribution) before I removed CentOS 7.4 and decided I'd given Ubuntu Server 18.04 a try and see where Ubuntu is at as a Linux server distribution vs CentOS.

Given my experience designing and building $B networks, this is not a hardware issue (very, very rare) and given CentOS Server 7.4 worked perfectly for everything expected of a server, including the network performance using this same i219-v Ethernet adaptor, it's most likely not a Linux kernel issue.

There's something in the way Ubuntu Server 18.04 is configured to use this Intel i219-v onboard network adaptor hardware that's the root of the issue. It's probably a scenario that Ubuntu Server 18.04 had probably not seen before and was never verified with (given what I know and have observed with how software is tested these days. My vendors constantly use us as a testing platform, but that's a separate story).

Again today, the network adaptor on the Ubuntu 18.04 server lost connectivity to the internet and I had to disconnect and then reconnect the wired Ethernet connnection to get the internet connection backup (simply, Network Manager service has to be stopped and then restarted, you can see it clearly in the logs I provided in a previous post).

What is Ubuntu support/development saying here? That Ubuntu Server 18.04 can't execute basic internet connectivity on the i219-v Ethernet adaptor in a 100% stable manner?

Obviously, there's others having issues with Ubuntu Server 18.04 and their network connectivity.

I prefer to use NetworkManager to control my wifi and wired Ethernet network interfaces. Ubuntu has a different view it seems (prefer networkd for wired interface, NetworkManager for wifi it seems), but there should be no bugs for those that choose to configure their systems to use NetworkManager. My networking hardware with NetworkManager is rock solid on CentOS Server 7.4, so I don't get why the network connectivity using NetworkManager is not stable for Ubuntu Server 18.04?

Please see the following string from this recent Ubuntu bug ticket opened with regards to the wired network interface not working properly with Ubuntu 18.04 (their is is mostly similar, though their road is slightly different in figuring out something is not right with Ubuntu 18.04 server and their network interface).

To sum this long bug post, the Ubuntu Server 18.04 implementation of NetworkManager is maybe not preferred, but it should be working perfectly on my Intel i219-v onboard network adapter.

https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1772859

There's a bug somewhere (e1000e driver, Ubuntu 18.04 implementation of NetworkManager, etc.) given the poor/strange performance I'm seeing on multiple fronts. Intermittent loss of internet connectivity and very, very poor download performance across my setup of the Intel i219-V onboard NI and the implementation of Netplan/NetworkManager on the Ubuntu Server 18.04 OS.

If it's not a bug (meaning a configuration like mine is proven 99.9999% stable using the scientific method through verification in the lab), then let's get the proper NetworkManager configuration information documented in detail on the Ubuntu wiki, so this same issue is not be brought up over and over again.

Please let me know if there is more help and info I can provide to get to this fixed and working properly as it should be.

The loss of the Internet connectivity on Ubuntu Server 18.04- continues to be an issue with the Intel i219-v onboard Ethernet adapter. I just lost the Internet connectivity on the Ubuntu 18.04 server and I was not even doing anything on the server.

I just logged in and the Internet connectivity had dropped. There's no way this should be happening if the OS/driver software was driving the Ethernet adaptor properly.

I've run several experiments over the last few weeks on the performance and stability with both the NetworkManager and networkd services. I was thinking that maybe the networkd implementation by Ubuntu Server was stable, but that's was a no go as well. Same behaviour as with NetworkManager.

I'm going to have to remove Ubuntu Server 18.04 (probably go back to CentOS Server 7.4) if Ubuntu Server 18.04 can't manage the required networking. Simply should not be an issue given the long-term proven technologies involved with Ethernet and IP networking.

Thanks.

Here is the syslog file from Aug. 21 the last time the ethernet connectivity on the i219-v onboard NIC disappeared and I had to manually disable and re-enable the network interface.

Let me know if you need anything else.

Here's the syslog from today. Had another drop network connection episode around around 9:40pm. same behaviour. Works Ok most of the day, often for a day or two, though the download speed on the speedtests is no where near where it should be (that's my indication that something is not configured right, I've never seen this before). Upload speed on the speedtests is fine though. I have to disable and then re-enable the ethernet interface to get the internet connection back when I notice there is no connectivity to the internet via a browser.

what are the next steps on this bug ticket? It still shows "incomplete" status?

Incomplete = reporter needs to give more information ??

I'm not sure how much more detailed information this original reporter can give on this i219-v nic performance issue with Ubuntu 18.04 server? Especially, when it's documented others have had NIC issues with Ubuntu 18.04 server.

Can someone please let me know what further is needed, or simply say there's nothing that can be done to fix the issue with Ubuntu 18.04 server. If there's nothing to be done on the Ubuntu side, please let me know and I can move on to a Linux distribution that can handle the i219-v NIC in a stable manner. Thanks.

Following up on that previous note about missing log files and asking to grant Launchpad access to our private systems.

I can't give Launchpad access to our private systems.

?? How do we go about working with someone to get this issue with the Intel i219-v ethernet controller fixed on Ubuntu 18.04? The issue has existing since day one of the install and continues to this day. Ethernet/Internet connectivity should be 100% staple on any OS.

There is a common issue on these I219-V systems which usually manifests when used in a dual-boot scenario with Windows.

In that case the Windows driver enables various power-management settings which, when rebooting into Linux without a cold-off, results in network problems. Most usually the Ethernet device brings the link up and can transmit packets but never receives packets.

My investigations showed this was caused by the receive side of the chip not having been woken up by the Linux driver in some way.

In those circumstances even ethtool didn't seem able to solve it (presumably the mainline e1000e driver doesn't do the correct thing).

The solution was always to disable the power-management options via Windows. There's an Arch Linux thread with a good discussion and screenshots of that issue at

https://bbs.archlinux.org/viewtopic.php?id=191981

See especially comment #8.

Whilst this may not be your issue it might give you some lead(s) to identify what is going on.

I'd also use "ethtool -k" to check the features enabled and investigation disabling all the "offload" functions one-by-one to see if those are to blame. I'd be especially suspicious of tcp-segmentation-offload (tso).

I eon't have problems with connectivity, but I hqve problems with speed. Iperf3 shows upload speed as normal(940mbps), but download speed is only 750mbps for some reason. I'm running Ubuntu 18.04.1, and Intel I219-V NIC. Please fix!

I'm getting this on a desktop with Kubuntu 18.10, though it started on 18.04. A disconnect using the network applet, wait a few seconds, connect brings it back till the next disconnect. I put up with it for months assuming it was due to something in the path to my router, but have isolated it back to the desktop. I"m usually watching YouTube with firefox, but it has happened with ktorrent and zsync.
There's no Windows dual boot.
ethto0l -k shows tcp-segmentation-offload off.

John,
If possible, please test latest mainline kernel and do kernel bisection so we can find the regression kernel commit.

I have the same problem on my desktop running Ubuntu 18.04, 18.10 and 19.04 with standard kernel and also in 19.04 with last mainline kernel. I don't have windows on my PC but multi-boot with other Ubuntu partitions.
corrado@corrado-p13-dd-1107-x:~$ inxi -Fx
System: Host: corrado-p13-dd-1107-x Kernel: 4.20.0-042000rc4-generic x86_64 bits: 64 compiler: gcc
           v: 8.2.0 Desktop: Gnome 3.30.1 Distro: Ubuntu 19.04 (Disco Dingo)
Machine: Type: Desktop Mobo: ASRock model: H110M-G/M.2 serial: <root required>
           UEFI: American Megatrends v: P1.10 date: 05/11/2017
CPU: Topology: Dual Core model: Intel Core i3-7100 bits: 64 type: MT MCP arch: Kaby Lake rev: 9
           L2 cache: 3072 KiB
           flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 31296
           Speed: 800 MHz min/max: 800/3900 MHz Core speeds (MHz): 1: 800 2: 800 3: 800 4: 800
Graphics: Device-1: Intel HD Graphics 630 vendor: ASRock driver: i915 v: kernel bus ID: 00:02.0
           Display: wayland server: X.Org 1.20.3 driver: i915 resolution: 1920x1080~60Hz
           OpenGL: renderer: Mesa DRI Intel HD Graphics 630 (Kaby Lake GT2) v: 4.5 Mesa 18.2.6
           direct render: Yes
Audio: Device-1: Intel 100 Series/C230 Series Family HD Audio vendor: ASRock Sunrise Point-H
           driver: snd_hda_intel v: kernel bus ID: 00:1f.3
           Sound Server: ALSA v: k4.20.0-042000rc4-generic
Network: Device-1: Intel Ethernet I219-V vendor: ASRock driver: e1000e v: 3.2.6-k port: f040
           bus ID: 00:1f.6
           IF: enp0s31f6 state: up speed: 100 Mbps duplex: full mac: 70:85:c2:44:7b:86
Drives: Local Storage: total: 931.51 GiB used: 10.12 GiB (1.1%)
           ID-1: /dev/sda vendor: Toshiba model: DT01ACA100 size: 931.51 GiB
Partition: ID-1: / size: 15.62 GiB used: 10.12 GiB (64.8%) fs: ext4 dev: /dev/sda13
           ID-2: swap-1 size: 8.00 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sda2
Sensors: System Temperatures: cpu: 31.0 C mobo: N/A
           Fan Speeds (RPM): N/A
Info: Processes: 211 Uptime: 1h 40m Memory: 7.50 GiB used: 1.36 GiB (18.2%) Init: systemd
           runlevel: 5 Compilers: gcc: 8.2.0 Shell: bash v: 4.4.19 inxi: 3.0.27
corrado@corrado-p13-dd-1107-x:~$

On my PC in different partitions I have various Ubuntu releases and I can run 'apport-collect 1785171'. In case I have to run it when the connection is dropped?
From a partition with standard kernel? or from the one with last mainline kernel?
thank you.

I cant run 'apport-collect 1785171' because i am not the creator of this bug. If i run ubuntu-bug xxx
what plan I have to put in xxx? Thanks

added some info about in my bug https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1806458

Some update comments on the issue with the Ubuntu 18.04 network connectivity that started as soon as I installed Ubuntu Server 18.04 with the motherboard using this Intel i219-v network adapter.

The issue is getting worse, not better. Previously the "drop" of the network connection with Ubuntu Server 18.04 would occur every 2 or 3 days. But now the drops are occurring multiple times daily. I don't even need to be using/doing anything on the machine anymore. The network connection will be fine once second and then down a minute later. The only way to get it back is to "disconnect" manually (in the Ubuntu software setting for the adapter) and then reconnect manually.

No dual boot system, etc. It's a plain as can be Linux server that right now is not of much use because the network connectivity (something that should be 100% stable) keeps cutting out.

I'm getting this on Ubuntu desktop 18.10 at work. It seems to be happening more and more often. Today it's up to 5 times within 2-3 hours. Currently I fix it by disconnecting and reconnecting the ethernet cable after af few seconds.
This is becomming rather painful.

I just bought Intel NUC8I5BEH and have also really annoying problems with Ethernet Connection (6) I219-V (device id 15be). Tried to install ubuntu 18.04 LTS version which _should_ be compatible with that NIC but immediately couple of seconds after connectinc network cable (or loading kernel module) ping latency starts increase to couple hundreds or thousand ms. Also some packet loss starts to occur. I verified that compiling intel driver and loading that kernel module fixed this ping problem so most propably there is problem in kernel driver which is included in 18.04.

Could someone else confirm this finding and it's relation to kernel module (ubuntu/intel)? I would really appreciate if someone can reproduce this ping issue with ubuntu 18.04 so I can be sure that there is no hardware issue in my Intel NUC.

I can confirm the ping latency problem

Network: Device-1: Intel driver: iwlwifi v: kernel port: N/A bus ID: 00:14.3
           IF: wlp0s20f3 state: up mac: 34:41:5d:7b:45:ad
           Device-2: Intel Ethernet I219-LM vendor: Hewlett-Packard driver: e1000e v: 3.2.6-k port: efa0 bus ID: 00:1f.6
           IF: enp0s31f6 state: up speed: 1000 Mbps duplex: full mac: b4:b6:86:e6:20:9f

i have a dual boot system with win10
disabling all power/ engrgy options in Windows-Driver seems to solve the problem!

I can confirm that this bug exists on 18.04 and 18.10 on a Intel NUC 8i3BEH (with latest BIOS, 0056). After a few seconds after boot, the RTT spikes to well over 1s and makes the system unusable.

Device:

00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (6) I219-V (rev 30)
 Subsystem: Intel Corporation Ethernet Connection (6) I219-V
 Flags: bus master, fast devsel, latency 0, IRQ 127
 Memory at c0100000 (32-bit, non-prefetchable) [size=128K]
 Capabilities: [c8] Power Management version 3
 Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
 Kernel driver in use: e1000e
 Kernel modules: e1000e

# ethtool -i eno1
driver: e1000e
version: 3.2.6-k
firmware-version: 0.4-4
expansion-rom-version:
bus-info: 0000:00:1f.6
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

Forcing the speed of the interface to 100 with autonegotiation off (via ethtool --change eno1 speed 100 autoneg off) helps somewhat - answer times stay around a few ms.

Since changing the power management settings seems to solve this issue, i tried various options: Disable intel_pstate, change the governor to performance, forcing full frequency, etc. without luck.

However, disabling PCIe ASPM *in the BIOS* solved the issue for me - at the price of a somewhat higher power consumption (around +5W).
Please note that using pcie_aspm=off in the kernel command line (linux-image-4.18.0-14-generic) *did not work*.

Here is the dmesg snippet with ASPM disabled in the BIOS:

# dmesg | grep -i aspm
[ 0.041040] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[ 0.177567] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[ 0.181078] acpi PNP0A08:00: FADT indicates ASPM is unsupported, using BIOS configuration

Please let me know, if you need more information.

I would like to add that I noticed quite weird connection between this issue and SD card reader in nuc. When the reader was disabled in bios, the issue persists and when it's enabled, the issue does not occur. More info here in the community thread in Intel forum: https://forums.intel.com/s/question/0D50P00004D4D6BSAV/really-weird-problem-in-ethernet-adapter-in-nuc8i5beh-help-needed-in-debugging

I returned my nuc so this is no more important for me, but clearly there is some bugs in device-bios-driver combo. Propably enabling sd card reader disables some power saving feture and because of tht the bug is not visible?

Hello:

I'm an ex-Ubuntu user and thought I'd add some information which may be useful.

I came across this thread while looking for answers to problems posed by the e1000e driver for my Sun Microsystems Ultra 24 on-board ethernet controller.

It's an Intel Corporation 82566DM-2 Gigabit Network Controller (rev 02), using the latest available driver for Linux (v.3.4.2.1 - 8/26/2018) provided by Intel under Devuan ASCII, 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux.

This driver is also used for many other Inter ethernet cards under Linux.

[quote=Tj]
[i]The solution was always to disable the power-management options via Windows.[/i]
[/quote]

Indeed ...
If only that *were* possible under Linux.

At least in *my* case (Devuan ASCII, v.3.4.2.1 e1000e driver and ethtool v.4.19), this has not been possible. It seems that as the driver is loaded as a module, ethtool cannot access the controller EEE settings.

ie:

[code]
# ethtool --show-eee eth0
Cannot get EEE settings: Operation not supported
#
# ethtool --set-eee eth0 eee off
Cannot get EEE settings: Operation not supported
#
[/code]

I have no doubt that the issues this e1000e driver has are originated in the power savings features which *do not* work properly.

Unfortunately, my attempts to get answers from Intel and Sourceforge with respect to this were non-productive.

See:
https://forums.intel.com/s/question/0D50P00004A4QxySAF/disabling-eee-on-82566dm2-gbe-controller?language=en_US

and

https://sourceforge.net/p/e1000/bugs/635/

Cheers,

A.

Hello,
same issue here on Ubuntu 18.04 with
driver: e1000e
version: 3.2.6-k
firmware-version: 0.5-4
expansion-rom-version:
bus-info: 0000:00:1f.6
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

I can change the EEE settings of the network adapter. But after a couple of minutes it still slows down to unusable.
# ethtool --show-eee eno2
EEE Settings for eno2:
 EEE status: disabled
 Tx LPI: 17 (us)
 Supported EEE link modes: 100baseT/Full
                            1000baseT/Full
 Advertised EEE link modes: 100baseT/Full
                             1000baseT/Full
 Link partner advertised EEE link modes: 100baseT/Full
                                          1000baseT/Full

Cheers,
Tjareson

I am having similar problems with Dell Optiplex 7060 running Ubuntu 18.04.2. I think the problem is connected with the chipset they are using since other machines are fine.

The network is extremely slow with the e1000e module provided by Ubuntu (3.2.6-k). Compiling the latest driver from Intel solves this, but I can not maintain this as a solution across all the clients.

# inxi -Nxxx
Network: Card: Intel Ethernet Connection (7) I219-LM
           driver: e1000e v: 3.2.6-k bus-ID: 00:1f.6 chip-ID: 8086:15bb

# speedtest
Testing download speed................................................................................
Download: 0.07 Mbit/s
Testing upload speed......................................................................................................
Upload: 488.32 Mbit/s

# inxi -Nxxx
Network: Card: Intel Ethernet Connection (7) I219-LM
           driver: e1000e v: 3.4.2.1-NAPI bus-ID: 00:1f.6 chip-ID: 8086:15bb

# speedtest
Testing download speed................................................................................
Download: 592.69 Mbit/s
Testing upload speed......................................................................................................
Upload: 633.40 Mbit/s

Was able to solve it as well with updated driver from Intel for a ThinkCentre M920x running with dual boot setup with win10:
filename: /lib/modules/4.15.0-46-generic/updates/drivers/net/ethernet/intel/e1000e/e1000e.ko
version: 3.4.2.1-NAPI
license: GPL
description: Intel(R) PRO/1000 Network Driver
author: Intel Corporation, <email address hidden>

But the effort of re-signing the driver in a secure boot setup for every update ahead seems not to be a feasible long term solution. So a solution of this issue would be still appreciated.

I may have stumbled on a workaround for the disconnection issue, though I can't be sure.

To narrow down the time when the connection stops working, I left a ping to my router running, every 4 seconds.

ping -i 4 192.168.1.1 > ping.log

Several days later, I rebooted, forgot about the ping, and had the connection fail a couple of times that day. Whenever the ping has been running, the problem has not occurred; but of course, the incidence of problems is sufficiently low that it might be a coincidence.

I faced problems with I219-V too.
I have a dual boot with Windows 10 setup.
was getting 10mb/s Lan Link speed.
The problem is resolved (working for now... I think) am seeing 100mb/s Link speed

Had to go into BIOS and disable Windows specific features in Advanced mode
changed CSM -> UEFI (Dont know what these do)
and disabled Fast Boot

Thanks TJ (comment #17 above)
Havent tried changing the Power management inside Windows (will try that next.. If BIOS change doesnt work)

fingers crossed

Motherboard : MSI z390 Gaming pro carbon AC
Bios : something.130 (Jan2019 update)

ProblemType: Bug
ApportVersion: 2.20.10-0ubuntu13.2
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: gio 1405 F.... pulseaudio
CurrentDesktop: KDE
DistroRelease: Ubuntu 18.10
InstallationDate: Installed on 2019-02-14 (35 days ago)
InstallationMedia: Kubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.2)
MachineType: LENOVO 20LW000XIX
Package: linux (not installed)
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.18.0-16-generic root=/dev/mapper/kubuntu--vg-root ro psmouse.elantech_smbus=0
ProcVersionSignature: Ubuntu 4.18.0-16.17-generic 4.18.20
RelatedPackageVersions:
 linux-restricted-modules-4.18.0-16-generic N/A
 linux-backports-modules-4.18.0-16-generic N/A
 linux-firmware 1.175.1
Tags: cosmic
Uname: Linux 4.18.0-16-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 01/21/2019
dmi.bios.vendor: LENOVO
dmi.bios.version: R0QET54W (1.31 )
dmi.board.asset.tag: Not Available
dmi.board.name: 20LW000XIX
dmi.board.vendor: LENOVO
dmi.board.version: SDK0J40697 WIN
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.modalias: dmi:bvnLENOVO:bvrR0QET54W(1.31):bd01/21/2019:svnLENOVO:pn20LW000XIX:pvrThinkPadL580:rvnLENOVO:rn20LW000XIX:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone:
dmi.product.family: ThinkPad L580
dmi.product.name: 20LW000XIX
dmi.product.sku: LENOVO_MT_20LW_BU_Think_FM_ThinkPad L580
dmi.product.version: ThinkPad L580
dmi.sys.vendor: LENOVO

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Please test this kernel, which disables TSO:
https://people.canonical.com/~khfeng/lp1785171/

>I may have stumbled on a workaround for the disconnection issue, though I can't be sure.
> To narrow down the time when the connection stops working, I left a ping to my router running, >every 4 seconds.
> ping -i 4 192.168.1.1 > ping.log

This is correct. Running an active ping probe mitigates the disconnection issue.

---

00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (7) I219-LM (rev 10)
 Subsystem: Hewlett-Packard Company Ethernet Connection (7) I219-LM
 Kernel driver in use: e1000e
 Kernel modules: e1000e

----

4.18.0-17-generic

----

Ubuntu 18.10

modinfo e1000e | grep -i version
------

version: 3.2.6-k
srcversion: 523CF030A04777C2DBD2CDC

my comment #37 above is nullified

It was a Hardware issue,
and so not an Ubuntu BUG

MDI-X is off
---------------------------------
> ethtool eno2
Settings for eno2:
 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: off (auto)
Cannot get wake-on-lan settings: Operation not permitted
 Current message level: 0x00000007 (7)
          drv probe link
 Link detected: yes

Some more information, somewhat related to this bug. I bought a NUC 8i5 with an Intel onboard Ethernet. Installed Ubuntu Server 19.04 on it, and quickly had poor networking speed: ping would rise to 600ms on the LAN (like, on the same switch as my computer) as soon as I tried to install something through apt. Resetting the interface would fix the ping on the LAN for SSH sessions, but as soon as a download would restart, the ping would rise again.

I downloaded the latest 3.4.2.1 driver from Intel (vs. the 3.2.6 driver included in Ubuntu Kernel), built it (commenting get_settings and set_settings, since it seems to have been removed) and it seems to have fixed the issue (consistent 0.4-1.1ms ping on LAN, no troubles downloading at full speed vs. being capped at 100KB/s in best-case scenario).

-----------------------------------
lshw:

        *-network:1
             description: Ethernet interface
             product: Ethernet Connection (6) I219-V
             vendor: Intel Corporation
             physical id: 1f.6
             bus info: pci@0000:00:1f.6
             logical name: eno1
             version: 30
             serial: 94:c6:91:af:3c:10
             width: 32 bits
             clock: 33MHz
             capabilities: bus_master cap_list ethernet physical
             configuration: broadcast=yes driver=e1000e driverversion=3.4.2.1-NAPI firmware=0.4-4

I had the same symptoms as in #58 on my Lenovo ThinkCentre M720q but running 18.04.2 desktop.

Built the latest Intel driver, signed and installed it and updated initramfs.
I've been running for half a day now without problems, when previously the symptoms would arise very quickly after boot.

  *-network
       description: Ethernet interface
       product: Ethernet Connection (7) I219-V
       vendor: Intel Corporation
       physical id: 1f.6
       bus info: pci@0000:00:1f.6
       logical name: eno1
       version: 10
       serial: e8:6a:64:75:06:75
       size: 1Gbit/s
       capacity: 1Gbit/s
       width: 32 bits
       clock: 33MHz
       capabilities: pm msi bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=e1000e driverversion=3.4.2.1-NAPI duplex=full firmware=0.5-4 ip=10.10.13.14 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
       resources: irq:134 memory:b1300000-b131ffff

nils,

Does mainline kernel still have this issue?

Kai-Heng,

I tested it with 4.20 from Ubuntu mainline at the time and it still had the issue. I think all ubuntu 4.x kernels ship with 3.2.6-k version of the e1000e module.
I haven't tested the 5.0 release yet though.

As an addition, my lenovo ThinkCentre M720q hasn't had any issues since I've updated to 3.4.2.1-NAPI.

I was experiencing this on multiple Ubuntu 18.04 servers with high UDP workload, I219-LM Ethernet, 4.15.0-50-generic Ubuntu kernel. Many events with "Detected Hardware Unit Hang" ... "Reset adapter unexpectedly" per day per server. The workaround suggested by the hosting provider does seem to help, 0 resets seen after disabling TSO & GSO:

    ethtool -K <interface> tso off gso off

I am seeing this on a Intel Corporation Ethernet Connection I218-V.

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.2 LTS"

Linux server 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24 10:55:24 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Jun 27 22:16:23 server kernel: [ 95.305441] ------------[ cut here ]------------
Jun 27 22:16:23 server kernel: [ 95.305445] NETDEV WATCHDOG: eno1 (e1000e): transmit queue 0 timed out
Jun 27 22:16:23 server kernel: [ 95.305481] WARNING: CPU: 3 PID: 0 at /build/linux-jmOa1Y/linux-4.15.0/net/sched/sch_generic.c:323 dev_watchdog+0x221/0x230
Jun 27 22:16:23 server kernel: [ 95.305482] Modules linked in: dm_crypt algif_skcipher af_alg nls_iso8859_1 ppdev intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass intel_cstate intel_rapl_perf input_leds serio_raw parport_pc snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic parport snd_hda_intel acpi_pad snd_hda_codec snd_hda_core snd_hwdep mei_me mei snd_pcm shpchp lpc_ich mac_hid snd_timer snd soundcore sch_fq_codel ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 btrfs zstd_compress raid10 raid0 multipath linear raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 hid_generic usbhid hid crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc i915 aesni_intel aes_x86_64 crypto_simd
Jun 27 22:16:23 server kernel: [ 95.305591] glue_helper mxm_wmi cryptd i2c_algo_bit drm_kms_helper syscopyarea e1000e sysfillrect sysimgblt fb_sys_fops ahci ptp drm libahci pps_core wmi video
Jun 27 22:16:23 server kernel: [ 95.305621] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.15.0-54-generic #58-Ubuntu
Jun 27 22:16:23 server kernel: [ 95.305623] Hardware name: MSI MS-7817/H97M ECO (MS-7817), BIOS V26.8 02/18/2016
Jun 27 22:16:23 server kernel: [ 95.305629] RIP: 0010:dev_watchdog+0x221/0x230
Jun 27 22:16:23 server kernel: [ 95.305631] RSP: 0018:ffff967b9eb83e58 EFLAGS: 00010286
Jun 27 22:16:23 server kernel: [ 95.305635] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006
Jun 27 22:16:23 server kernel: [ 95.305638] RDX: 0000000000000007 RSI: 0000000000000092 RDI: ffff967b9eb96490
Jun 27 22:16:23 server kernel: [ 95.305641] RBP: ffff967b9eb83e88 R08: 0000000000000001 R09: 000000000000044c
Jun 27 22:16:23 server kernel: [ 95.305643] R10: ffffdaca8f63f580 R11: 0000000000000000 R12: 0000000000000001
Jun 27 22:16:23 server kernel: [ 95.305646] R13: ffff967b80934000 R14: ffff967b80934478 R15: ffff967b81020880
Jun 27 22:16:23 server kernel: [ 95.305650] FS: 0000000000000000(0000) GS:ffff967b9eb80000(0000) knlGS:0000000000000000
Jun 27 22:16:23 server kernel: [ 95.305653] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jun 27 22:16:23 server kernel: [ 95.305655] CR2: 0000555b6574ea28 CR3: 000000025a40a006 CR4: 00000000001606e0
Jun 27 22:16:23 server kernel: [ 95.305658] Call Trace:
Jun 27 22:16:23 server kernel: [ 95.305662] <IRQ>
Jun 27 22:16:23 server kernel: [ 95.305671] ? dev_deactivate_queue.constprop.33+0x60/0x60
Jun 27 22:16:23 server kernel...

I am experimenting with disabling tso via ethtool now.

Disabling TSO does not resolve the issue.

Ok, please do a kernel bisection.

FYI a kernel bisection may be outside the skill set of your average user and chances are much lower without detailed instructions. Please don't shoot the messenger.

I too have a Asrock motherboard but a ASRock Z370M-ITX/ac. I had a lot off trouble getting my I219-V NICs to behave on Ubuntu.

I started on 18.04 and eventually went to 19.10 with the Intel e1000e 3.6.0-NAPI driver and a bunch of commands to get good performance.

File transfers were severely impacted but it is immediately obvious in iperf3 when the card is not performing properly.
Tweaking several of these options added several hundred Mbps to transfers giving a consistent 60MB/s over SMB but I'm still getting half the throughput of my Windows 10 workstation when talking to the same Ubuntu server. Given my Ubuntu client storage is 5X faster the cause is unknown.

I'm curious if anyone has figured out if the firmware version on the I219-V NIC is updateable and how. It's odd the same chip users different drivers and shows different firmware revisions.

$ ethtool -i enp2s0
driver: igb
version: 5.6.0-k
firmware-version: 0. 4-1
$ ethtool -i eno1
driver: e1000e
version: 3.6.0-NAPI
firmware-version: 0.2-4

It's really odd to be using two different drivers for the same NIC:
sudo lspci -v | grep -i ether
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2) I219-V
 DeviceName: Onboard - Ethernet
 Subsystem: ASRock Incorporation Ethernet Connection (2) I219-V
02:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03)

I have this in my rc.local now:
ethtool -A eno1 autoneg off tx off rx off 2> /dev/null || :
ethtool -K eno1 gso off tso off 2> /dev/null || :
ethtool -A enp2s0 autoneg off tx off rx off 2> /dev/null || :
ethtool --set-eee eno1 eee off 2> /dev/null || :
ethtool --set-eee enp2s0 eee off 2> /dev/null || :

1st line turns off flow control, 2nd turns off offloading specifically gso and tso, the last ones turn off a energy efficient Ethernet option.
Post tweaks I consistently get 935-958Mbit/s in perf3.

FYI in terms of sustainable options I was able to find a very hard to find .deb with the latest driver as a DKMS module. It works fine for me on Ubuntu 19.10. I really wish this was in a repository which was part of universe but I'm never figured out how to do things like that.

# dpkg -l | grep e1000e
ii e1000e-dkms 3.6.0 all Intel e1000e Ethernet adapter driver (DKMS version)

Details here: https://github.com/koljah-de/e1000e-dkms-debian

The latest V3.6.0 driver I use: https://github.com/koljah-de/e1000e-dkms-debian/releases/tag/3.6.0

I caveat this comment with an apology for not having any logs to share, but anecdotally, I was having this problem on a Thinkpad T460s, which has an i219-LM nic, running Ubuntu desktop 20.04 LTS. Wired network would disconnect on average every 20 minutes, sporadically, without warning. Made Zoom conferences very annoying, as I would drop out without warning, then have to re-login, reconnect to the conference room, and then pick up where we left off. Internet searches or clicking links would randomly turn up a "not connected" error page. There was no particular pattern I could ascertain as to when/why it would happen, it just did.

Then I upgraded to a Dell Precision 7730 laptop, which unfortunately has the same i219-LM nic. I installed my NVMe ssd from the Thinkpad T460s, so unsurprisingly, I had the same wireless network dropping issues. Unrelated, I installed .list files in /etc/apt/sources.list.d for 20.10 and 20.10-proposed so I could install more current qemu-kvm packages, and came across the linux-image-5.6-1021-oem package. The e1000e.ko contained within is is 3.2.6-k, which is a little outdated, but it doesn't drop connection so that doesn't particularly matter - it's infinitely less obnoxious to run.

The list file for the repo is: deb http://archive.ubuntu.com/ubuntu/ groovy-proposed restricted main multiverse universe and I run it pinned as priority 300 to avoid it installing anything that might break my system:

$ cat /etc/apt/preferences.d/proposed-updates
# Configure apt to allow selective installs of packages from proposed
Package: *
Pin: release a=groovy-proposed
Pin-Priority: 300

I also have a feeling the e1000e-dkms package would be a good fix, which might be attractive to someone wanting a newer version of the ko, but, as I have no interest in making my kernel installations take longer than they already do, I have not tried it.

FYI, I have been running on the latest version of this driver from Intel without issue for months now. It appears to be resolved in the upstream driver.

I have been using the latest version (3.8.4) from Intel without issue for about a week.

I can confirm this problem on the following platforms.

Intel NUC 8i5BEH with Ubuntu 18.04
Intel NUC 8i5BEH with Ubuntu 18.04 and the hardware enablement stack
Intel NUC 8i5BEH with Ubuntu 20.04
Intel NUC 10i7FNH with Ubuntu 18.04
Intel NUC 10i7FNH with Ubuntu 18.04 and the hardware enablement stack
Intel NUC 10i7FNH with Ubuntu 20.04

I can boot the system and after booting I can connect via SSH for a few minutes and then the connection is dropped. There is nothing on the log files on the client or the server.

I just wanted to mention I've been having disconnection issues w/ my i219-LM on both Thinkpad T460s and Dell Precision 7730 laptops in Ubuntu, sometimes disconnecting and reconnecting several times per hour (REALLY irritating).

I updated to linux-image-5.8.0-18-generic and haven't had any issues since AFAIK. It's in the groovy main repo. Also works w/ zfs 0.8.4-1.