Antes de probar mi solución, considere probar primero la de ppparadox.
Con la amable ayuda de e1000-devel lista de correo, así es como arreglé la NVM Palabra de suma de verificación usando ethtool .
tl;dr: Básicamente, primero parcheé e1000e para tener acceso al chip Ethernet en Linux y luego usé ethtool para leer un valor de la región "checksummed" de la NVM de mi I219-V y luego volver a escribirlo. La operación de escritura arregló la suma de verificación.
Para tener acceso a mi chip Ethernet desde Linux, tuve que parchear e1000e para omitir la validación de la suma de comprobación de NVM. En archivo src/netdev.c , cambié la primera línea de
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;
}
}
en
for (i = 0; false; i++) {
(Todo el bloque también podría eliminarse o comentarse).
Luego instalé el módulo parcheado. Desde el /src directorio que hice:
sudo make install
sudo modprobe -r e1000e
sudo modprobe e1000e
sudo update-initramfs -u
reboot
Ahora se omitió la validación de la suma de verificación y Ethernet comenzó a funcionar.
Antes de corregir la palabra Checksum, examiné el esquema de NVM de I219 presentado en la Sección 10 de la hoja de datos de Intel. El uso de la palabra Checksum se explica en la Sección 10.3.2.2.
Anoté la palabra Checksum antes de escribir a la NVM:
$ sudo ethtool -e enp0s31f6 offset 0x7e length 2
Offset Values
------ ------
0x007e: 60 13
(enp0s31f6 es el nombre de mi interfaz Ethernet). Por lo tanto, el valor erróneo de la palabra Checksum fue 0x1360 .
Miré el volcado de NVM con sudo ethtool -e enp0s31f6 y luego miró de nuevo el byte en el desplazamiento 0x10:
$ sudo ethtool -e enp0s31f6 offset 0x10 length 1
Offset Values
------ ------
0x0010: ff
(Aparentemente, cualquier ubicación funcionaría, pero me dijeron que en mi caso el valor en el desplazamiento 0x10 no se usó en absoluto, por lo que parecía "más seguro").
Para escribir en la NVM (EEPROM) con ethtool , necesitaba una "llave mágica". Leí Desbloqueo de una interfaz de red Intel Pro/1000 (e1000) y descubrí que mi llave mágica era 0x15708086 usando lspci -nn :
$ lspci -nn | grep Ethernet
00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection I219-V [8086:1570] (rev 21)
Luego escribí 0xff volver al desplazamiento 0x10 en la NVM:
$ sudo ethtool -E enp0s31f6 magic 0x15708086 offset 0x10 value 0xff
Después de comparar los volcados de la NVM antes y después de la escritura, pude ver que, como era de esperar, lo único que cambió fue la palabra Checksum:
$ sudo ethtool -e enp0s31f6 offset 0x7e length 2
Offset Values
------ ------
0x007e: 60 93
El nuevo valor por lo tanto fue 0x9360 .
Arranqué un kernel con un e1000e sin parchear y el puerto Ethernet funcionó bien.
PD Me parece un poco preocupante que solo el bit más alto en la palabra Checksum esté mal.
Usé bootutil para Linux de Intel (como se sugirió en la publicación de 2011) en una NIC Intel integrada en mi Asus Z270-A para corregir este error, sin las claves mágicas y de recompilación discutidas en la respuesta votada. Funcionó muy bien. Descargué la herramienta del sitio de descargas de Intel
chmod +x ./bootutil64e
sudo ./bootutil64e -NIC 1 -defcfg
Estaba recibiendo el mismo error en Fedora 24 de e1000e controlador con placa base ASUS ROG MAXIMUS IX HERO que tiene adaptador NIC Intel I219-V.
Considero que la solución aceptada, que requiere parchear la NVM, es demasiado arriesgada. Puede inutilizar su hardware.
Una solución segura es aplicar la configuración predeterminada a la NIC mediante la Utilidad de arranque de conexiones Intel Ethernet. Funciona en Linux desde el primer momento, no es necesario crear un disco de arranque:
$ chmod +x bootutil64e
$ sudo ./bootutil64e -NIC=1 -DEFAULTCONFIG
Eso es. Simplemente reinicie (o vuelva a cargar e1000e controlador manualmente).