Il campo vendor dell'AFBR-89BDDZ QSFP28 legge 0905000000000000 dopo che l'interfaccia SP/FPGA è passata a una FIFO
Ci occupiamo del firmware di gestione dello switch sul nostro hardware, e da quando l'interfaccia SP/FPGA è passata da buffer mappati in memoria a una FIFO, l'inventario dei transceiver torna spazzatura su alcune porte.
- ottiche QSFP28, tutte AFBR-89BDDZ dello stesso lotto
- le letture passano per il percorso service processor e FPGA fino all'EEPROM del modulo
- l'helper lato host è get_i2c_status_and_read_buffer: controlla lo stato, legge tutto il buffer, controlla di nuovo lo stato
Quello che otteniamo al posto dei dati vendor:
one port, vendor field: 0905000000000000
the next port, vendor field: all ones
on another machine: vendor field all zeros, elsewhere repeated digit charactersCosa abbiamo già provato:
- riletto la stessa porta più volte di fila, e la spazzatura è stabile per porta invece che rumore casuale
- fatto il power cycle dei moduli, nessuna differenza
- confermato che ogni modulo nello chassis ha lo stesso part number, quindi non siamo noi a decodificare male qualche blocco vendor esotico
Prima di iniziare a togliere ottiche dalla produzione, è più probabile che sia colpa dei moduli, del percorso I2C, o del nostro helper di lettura?
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
Questo punta dritto al percorso di lettura, e il cambio a FIFO è la ragione. Un buffer mappato in memoria restituisce lo stesso contenuto per quante volte lo chiedi; una FIFO cede ogni byte esattamente una volta e poi è sparito. La sequenza ereditata da get_i2c_status_and_read_buffer, controllo stato, lettura completa del buffer, controllo stato di nuovo, aveva senso con la memoria dietro e non ne ha con una FIFO: svuota la coda mentre la lettura dell'EEPROM del modulo è ancora sul filo. Ottieni qualsiasi cosa fosse lì in quell'istante, e i byte che arrivano in ritardo restano indietro e spuntano alla lettura successiva.
È esattamente l'impronta che descrivi. Spazzatura stabile per porta, corruzione che cammina insieme alla sequenza, tutti zeri su una macchina e pattern di cifre ripetute su un'altra a seconda di come cade il timing. Niente di tutto ciò richiede un modulo difettoso, e il tuo risultato con lo scambio esclude comunque le ottiche.
La correzione è smettere di rendere il chiamante responsabile del controllo di completamento. Sposta quella responsabilità dentro la routine di lettura del driver del transceiver stesso: aspetta che la transazione I2C segnali completata e solo allora tocca il buffer, così nessun chiamante può svuotarla in anticipo per costruzione. Sistemare un singolo punto di chiamata sposterebbe solo la race altrove.
Avviso onesto che questa è la forma proposta della correzione e non qualcosa con anni alle spalle, quindi validala sulla tua piattaforma prima di fidarti di nuovo dell'inventario. Lezione economica da portarsi a casa comunque: stringhe vendor sfasciate meritano prima un test modulo-contro-porta, perché l'ordine di lettura si rivela il colpevole molto più spesso delle ottiche.
La misura che taglia la cosa in due: la corruzione resta con il modulo o con la porta? Togli il modulo dalla porta che restituisce
0905000000000000, scambialo con un modulo di una porta che legge correttamente, e rileggi entrambe. Se la stringa sballata segue il modulo fisico, vai a guardare le ottiche. Se resta sul numero di porta, o peggio, si sposta su qualsiasi modulo venga letto dopo, i moduli sono innocenti e hai un problema di lettura lato host.Finché sei lì dentro, dumpa i byte grezzi dell'EEPROM insieme ai campi decodificati. Spazzatura in una stringa vendor decodificata con byte sensati sotto è un bug completamente diverso dalla spazzatura nei byte stessi.
Fatto quello scambio su una coppia di porte. I dati sballati non si sono spostati con il modulo: la porta che restituiva
0905000000000000continuava a restituirlo con un modulo diverso inserito, e il modulo che abbiamo tolto leggeva perfettamente nel suo nuovo slot.Meglio ancora, quando abbiamo cambiato l'ordine in cui le porte vengono lette, la corruzione si è spostata con la sequenza. La spazzatura finisce su qualsiasi modulo venga letto dopo quello che si comporta male. Quindi segue l'ordine di lettura, non il pezzo fisico. Anche i byte grezzi sono sbagliati, quindi non è un problema di decodifica dal nostro lato.
Causa radice diversa, stessa trappola, lato driver. Su un Intel E810-C con l'ice 1.15.4 out of tree ottenevo pagine sbagliate e incomplete da
ethtool -msu ottiche QSFP28: i dati di pagina 1 e pagina 3, soglie e monitor per lane, non corrispondevano a quello che il modulo conteneva davvero. Non sono mai arrivato a una vera dichiarazione di causa radice, il thread è stato chiuso come risolto senza molti dettagli, quindi prendila come aneddoto e non come verità assoluta.Quello che ho finito per fare è stato aggiornare il driver ice e l'NVM della E810 con
nvmupdate64e, verificare incrociando con una lettura dal driver ice in kernel su un altro host, e tirare fuori pagine specifiche conpiù offset e lunghezza espliciti, invece di fidarmi dell'output decodificato. Se la tua piattaforma può fare un dump grezzo, confronta il grezzo contro il decodificato prima di credere all'uno o all'altro.
Vale la pena spiegare i livelli, perché rende questo genere di caccia molto più breve. Su Linux
ethtool -mdecodifica l'EEPROM del modulo (nome vendor, OUI, part number, seriale, date code, e valori DDM quando il modulo li ha),ethtool -edumpa i byte grezzi, e dove il bus I2C è espostoi2cdump -y 1 0x50legge A0h mentrei2cdump -y 1 0x51legge A2h.In A0h il nome vendor vive nei byte 20-35 e PN, rev e SN nei 40-59. Quindi se il campo vendor è sfasciato e il part number due dozzine di byte più avanti è intatto, questo da solo dice che la lettura dipende dal timing invece che l'EEPROM sia difettosa, il che si sposa con quello che stai vedendo.
Un guasto da non confondere con questo:
ethtool -mche restituisce Input/output error di solito è solo un modulo senza DDM. Il bit 6 del byte 92 di A0h è il flag per se A2h esiste affatto, e quel controllo è stato messo nei driver ixgbe e bnx2x in kernel tanto tempo fa proprio perché smettessero di andare a cercare altri 256 byte che non esistono.Stesso genere di problema sulle scatole SONiC, per chi arriva da quella parte.
sfputil show eepromdice Cannot get Module EEPROM data: Invalid argument per certi moduli, oppure è silenziosamente in disaccordo conshow interfaces transceiver eepromsulla stessa porta.Da quello che ho incontrato sono per lo più lacune di piattaforma e driver piuttosto che delle ottiche: i due comandi usavano nomi di chiave incoerenti nel branch 202012 ed è stato corretto in 202205, alcune piattaforme perdono i moduli QSFP da sfputil dopo un power cycle finché non arriva una correzione al driver, e su altre get_transceiver_info semplicemente non è implementato. Quando mi serve qualcosa di cui fidarmi per lo scripting vado sul driver kernel optoe e faccio io stesso letture grezze dell'EEPROM SFP, QSFP o CMIS. Verificalo comunque sulla tua piattaforma, il comportamento varia parecchio da una all'altra.
Aggiornamento dal nostro lato. Abbiamo spostato il controllo di completamento dentro la funzione di lettura del driver come suggerito, e le stringhe vendor sono state corrette su ogni porta lungo qualche centinaio di passate di inventario, incluse le due porte che si scambiavano spazzatura a vicenda. I byte grezzi ora corrispondono ai campi decodificati.
Lo definisco parziale piuttosto che chiuso per il momento: lo portiamo avanti come una patch che non è ancora atterrata nel nostro albero, e c'è un'altra piattaforma con una build FPGA diversa da verificare prima di fidarcene ovunque. Ma le ottiche erano a posto fin dall'inizio, che è la parte su cui avrei sbagliato da solo.