How to repair the checksum of the non-volatile memory (NVM) of Intel Ethernet Controller I219-V of an ASUS laptop?

Before trying my solution, please consider trying the one by ppparadox first.

---

With kind help from e1000-devel mailing list, here is how I fixed the NVM Checksum word using ethtool.

tl;dr: Basically, I first patched e1000e to have access to the Ethernet chip in Linux, and then used ethtool to read a value from the "checksummed" region of the NVM of my I219-V and then to write it back. The writing operation fixed the checksum.

To have acces to my Ethernet chip from Linux, I had to patch e1000e to skip NVM checksum validation. In file src/netdev.c, I changed the first line of

for (i = 0;; i++) {
    if (e1000_validate_nvm_checksum(&adapter->hw) >= 0)
        break;
    if (i == 2) {
        dev_err(pci_dev_to_dev(pdev),
            "The NVM Checksum Is Not Valid\n");
        err = -EIO;
        goto err_eeprom;
    }
}

into

for (i = 0; false; i++) {

(The whole block could also be just removed or commented out.)

Then I installed the patched module. From the /src directory I did:

sudo make install
sudo modprobe -r e1000e
sudo modprobe e1000e
sudo update-initramfs -u
reboot

Now the checksum validation was skipped and the Ethernet started working.

Before fixing the Checksum word, I looked into the outline of the NVM of I219 presented in Section 10 of Intel's datasheet. The use of Checksum word is explained in Section 10.3.2.2.

I noted the Checksum word before writing to the NVM:

$ sudo ethtool -e enp0s31f6 offset 0x7e length 2
Offset      Values
------      ------
0x007e:     60 13 

(enp0s31f6 is the name of my Ethernet interface.) Thus the erroneous Checksum word value was 0x1360.

I looked at the dump of NVM with sudo ethtool -e enp0s31f6 and then looked again at the byte at offset 0x10:

$ sudo ethtool -e enp0s31f6 offset 0x10 length 1
Offset      Values
------      ------
0x0010:     ff 

(Apparently any location would do, but I was told that in my case the value at offset 0x10 was not used at all, so it seemed "safer.")

For writing to the NVM (EEPROM) with ethtool, I needed a "magic key." I read Unbricking an Intel Pro/1000 (e1000) network interface and figured out that my magic key was 0x15708086 using lspci -nn:

$ lspci -nn | grep Ethernet
00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection I219-V [8086:1570] (rev 21)

Then I wrote 0xff back to offset 0x10 in the NVM:

$ sudo ethtool -E enp0s31f6 magic 0x15708086 offset 0x10 value 0xff

After comparing the dumps of the NVM before and after the write, I could see that, as expected, the only thing that changed was the Checksum word:

$ sudo ethtool -e enp0s31f6 offset 0x7e length 2
Offset      Values
------      ------
0x007e:     60 93 

The new value thus was 0x9360.

I booted a kernel with an unpatched e1000e, and the Ethernet port worked fine.

P.S. I find it a bit worrying that only the highest bit in the Checksum word was wrong.

I used bootutil for Linux from Intel (as suggested in the 2011 post) on an integrated Intel NIC on my Asus Z270-A to fix this error, without the recompiling and magic keys discussed in the upvoted answer. It worked great. I downloaded the tool from the Intel download site

chmod +x ./bootutil64e
sudo ./bootutil64e -NIC 1 -defcfg

I was getting the same error on Fedora 24 from e1000e driver with ASUS ROG MAXIMUS IX HERO motherboard which has Intel I219-V NIC adapter.

I find the accepted solution, that requires patching the NVM, too risky. It may render your hardware useless.

One safe solution is to apply the default configuration to the NIC using Intel Ethernet Connections Boot Utility. It works in Linux out of the box, no need to create a boot disk:

$ chmod +x bootutil64e
$ sudo ./bootutil64e -NIC=1 -DEFAULTCONFIG

That is it. Just reboot (or re-load e1000e driver manually).