Pole vendor w AFBR-89BDDZ QSFP28 pokazuje 0905000000000000 po przejściu interfejsu SP/FPGA na FIFO
Zajmujemy się firmware'em zarządzania switchem na własnym sprzęcie i odkąd interfejs SP/FPGA zmienił się z buforów memory mapped na FIFO, inwentaryzacja transceiverów zaczęła wracać jako śmieci na niektórych portach.
- optyka QSFP28, wszystkie to AFBR-89BDDZ z tej samej partii
- odczyty idą przez service processor i ścieżkę FPGA do EEPROM-u modułu
- funkcja pomocnicza po stronie hosta to get_i2c_status_and_read_buffer: sprawdź status, odczytaj cały bufor, sprawdź status jeszcze raz
Co dostajemy zamiast danych vendora:
one port, vendor field: 0905000000000000
the next port, vendor field: all ones
on another machine: vendor field all zeros, elsewhere repeated digit charactersCo już próbowaliśmy:
- odczytaliśmy ten sam port kilka razy z rzędu, i śmieci są stabilne per port, a nie losowym szumem
- zrobiliśmy power cycle modułów, bez różnicy
- potwierdziliśmy, że każdy moduł w chassis ma ten sam numer katalogowy, więc to nie jest błąd dekodowania jakiegoś egzotycznego bloku vendora z naszej strony
Zanim zaczniemy wyciągać optykę z produkcji: czy to bardziej prawdopodobnie moduły, ścieżka I2C, czy nasza własna funkcja odczytu?
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
To wskazuje wprost na ścieżkę odczytu, a zmiana na FIFO jest tego przyczyną. Bufor memory mapped zwraca tę samą zawartość, niezależnie od tego, jak często pytasz; FIFO oddaje każdy bajt dokładnie raz, a potem go już nie ma. Sekwencja odziedziczona przez get_i2c_status_and_read_buffer - sprawdź status, odczytaj cały bufor, sprawdź status jeszcze raz - miała sens z pamięcią za sobą, a nie ma sensu z FIFO: opróżnia kolejkę, podczas gdy odczyt EEPROM-u modułu wciąż jest w drodze. Dostajesz to, co akurat tam siedziało w tej chwili, a bajty, które docierają później, zostają w tyle i pojawiają się przy następnym odczycie.
To dokładnie ten odcisk palca, który opisujesz. Stabilne śmieci per port, uszkodzenie wędrujące razem z sekwencją, same zera na jednej maszynie i powtarzające się wzorce cyfr na innej, zależnie od tego, jak akurat ułoży się timing. Nic z tego nie wymaga wadliwego modułu, a wynik twojej zamiany i tak wyklucza optykę.
Naprawa polega na tym, żeby przestać obarczać wywołującego odpowiedzialnością za sprawdzenie zakończenia. Przenieś tę odpowiedzialność do wnętrza procedury odczytu samego sterownika transceivera: czeka, aż transakcja I2C zgłosi zakończenie, i dopiero wtedy dotyka bufora, więc żaden wywołujący nie jest w stanie opróżnić go za wcześnie, z samej konstrukcji. Łatanie jednego miejsca wywołania po prostu przesunęłoby wyścig gdzie indziej.
Uczciwe ostrzeżenie: to proponowany kształt naprawy, a nie coś sprawdzonego przez lata, więc zweryfikuj to na swojej platformie, zanim znowu zaufasz inwentaryzacji. Tania lekcja do zabrania ze sobą jednak taka: pogmatwane ciągi vendora zasługują najpierw na test moduł-kontra-port, bo kolejność odczytu okazuje się winna dużo częściej niż optyka.
Jeden pomiar, który rozstrzyga sprawę na pół: czy uszkodzenie zostaje przy module, czy przy porcie? Wyjmij moduł z portu zwracającego
0905000000000000, zamień go z modułem z portu, który czyta się poprawnie, i odczytaj oba jeszcze raz. Jeśli zły ciąg podąża za fizycznym modułem, idź sprawdzać optykę. Jeśli zostaje przy numerze portu, albo gorzej, przesuwa się na kolejny odczytywany moduł, moduły są niewinne i masz problem z odczytem po stronie hosta.Skoro już tam jesteś, zrzuć surowe bajty EEPROM obok zdekodowanych pól. Śmieci w zdekodowanym ciągu vendora przy zdrowych bajtach pod spodem to zupełnie inny błąd niż śmieci w samych bajtach.
Zrobiliśmy tę zamianę na parze portów. Złe dane nie przeniosły się z modułem: port, który zwracał
0905000000000000, zwracał to samo z innym osadzonym modułem, a moduł, który wyjęliśmy, czytał się bez zarzutu w nowym slocie.Co więcej, gdy zmieniliśmy kolejność, w jakiej odczytywane są porty, uszkodzenie przesunęło się razem z sekwencją. Śmieci lądują na tym module, który jest odczytywany zaraz po tym, który się źle zachowuje. Czyli to podąża za kolejnością odczytu, nie za fizyczną częścią. Surowe bajty też są złe, więc to nie jest problem dekodowania po naszej stronie.
Inna przyczyna źródłowa, ta sama pułapka, tym razem od strony sterownika. Na Intel E810-C z zewnętrznym (out of tree) ice 1.15.4 dostawałem złe i niekompletne strony z
ethtool -mna optyce QSFP28: dane strony 1 i strony 3, progi i monitory per lane nie zgadzały się z tym, co moduł faktycznie przechowuje. Nigdy nie dostałem porządnego stwierdzenia przyczyny źródłowej, wątek zamknięto jako rozwiązany bez wielu szczegółów, więc traktuj to jako anegdotę, nie pewnik.To, na czym skończyłem, to aktualizacja sterownika ice i NVM E810 przez
nvmupdate64e, sprawdzenie krzyżowe z odczytem z wbudowanego w kernel sterownika ice na innym hoście, i wyciąganie konkretnych stron przezplus jawny offset i długość, zamiast ufać zdekodowanemu wyjściu. Jeśli twoja platforma potrafi zrobić surowy zrzut, porównaj surowe ze zdekodowanym, zanim uwierzysz któremukolwiek.
Warto rozpisać warstwy, bo to znacznie skraca tego typu polowanie. W Linuksie
ethtool -mdekoduje EEPROM modułu (nazwa vendora, OUI, numer katalogowy, numer seryjny, kod daty i wartości DDM, gdy moduł je ma),ethtool -ezrzuca surowe bajty, a tam gdzie magistrala I2C jest wystawiona,i2cdump -y 1 0x50czyta A0h, ai2cdump -y 1 0x51czyta A2h.W A0h nazwa vendora mieszka w bajtach 20-35, a PN, rewizja i SN w 40-59. Więc jeśli pole vendora jest pogmatwane, a numer katalogowy dwadzieścia parę bajtów dalej jest nienaruszony, to samo w sobie mówi, że odczyt zależy od timingu, a nie że EEPROM jest wadliwy, co pasuje do tego, co widzisz.
Jedna usterka, której nie warto mylić z tą:
ethtool -mzwracające Input/output error to zwykle po prostu moduł bez DDM. Bit 6 bajtu 92 w A0h to flaga tego, czy A2h w ogóle istnieje, i to sprawdzenie trafiło do sterowników ixgbe i bnx2x w kernelu dawno temu, żeby przestały sięgać po kolejne 256 bajtów, których nie ma.Ten sam gatunek problemu na urządzeniach SONiC, dla każdego, kto trafia tu z tamtej strony.
sfputil show eepromzgłasza Cannot get Module EEPROM data: Invalid argument dla niektórych modułów, albo po cichu nie zgadza się zshow interfaces transceiver eepromna tym samym porcie.Z tego, na co ja trafiłem, to głównie dziury platformy i sterownika, a nie optyka: te dwa polecenia używały niespójnych nazw kluczy w gałęzi 202012, co naprawiono w 202205, część platform gubi moduły QSFP z sfputil po power cycle, dopóki nie wyląduje poprawka sterownika, a na innych get_transceiver_info po prostu nie jest zaimplementowane. Gdy potrzebuję czegoś, czemu mogę zaufać do skryptów, idę do sterownika kernela optoe i sam robię surowe odczyty EEPROM SFP, QSFP albo CMIS. Sprawdź to jednak na swojej platformie, zachowanie mocno się między nimi różni.
Aktualizacja z naszej strony. Przenieśliśmy sprawdzenie zakończenia do funkcji odczytu sterownika, jak zaproponowano, i ciągi vendora są poprawne na każdym porcie przez kilkaset przebiegów inwentaryzacji, włącznie z tymi dwoma portami, które kiedyś wymieniały się śmieciami między sobą. Surowe bajty zgadzają się teraz ze zdekodowanymi polami.
Na razie nazywam to częściowo rozwiązanym, nie zamkniętym: nosimy to jako łatkę, która jeszcze nie wylądowała w naszym drzewie, i jest jeszcze jedna platforma z innym buildem FPGA do zweryfikowania, zanim zaufamy temu wszędzie. Ale optyka przez cały czas była w porządku, co jest tą częścią, którą sam bym źle ocenił.