Le champ vendor de l'AFBR-89BDDZ QSFP28 affiche 0905000000000000 après le passage de l'interface SP/FPGA à une FIFO
Nous nous occupons du firmware de gestion du switch sur notre propre matériel, et depuis que l'interface SP/FPGA est passée de tampons mappés en mémoire à une FIFO, l'inventaire des transceivers revient corrompu sur certains ports.
- optiques QSFP28, toutes des AFBR-89BDDZ issues du même lot
- les lectures passent par le chemin service processor et FPGA jusqu'à l'EEPROM du module
- côté hôte, la fonction utilitaire est get_i2c_status_and_read_buffer : vérifier le statut, lire tout le buffer, revérifier le statut
Ce que nous obtenons à la place des données vendor :
one port, vendor field: 0905000000000000
the next port, vendor field: all ones
on another machine: vendor field all zeros, elsewhere repeated digit charactersCe que nous avons essayé jusqu'ici :
- relire le même port plusieurs fois de suite, et le contenu erroné est stable par port plutôt qu'un bruit aléatoire
- coupé l'alimentation des modules, aucun changement
- confirmé que tous les modules du châssis ont la même référence, donc ce n'est pas nous qui décodons mal un bloc vendor exotique
Avant de commencer à retirer des optiques de la production, est-ce plus probablement les modules, le chemin I2C, ou notre propre fonction de lecture ?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 7
Cela pointe carrément vers le chemin de lecture, et le changement vers une FIFO en est la cause. Un tampon mappé en mémoire renvoie le même contenu peu importe le nombre de fois qu'on l'interroge ; une FIFO ne livre chaque octet qu'une seule fois, après quoi il a disparu. La séquence héritée par get_i2c_status_and_read_buffer, vérification du statut, lecture complète du buffer, nouvelle vérification du statut, avait du sens avec de la mémoire derrière et n'en a plus avec une FIFO : elle vide la file pendant que la lecture de l'EEPROM du module est encore en cours sur le bus. On obtient ce qui se trouvait là à cet instant précis, et les octets qui arrivent en retard restent en attente et réapparaissent à la lecture suivante.
C'est exactement la signature que vous décrivez. Un contenu erroné stable par port, une corruption qui se déplace avec la séquence, des zéros partout sur une machine et des motifs de chiffres répétés sur une autre selon la façon dont le timing tombe. Rien de tout cela n'exige un module défectueux, et votre résultat d'échange écarte de toute façon les optiques.
Le correctif consiste à ne plus faire reposer la vérification d'achèvement sur l'appelant. Il faut déplacer cette responsabilité à l'intérieur de la routine de lecture du driver du transceiver lui-même : elle attend que la transaction I2C signale qu'elle est terminée et ne touche au buffer qu'à ce moment-là, si bien qu'aucun appelant ne peut le vider prématurément, par construction. Corriger un seul point d'appel ne ferait que déplacer la course ailleurs.
Prévenez que c'est la forme proposée du correctif, pas quelque chose qui a des années de recul, donc validez-le sur votre propre plateforme avant de refaire confiance à l'inventaire. La leçon peu coûteuse à retenir tout de même : des chaînes vendor corrompues méritent d'abord un test module contre port, parce que l'ordre de lecture s'avère être le coupable bien plus souvent que les optiques.
La mesure qui tranche en deux : est-ce que la corruption reste avec le module ou avec le port ? Retirez le module du port qui renvoie
0905000000000000, échangez-le avec un module d'un port qui lit correctement, et relisez les deux. Si la chaîne erronée suit le module physique, allez examiner les optiques. Si elle reste sur le numéro de port, ou pire, se déplace vers le module lu ensuite, les modules sont innocents et vous avez un problème de lecture côté hôte.Pendant que vous y êtes, extrayez les octets bruts de l'EEPROM à côté des champs décodés. Une chaîne vendor décodée corrompue avec des octets sains en dessous est un bug totalement différent d'octets eux-mêmes corrompus.
Fait cet échange sur une paire de ports. Les données erronées n'ont pas suivi le module : le port qui renvoyait
0905000000000000a continué à le renvoyer avec un module différent inséré, et le module que nous avons retiré a été lu parfaitement dans son nouvel emplacement.Mieux encore, quand nous avons changé l'ordre de lecture des ports, la corruption s'est déplacée avec la séquence. Le contenu erroné atterrit sur le module qui est lu juste après celui qui pose problème. Ça suit donc l'ordre de lecture, pas la pièce physique. Les octets bruts sont faux eux aussi, donc ce n'est pas un problème de décodage de notre côté.
Cause racine différente, même piège, côté driver. Sur une Intel E810-C avec le driver ice 1.15.4 hors arbre, j'obtenais des pages fausses et incomplètes via
ethtool -msur des optiques QSFP28 : les données des pages 1 et 3, les seuils et les moniteurs par voie, ne correspondaient pas à ce que le module contenait réellement. Je n'ai jamais obtenu de véritable explication de la cause racine, le fil a été clos comme résolu sans beaucoup de détails, donc prenez ceci comme une anecdote plutôt qu'une vérité établie.Ce que j'ai fini par faire, c'est mettre à jour le driver ice et le NVM de l'E810 avec
nvmupdate64e, vérifier par recoupement avec une lecture faite via le driver ice intégré au noyau sur un autre hôte, et extraire des pages spécifiques avecplus un offset et une longueur explicites, au lieu de faire confiance à la sortie décodée. Si votre plateforme peut faire un dump brut, comparez le brut au décodé avant de croire l'un ou l'autre.
Ça vaut la peine de détailler les couches, car ça raccourcit beaucoup ce genre de chasse. Sous Linux,
ethtool -mdécode l'EEPROM du module (nom du vendor, OUI, référence, numéro de série, code date, et les valeurs DDM quand le module en dispose),ethtool -eextrait les octets bruts, et là où le bus I2C est exposé,i2cdump -y 1 0x50lit la page A0h tandis quei2cdump -y 1 0x51lit la page A2h.Dans A0h, le nom du vendor se trouve dans les octets 20-35 et le PN, la révision et le SN dans 40-59. Donc si le champ vendor est corrompu et que la référence, une vingtaine d'octets plus loin, est intacte, cela indique à lui seul que la lecture est dépendante du timing plutôt que l'EEPROM elle-même défectueuse, ce qui colle avec ce que vous observez.
Une panne à ne pas confondre avec celle-ci : quand
ethtool -mrenvoie Input/output error, c'est en général simplement un module sans DDM. Le bit 6 de l'octet 92 d'A0h est le drapeau indiquant si A2h existe seulement, et ce test a été ajouté depuis longtemps aux drivers ixgbe et bnx2x intégrés au noyau pour qu'ils arrêtent d'aller chercher 256 octets supplémentaires qui n'existent pas.Même genre de problème sur les boîtiers SONiC, pour quiconque arrive de ce côté-là.
sfputil show eepromrenvoie Cannot get Module EEPROM data: Invalid argument pour certains modules, ou est en désaccord silencieux avecshow interfaces transceiver eepromsur le même port.D'après ce que j'ai rencontré, ce sont surtout des lacunes de plateforme et de driver plutôt que les optiques : les deux commandes utilisaient des noms de clés incohérents dans la branche 202012, corrigé en 202205, certaines plateformes perdent les modules QSFP de sfputil après une coupure d'alimentation tant qu'un correctif de driver n'est pas déployé, et sur d'autres get_transceiver_info n'est tout simplement pas implémenté. Quand j'ai besoin de quelque chose de fiable pour du scripting, je passe par le driver noyau optoe et je fais moi-même des lectures brutes de l'EEPROM SFP, QSFP ou CMIS. Vérifiez quand même sur votre propre plateforme, le comportement varie beaucoup d'une à l'autre.
Mise à jour de notre côté. Nous avons déplacé la vérification d'achèvement dans la fonction de lecture du driver comme suggéré, et les chaînes vendor sont correctes sur tous les ports depuis plusieurs centaines de passages d'inventaire, y compris sur les deux ports qui échangeaient auparavant du contenu erroné entre eux. Les octets bruts correspondent maintenant aux champs décodés.
Je considère ceci comme partiel plutôt que clos pour le moment : nous le portons comme un correctif qui n'est pas encore intégré dans notre arbre, et il reste une plateforme avec une version de FPGA différente à vérifier avant qu'on lui fasse confiance partout. Mais les optiques étaient bonnes depuis le début, ce qui est la partie sur laquelle je me serais trompé tout seul.