Comment réparer la somme de contrôle de la mémoire non volatile (NVM) de Intel Ethernet Controller I219-V d'un ordinateur portable ASUS?
J'ai un problème avec un nouveau asuspro b8430ua ordinateur portable: sa Intel Ethernet Connection I219-V ne fonctionne pas sous Linux. En fait, j'ai essayé deux ordinateurs portables différents de ce modèle et les deux ont eu le même problème.
Le pilote Linux utilisé est E1000E , il produit les messages suivants pendant Linux (Ubuntu 16.04) Boot:
$ dmesg | grep e1000e
[ 5.643760] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
[ 5.643761] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[ 5.644308] e1000e 0000:00:1f.6: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
[ 5.877838] e1000e 0000:00:1f.6: The NVM Checksum Is Not Valid
[ 5.907340] e1000e: probe of 0000:00:1f.6 failed with error -5
J'ai essayé d'installer la dernière version 3.3.4 de E1000E, mais cela n'a pas aidé (j'ai contaminé le noyau, cependant).
J'ai posé des questions à ce sujet sur E1000-Devel Liste de diffusion, et il a été conseillé de contacter mon fabricant de l'ordinateur portable, car "le checksum NVM n'est pas Valide "signifie que le contenu de la mémoire non volatile de ma puce Ethernet est corrompu, ou du moins qu'il ne correspond pas à la somme de contrôle (malheureusement, je ne suis pas un spécialiste et ne peut pas l'expliquer plus précisément).
J'ai posé la question à un soutien client Intel, et ils ont répondu qu'ils ne s'occupent pas des systèmes OEM (jetons Ethernet intégrés dans des ordinateurs portables) et que je devrais contacter ASUS:
Malheureusement, comme votre système est OEM, nos options de support sont extrêmement limitées. Le fabricant de l'ordinateur portable peut avoir modifié le logiciel ou le matériel et c'est pourquoi la prise en charge et les pilotes de ces systèmes sont fournis directement par le fabricant de l'ordinateur portable.
J'ai contacté le support client ASUS, mais ils ont répondu qu'ils n'ont aucun outil de vérification ou de réparation du contenu de la NVM et que si je trouve ces outils, ils seraient heureux de savoir à ce sujet. Ils ont également expliqué qu'ils ne sont censés supporter que la configuration du matériel et du logiciel d'origine, et ce modèle d'ordinateur portable est vendu avec Windows 7. sous Windows 7, mon Ethernet semble fonctionner correctement. Selon ce que j'ai appris, Windows ne vérifie tout simplement pas la somme de contrôle NVM.
J'ai constaté que dans une affaire similaire en 2011, le problème pourrait être fixé à l'aide de Intel Ethernet Connections Boot Utility :
Cependant, la clause de non-responsabilité du dernier paragraphe avertit:
Vous devez probablement savoir que l'utilitaire de démarrage Intel (R) Ethernet Connections Ethernet n'a pas été conçu pour être utilisé à bord (également connu sous forme d'OEM) Cartes LAN (est pour les cartes PCI), donc il n'y a donc pas de moyen de prédire ses interactions avec d'autres à bord des composants comme des contrôleurs USB ou de son.
Le Description de la version de boottutil 1.6.13.0 semble également dire qu'il n'est pas exactement destiné à être utilisé avec des contrôleurs Ethernet à bord:
L'utilitaire de microprogramme Intel (R) Ethernet Flash (boottutil) est un utilitaire pouvant être utilisé pour programmer l'option PCI ROM sur la mémoire flash des adaptateurs réseau Intel PCI et PCI-Express et pour mettre à jour les configurations.
[...]
Les OEM peuvent fournir des images de micrologiciels Flash personnalisées pour les adaptateurs réseau OEM. Veuillez vous reporter aux instructions données par OEM.
Il y a cependant un paragraphe que je n'ai pas compris:
Les combinaisons d'images PXE + EFI et ISCSI + EFI sont prises en charge pour tous les adaptateurs génériques OEM, mais la prise en charge est limitée aux périphériques qui prennent en charge les technologies comme des images discrètes.
En plus, In Commentaire 5 sur un numéro de 2008 sur lequel le NVM devait être corrompu à cause d'un pilote E1000E BOG , il est conseillé:
Veuillez ne pas exécuter Ibautil comme certains sites sur le Web suggèrent d'essayer de résoudre ce problème. Cela vous fera probablement de devoir remplacer votre carte mère pour récupérer la fonctionnalité LAN.
Ibautil est l'un des prédécesseurs de boottutil.
Dans tous les cas, j'ai décidé d'exécuter Bottintil de sous Linux sans options de ligne de commande pour obtenir la "liste de tous les ports réseau Intel pris en charge que l'on trouve dans le système". C'est ce que j'ai:
$ Sudo ./bootutil64e
Intel(R) Ethernet Flash Firmware Utility
BootUtil version 1.6.13.0
Copyright (C) 2003-2016 Intel Corporation
Type BootUtil -? for help
Port Network Address Location Series WOL Flash Firmware Version
==== =============== ======== ======= === ============================= =======
1 D017C2201F59 0:31.6 Gigabit N/A FLASH Not Present
Je voudrais comprendre ce que "flash pas présent" signifie dans ce contexte et quelles options que j'ai pour la fixation de la somme de contrôle.
Mise à jour 1. Selon un commentaire que j'ai reçu de E1000-Devel liste de diffusion sur "Flash non présent",
Le flash et les NVM sont deux éléments distincts. Le flash permet des choses comme le démarrage de PXE et ISCSI, tandis que le NVM stocke des choses comme l'adresse réseau.
Mise à jour 2. J'ai trouvé Intel's Datasheet pour i219, section 10.3.3.2.2 CheckSum Calcul de mot dit:
Le mot checksum (mot 0x3f, octets NVM 0x7e et 0x7f) est utilisé pour garantir que l'image NVM de base est une image valide. La valeur de ce mot doit être calculée de telle sorte qu'après avoir ajouté tous les mots (0x00- 0x3f)/octets (0x00-0x7f), y compris le mot de contrôle lui-même, la somme devrait être 0xbaba. La valeur initiale dans le registre de sommation de 16 bits doit être 0x0000 et le bit de reportage doit être ignoré après chaque addition.
Avec aide aimable de ((( E1000-devel Liste de diffusion, voici comment j'ai corrigé le NVM Word de contrôle en utilisant ethtool .
Fondamentalement, je suis d'abord corrigé E1000E pour avoir accès à la puce Ethernet sous Linux, puis utilisé ethtool _ pour lire une valeur de la région "Christied" de la NVM de mon I219 -V, puis pour l'écrire. L'opération d'écriture fixe la somme de contrôle.
Pour avoir accès à ma puce Ethernet de Linux, j'ai dû patch E1000E pour ignorer la validation de la somme de contrôle NVM. Dans le fichier src/netdev.c, J'ai changé la première ligne 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;
}
}
dans
for (i = 0; false; i++) {
(L'ensemble du bloc pourrait également être simplement supprimé ou commenté.)
Ensuite, j'ai installé le module patché. Du /src répertoire j'ai fait:
Sudo make install
Sudo modprobe -r e1000e
Sudo modprobe e1000e
Sudo update-initramfs -u
reboot
Maintenant, la validation de la somme de contrôle a été ignorée et l'Ethernet a commencé à travailler.
Avant de résoudre le mot de contrôle, j'ai examiné le contour de la NVM de l'I219 présenté à la section 10 de l'Intel Fiche technique . L'utilisation du mot checkSum est expliquée à la section 10.3.2.2.
J'ai noté le mot checksum avant d'écrire sur la NVM:
$ Sudo ethtool -e enp0s31f6 offset 0x7e length 2
Offset Values
------ ------
0x007e: 60 13
(enp0s31f6 est le nom de mon interface Ethernet.) Ainsi, la valeur du mot checksum erroneux était 0x1360.
J'ai regardé la décharge de NVM avec Sudo ethtool -e enp0s31f6 Et ensuite regardé à nouveau à l'octet à la décalage 0x10:
$ Sudo ethtool -e enp0s31f6 offset 0x10 length 1
Offset Values
------ ------
0x0010: ff
(Apparemment, n'importe quel endroit ferait, mais on m'a dit que dans mon cas, la valeur de décalage 0x10 n'était pas utilisée du tout, il semblait donc "plus sûr".)
Pour écrire au NVM (EEPROM) avec ethtool, j'avais besoin d'une "clé magique". Je lis ((( interbriquetant d'une interface réseau Intel Pro/1000 (E1000) et a compris que ma clé magique était 0x15708086 à l'aide de lspci -nn:
$ lspci -nn | grep Ethernet
00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection I219-V [8086:1570] (rev 21)
Puis j'ai écrit 0xff Retour à Offset 0x10 dans la NVM:
$ Sudo ethtool -E enp0s31f6 magic 0x15708086 offset 0x10 value 0xff
Après avoir comparer les décharges de la NVM avant et après l'écriture, je pouvais voir que, comme prévu, la seule chose qui a changé était le mot de somme de contrôle:
$ Sudo ethtool -e enp0s31f6 offset 0x7e length 2
Offset Values
------ ------
0x007e: 60 93
La nouvelle valeur était donc 0x9360.
J'ai démarré un noyau avec un fichier non attribué E1000E , et le port Ethernet a fonctionné bien.
P.s. Je trouve cela un peu inquiet que seul le bit le plus élevé du mot de somme de contrôle était faux.
J'ai utilisé bootutil pour Linux d'Intel (comme suggéré dans le post 2011) sur un Intel intégré NIC sur mon ASUS Z270-A pour corriger cette erreur, sans la recompilation et la magie Touches discutées dans la réponse évitée. Cela a fonctionné super. J'ai téléchargé l'outil à partir du Site de téléchargement Intel
chmod +x ./bootutil64e
Sudo ./bootutil64e -NIC 1 -defcfg
J'avais la même erreur sur Fedora 24 de e1000e Driver avec la carte mère Asus Rog Maximus IX Hero qui a Intel I219-V NIC Adaptateur.
Je trouve la solution acceptée, qui nécessite de corriger la NVM, trop risquée. Cela peut rendre votre matériel inutile.
Une solution sûre consiste à appliquer la configuration par défaut sur NIC UTILISATION tilitaire de démarrage Intel EtherNet Connections . Il fonctionne sous Linux hors de la boîte, pas besoin de créer une démarrage. disque:
$ chmod +x bootutil64e
$ Sudo ./bootutil64e -NIC=1 -DEFAULTCONFIG
C'est ça. Juste redémarrer (ou réaménager e1000e conducteur manuellement).
essayer:
$ Sudo ./bootutil64e -NIC=XXX -BOOTENABLE=DISABLED.
Cela devrait faire l'affaire dans les versions récentes de bootutil64e.
J'ai eu la même erreur et je voulais tout essayer avant de jouer avec des bits NVM.
Je ne suis pas sûr que c'était ce que c'était ce que j'ai résolu le problème, mais la dernière chose que j'ai faite avant qu'elle a de nouveau fonctionné par magie était tentative de démarrer sur le réseau avec UEFI (IPv4). Ensuite, une magie noire doit avoir fixé mon NVM.
Environnement
- Mainboard: Asus Prime Z270-A (BIOS 0701)
- NIC:
00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection (2) I219-V [8086:15b8]
Ma solution est beaucoup plus simple:
- Entrez l'utilitaire UEFI BIOS;
- Entrer Mode avancé
- aller vers Configuration avancée\Network Stack et activez simplement la pile de réseau (je n'ai que compté uniquement IPv4 de rester en toute sécurité derrière mon NAT).
[.____] Redémarrez et profitez de votre carte réseau. Apparemment, cela suffit à effacer la mauvaise somme de contrôle NVM. Vous pouvez ensuite revenir en arrière et désactiver ladite pile.
Ceci est sous BIOS version 8001 sur une carte mère Asus Prime Z270-A (pilote E1000E sur Arch Linux, noyau 4.9.11-1).
[ Je me souviens de l'utilité demandant si cela pourrait activer la pile de réseau (qui est désactivée par défaut) afin de tenter la mise à jour.