AFBR-89BDDZ QSFP28 vendor field leest 0905000000000000 nadat de SP/FPGA-interface naar een FIFO is verhuisd
Wij onderhouden de switch-managementfirmware op onze eigen hardware, en sinds de SP/FPGA-interface is omgezet van memory mapped buffers naar een FIFO, komt de transceiver-inventarisatie op sommige poorten als rommel terug.
- QSFP28-optiek, allemaal AFBR-89BDDZ uit dezelfde batch
- reads lopen via het service-processor- en FPGA-pad naar de EEPROM van de module
- de helper aan de hostkant is get_i2c_status_and_read_buffer: status checken, hele buffer lezen, status opnieuw checken
Wat we in plaats van vendor-data krijgen:
one port, vendor field: 0905000000000000
the next port, vendor field: all ones
on another machine: vendor field all zeros, elsewhere repeated digit charactersWat we tot nu toe geprobeerd hebben:
- dezelfde poort meerdere keren achter elkaar opnieuw gelezen, en de rommel is stabiel per poort in plaats van willekeurige ruis
- de modules power-gecycled, geen verschil
- bevestigd dat elke module in het chassis hetzelfde partnummer heeft, dus dit is niet dat wij een of ander exotisch vendor-blok verkeerd decoderen
Voordat we optiek uit productie gaan trekken: is dit waarschijnlijker de modules, het I2C-pad, of onze eigen 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
Dat wijst regelrecht naar het leespad, en de FIFO-wijziging is de reden. Een memory mapped buffer geeft altijd dezelfde inhoud terug, hoe vaak je ook vraagt; een FIFO geeft elke byte precies één keer af en dan is hij weg. De volgorde die get_i2c_status_and_read_buffer heeft geërfd, status checken, hele buffer lezen, status opnieuw checken, was logisch met geheugen erachter en is dat niet met een FIFO: hij leegt de queue terwijl de EEPROM-read van de module nog onderweg is. Je krijgt wat er op dat moment toevallig lag, en de bytes die laat aankomen blijven achter en duiken op bij de volgende read.
Dat is precies de vingerafdruk die je beschrijft. Stabiele rommel per poort, corruptie die met de volgorde meeloopt, overal nullen op de ene machine en herhaalde cijferpatronen op de andere, afhankelijk van hoe de timing uitvalt. Niets daarvan vereist een kapotte module, en je swap-resultaat sluit de optiek toch al uit.
De fix is om de caller niet langer verantwoordelijk te maken voor de completion check. Verplaats die verantwoordelijkheid naar binnen in de read-routine van de transceiver-driver zelf: hij wacht tot de I2C-transactie klaar meldt en raakt de buffer pas dan aan, zodat geen enkele caller hem door de constructie zelf vroegtijdig kan leegtrekken. Eén enkele call site patchen zou de race gewoon ergens anders naartoe duwen.
Eerlijke waarschuwing dat dit de voorgestelde vorm van de fix is en niet iets met jaren ervaring erachter, dus valideer hem op je eigen platform voordat je de inventarisatie weer vertrouwt. Goedkope les om mee te nemen: verminkte vendor-strings verdienen eerst een module-versus-poort-test, want leesvolgorde blijkt veel vaker de boosdoener dan de optiek.
De ene meting die dit in tweeën splitst: blijft de corruptie bij de module of bij de poort? Haal de module uit de poort die
0905000000000000teruggeeft, wissel hem met een module uit een poort die correct leest, en lees beide opnieuw. Volgt de foute string de fysieke module, dan ligt het aan de optiek. Blijft hij op het poortnummer hangen, of erger nog, loopt hij mee naar welke module er hierna gelezen wordt, dan zijn de modules onschuldig en heb je een host-readprobleem.Dump, nu je er toch mee bezig bent, ook de raw EEPROM-bytes naast de gedecodeerde velden. Rommel in een gedecodeerde vendor-string met verstandige bytes eronder is een compleet andere bug dan rommel in de bytes zelf.
Die swap op een paar poorten uitgevoerd. De foute data verhuisde niet mee met de module: de poort die
0905000000000000teruggaf, bleef dat teruggeven met een andere module erin, en de module die we eruit haalden, las perfect in zijn nieuwe slot.Sterker nog, toen we de volgorde waarin de poorten gelezen worden veranderden, verhuisde de corruptie mee met de sequentie. De rommel komt terecht op welke module er ook gelezen wordt na degene die zich misdraagt. Dus hij volgt de leesvolgorde, niet het fysieke onderdeel. De raw bytes kloppen ook niet, dus het is geen decodeerprobleem aan onze kant.
Andere hoofdoorzaak, zelfde valkuil, maar dan aan de driverkant. Op een Intel E810-C met de out-of-tree ice 1.15.4 kreeg ik foute en onvolledige pagina's uit
ethtool -mop QSFP28-optiek: page 1- en page 3-data, thresholds en per-lane monitors kwamen niet overeen met wat de module werkelijk bevat. Ik heb er nooit een fatsoenlijke root-causeverklaring voor gekregen, de thread werd als opgelost gesloten zonder veel detail, dus behandel dit als anekdote en niet als waarheid.Wat ik uiteindelijk deed was de ice-driver en de E810-NVM bijwerken met
nvmupdate64e, kruislings controleren tegen een read van de in-kernel ice-driver op een andere host, en specifieke pagina's ophalen metplus expliciete offset en lengte, in plaats van te vertrouwen op de gedecodeerde output. Kan jouw platform een raw dump maken, vergelijk dan raw tegen gedecodeerd voordat je een van beide gelooft.
De moeite waard om de laagverdeling even uit te leggen, want dat maakt dit soort speurtocht een stuk korter. Op Linux decodeert
ethtool -mde EEPROM van de module (vendor name, OUI, part number, serial, date code, en DDM-waarden als de module die heeft),ethtool -edumpt de raw bytes, en waar de I2C-bus toegankelijk is leesti2cdump -y 1 0x50A0h terwijli2cdump -y 1 0x51A2h leest.In A0h staat de vendor name in bytes 20-35 en PN, rev en SN in 40-59. Is het vendor-veld dus verminkt terwijl het partnummer een paar dozijn bytes verderop intact is, dan zegt dat op zichzelf al dat de read timing-afhankelijk is in plaats van dat de EEPROM stuk is, en dat past bij wat jij ziet.
Één storing om niet met deze te verwarren:
ethtool -mdat Input/output error teruggeeft is meestal gewoon een module zonder DDM. Byte 92 bit 6 van A0h is de vlag voor of A2h er überhaupt is, en die test zit al lang in de in-kernel ixgbe- en bnx2x-drivers zodat ze niet nog eens 256 bytes proberen op te halen die niet bestaan.Zelfde soort probleem op SONiC-boxen, voor wie daarvandaan binnenloopt.
sfputil show eepromzegt Cannot get Module EEPROM data: Invalid argument bij bepaalde modules, of is het stilletjes oneens metshow interfaces transceiver eepromop dezelfde poort.Voor zover ik het heb meegemaakt zijn het vooral platform- en drivergaten, niet de optiek: de twee commando's gebruikten inconsistente key-namen in de 202012-branch en dat is in 202205 gefixt, sommige platformen raken QSFP-modules kwijt uit sfputil na een power cycle totdat er een driverfix landt, en bij andere is get_transceiver_info gewoon niet geïmplementeerd. Als ik iets nodig heb dat ik voor scripting kan vertrouwen, ga ik naar de optoe kernel-driver en doe ik zelf raw reads van de SFP-, QSFP- of CMIS-EEPROM. Check het wel op je eigen platform, het gedrag verschilt behoorlijk tussen ze.
Update van onze kant. We hebben de completion check verplaatst naar de read-functie van de driver zoals voorgesteld, en de vendor-strings zijn nu correct op elke poort over een paar honderd inventarisatierondes, inclusief de twee poorten die vroeger rommel met elkaar uitwisselden. Raw bytes komen nu overeen met de gedecodeerde velden.
Ik noem dit voorlopig gedeeltelijk opgelost in plaats van afgesloten: we dragen het als patch mee die nog niet in onze tree is beland, en er is nog een platform met een andere FPGA-build te verifiëren voordat we het overal vertrouwen. Maar de optiek deugde de hele tijd al, en dat is het stuk dat ik zelf verkeerd zou hebben ingeschat.