AFBR-89BDDZ QSFP28 liest im Vendor-Feld 0905000000000000, seit das SP/FPGA-Interface auf FIFO umgestellt wurde
Wir betreuen die Switch-Management-Firmware auf unserer eigenen Hardware, und seit das SP/FPGA-Interface von memory mapped Buffern auf ein FIFO umgestellt wurde, kommt die Transceiver-Inventur auf manchen Ports als Müll zurück.
- QSFP28-Optiken, alle AFBR-89BDDZ aus derselben Charge
- Reads laufen über den Service-Processor- und FPGA-Pfad zum Modul-EEPROM
- der Helfer auf der Host-Seite ist get_i2c_status_and_read_buffer: Status prüfen, ganzen Buffer lesen, Status erneut prüfen
Was wir statt Vendor-Daten bekommen:
one port, vendor field: 0905000000000000
the next port, vendor field: all ones
on another machine: vendor field all zeros, elsewhere repeated digit charactersWas wir bisher versucht haben:
- denselben Port mehrfach hintereinander neu gelesen, der Müll ist stabil pro Port statt zufälligem Rauschen
- Module stromlos gemacht und neu gestartet, kein Unterschied
- bestätigt, dass jedes Modul im Chassis dieselbe Teilenummer hat, das ist also kein Fehldecodieren irgendeines exotischen Vendor-Blocks unsererseits
Bevor wir anfangen, Optiken aus der Produktion zu ziehen: Sind eher die Module dran schuld, der I2C-Pfad, oder unser eigener Read-Helper?
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
Das zeigt eindeutig auf den Lesepfad, und der Grund ist die FIFO-Umstellung. Ein memory mapped Buffer liefert denselben Inhalt, egal wie oft man fragt; ein FIFO gibt jedes Byte genau einmal her, und dann ist es weg. Die Sequenz, die get_i2c_status_and_read_buffer geerbt hat, Status prüfen, ganzen Buffer lesen, Status erneut prüfen, ergab mit Speicher dahinter Sinn und ergibt mit einem FIFO keinen: Sie leert die Queue, während der EEPROM-Read des Moduls noch auf dem Draht unterwegs ist. Man bekommt, was in dem Moment gerade dalag, und die Bytes, die zu spät ankommen, bleiben liegen und tauchen beim nächsten Read auf.
Genau das ist der Fingerabdruck, den ihr beschreibt. Stabiler Müll pro Port, Korruption, die mit der Sequenz mitwandert, an einer Maschine alles Nullen, an einer anderen wiederholte Ziffernmuster, je nachdem, wie das Timing fällt. Nichts davon verlangt ein defektes Modul, und euer Tauschtest schließt die Optiken ohnehin aus.
Der Fix ist, den Aufrufer nicht länger für die Completion-Prüfung verantwortlich zu machen. Diese Verantwortung in die Read-Routine des Transceiver-Treibers selbst verlegen: Sie wartet, bis die I2C-Transaktion done meldet, und fasst den Buffer erst dann an, sodass kein Aufrufer ihn konstruktionsbedingt zu früh leeren kann. Nur eine einzelne Aufrufstelle zu patchen würde das Rennen nur woanders hinschieben.
Fairerweise der Hinweis, dass das die vorgeschlagene Form des Fixes ist und keine, die schon Jahre auf dem Buckel hat, also auf der eigenen Plattform validieren, bevor man der Inventur wieder traut. Eine billige Lektion zum Mitnehmen bleibt trotzdem: Verstümmelte Vendor-Strings verdienen zuerst einen Modul-gegen-Port-Test, denn die Lesereihenfolge ist weit häufiger der Schuldige als die Optik.
Die eine Messung, die das sauber teilt: Bleibt die Korruption beim Modul oder beim Port? Modul aus dem Port ziehen, der
0905000000000000liefert, mit einem Modul aus einem korrekt lesenden Port tauschen, und beide neu lesen. Folgt der schlechte String dem physischen Modul, dann die Optik ansehen. Bleibt er an der Portnummer hängen, oder wandert schlimmer noch zum jeweils nächsten gelesenen Modul weiter, sind die Module unschuldig und es ist ein Host-Read-Problem.Wo ihr schon dabei seid: die rohen EEPROM-Bytes zusammen mit den decodierten Feldern dumpen. Müll in einem decodierten Vendor-String bei sauberen Bytes darunter ist ein völlig anderer Bug als Müll in den Bytes selbst.
Den Tausch an einem Portpaar durchgeführt. Die schlechten Daten sind nicht mit dem Modul gewandert: Der Port, der
0905000000000000lieferte, lieferte das weiterhin mit einem anderen gesteckten Modul, und das gezogene Modul las in seinem neuen Slot einwandfrei.Noch aufschlussreicher: Als wir die Reihenfolge geändert haben, in der die Ports gelesen werden, ist die Korruption mit der Sequenz mitgewandert. Der Müll landet immer auf dem Modul, das nach dem fehlerhaften gelesen wird. Sie folgt also der Lesereihenfolge, nicht dem physischen Teil. Auch die rohen Bytes sind falsch, also ist es auf unserer Seite kein Decode-Problem.
Andere Grundursache, gleiche Falle, diesmal von der Treiberseite. Auf einem Intel E810-C mit dem out-of-tree ice 1.15.4 bekam ich aus
ethtool -mbei QSFP28-Optiken falsche und unvollständige Seiten: Page-1- und Page-3-Daten, Schwellwerte und Per-Lane-Monitore, stimmten nicht mit dem überein, was das Modul tatsächlich enthält. Eine saubere Root-Cause-Aussage habe ich nie bekommen, der Thread wurde ohne viele Details als gelöst geschlossen, also eher als Anekdote behandeln statt als Evangelium.Am Ende habe ich den ice-Treiber und die E810-NVM mit
nvmupdate64eaktualisiert, gegen einen Read vom In-Kernel-ice-Treiber auf einem anderen Host gegengeprüft und gezielt einzelne Seiten gezogen, mitplus explizitem Offset und Länge, statt der decodierten Ausgabe zu trauen. Wenn die eigene Plattform einen Rohdump kann: Raw gegen decodiert vergleichen, bevor man einem von beiden traut.
Es lohnt sich, die Schichten einmal auszubuchstabieren, das macht diese Art von Fehlersuche viel kürzer. Unter Linux decodiert
ethtool -mdas Modul-EEPROM (Vendor-Name, OUI, Teilenummer, Seriennummer, Datumscode und DDM-Werte, sofern das Modul welche hat),ethtool -edumpt die rohen Bytes, und wo der I2C-Bus zugänglich ist, liesti2cdump -y 1 0x50A0h undi2cdump -y 1 0x51A2h.In A0h liegt der Vendor-Name in den Bytes 20-35 und PN, Rev und SN in 40-59. Ist also das Vendor-Feld verstümmelt und die zwei Dutzend Bytes weiter liegende Teilenummer intakt, sagt das für sich schon, dass der Read zeitabhängig ist statt dass das EEPROM defekt wäre, was zu dem passt, was ihr seht.
Ein Fehlerbild, das man damit nicht verwechseln sollte:
ethtool -m, das Input/output error zurückgibt, ist meistens einfach ein Modul ohne DDM. Byte 92 Bit 6 von A0h ist das Flag dafür, ob A2h überhaupt vorhanden ist, und dieser Test wurde vor langer Zeit in die In-Kernel-Treiber ixgbe und bnx2x eingebaut, damit sie nicht nach weiteren 256 Bytes greifen, die es gar nicht gibt.Gleiche Problemgattung auf SONiC-Boxen, für alle, die von dieser Seite hier reinstolpern.
sfputil show eepromsagt bei manchen Modulen Cannot get Module EEPROM data: Invalid argument, oder widerspricht stillshow interfaces transceiver eepromauf demselben Port.Nach meiner Erfahrung sind das meistens Plattform- und Treiberlücken statt Optik: Die beiden Befehle benutzten im 202012-Branch inkonsistente Key-Namen, gefixt in 202205, manche Plattformen verlieren QSFP-Module aus sfputil nach einem Power-Cycle, bis ein Treiberfix landet, und auf anderen ist get_transceiver_info schlicht nicht implementiert. Wenn ich etwas brauche, dem ich beim Scripting traue, gehe ich zum optoe-Kernel-Treiber und lese SFP-, QSFP- oder CMIS-EEPROM selbst roh aus. Auf der eigenen Plattform trotzdem prüfen, das Verhalten schwankt zwischen ihnen stark.
Update von unserer Seite. Wir haben die Completion-Prüfung wie vorgeschlagen in die Read-Funktion des Treibers verlegt, und die Vendor-Strings waren über ein paar hundert Inventurläufe auf jedem Port korrekt, einschließlich der beiden Ports, die früher Müll untereinander getauscht haben. Rohe Bytes stimmen jetzt mit den decodierten Feldern überein.
Ich nenne das vorerst teilweise statt abgeschlossen: Wir führen es als Patch, der noch nicht in unserem Tree gelandet ist, und es gibt noch eine Plattform mit einem anderen FPGA-Build zu verifizieren, bevor wir es überall glauben. Aber die Optik war die ganze Zeit in Ordnung, das ist der Teil, den ich alleine falsch eingeschätzt hätte.