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
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).
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-segmentatio n-offload (tso).