Dell M14MK SFP28 odrzucany na OpenWrt z no common interface modes, podczas gdy QSFPTEK SFP+ się łączy
Mały domowy lab. Przeflashowałem Linksys LGS328C na OpenWrt SNAPSHOT, żeby uciec od fabrycznego interfejsu webowego. Wszystko przetrwało przejście oprócz jednego portu SFP28, który wcześniej działał bez zarzutu.
- switch: Linksys LGS328C (Realtek rtl930x), OpenWrt SNAPSHOT
- moduł: Dell S28-10G-25G-SR-85C, dual-rate 10G/25G, EEPROM zgłasza DELL M14MK rev A1
- moduł referencyjny w tej samej klatce: QSFPTEK QT-SFP+-SR
- ten sam światłowód i ten sam drugi koniec w obu testach
Moduł Dell jest wykrywany, a potem od razu wyrzucany:
sfp sfp-p49: module DELL M14MK rev A1
rtl83xx-switch ...: unsupported SFP module: no common interface modes
# ethtool lan28
Advertised link modes: 10000baseCR/Full
Link detected: noCo już sprawdziłem:
- podmieniłem na QSFPTEK SFP+ w tej samej klatce: log pokazuje, że port wybiera inband/10gbase-r, i dostaję czysty link 10 Gbps;
- ten sam moduł Dell chodził na tym switchu bez problemu pod fabrycznym firmware, więc optyka nie jest martwa;
- osadziłem ponownie i wyczyściłem złącze, bez zmiany w logu.
Czy ten moduł jest faktycznie źle zaprogramowany, czy sterownik switcha jest wybredny wobec części z możliwością 25G? Wolałbym to zrozumieć, zamiast po prostu kupić inną optykę.
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 5
Ten zrzut tłumaczy wszystko. Warstwa sfp w kernelu ma dokładnie jedno źródło danych, kiedy ustala, jakie tryby interfejsu moduł potrafi obsłużyć, i są to te bajty compliance. Kiedy żaden z nich nie jest ustawiony, wychodzi pusty zbiór, przecina go z tym, co oferuje MAC, nie dostaje nic wspólnego i wypisuje dokładnie ten komunikat, na który patrzysz. 10000baseCR/Full w ethtool to pozostałość po stronie portu, nie coś, o co poprosił moduł. Fabryczny firmware producenta się tym nie przejmuje, bo te obrazy generalnie w ogóle pomijają bajty compliance i zamiast tego dopasowują ciągi vendor i part do zaszytej na sztywno listy - dlatego optyka działała, zanim przeflashowałeś.
Poprawka, która faktycznie trzyma, to quirk modułu. W drivers/net/phy/sfp.c dodaj wpis SFP_QUIRK_S, który dopasowuje vendor DELL z part M14MK i na siłę ustawia ETHTOOL_LINK_MODE_10000baseSR_Full oraz PHY_INTERFACE_MODE_10GBASER, potem przebuduj obraz. Port wstaje jako zwykły link 10G, zgłaszając 10000baseSR/Full, a linia unsupported-module znika z logu.
Dwa zastrzeżenia. Trzymaj łatkę w formie, którą można wysłać do netdev, zamiast siedzieć na niej u siebie: EEPROM sam się nie naprawi, a ten sam part od Della ma jeszcze ktoś inny. A jeśli wolisz w ogóle nie utrzymywać własnego builda kernela, nudna alternatywa to QSFPTEK SFP+, który już masz - i tak ten port da ci najwyżej 10G.
Zanim obwinisz sterownik switcha, zrzuć EEPROM i zobacz, co deklaruje moduł:
ethtool --module-info lan28. Wklej pierwsze wiersze zrzutu hex plus pełnyethtool lan28. "no common interface modes" znaczy, że kernel nie potrafił wyprowadzić z modułu ani jednego użytecznego trybu, więc zawartość tych bajtów to cała historia.Jeszcze jedno do potwierdzenia: czy QSFPTEK siedzi w tej samej klatce, a nie w sąsiedniej? Twoja linia w logu mówi p49, podczas gdy wynik ethtool to lan28, a mylenie portów w tego rodzaju teście marnuje mnóstwo czasu.
Zrzuciłem. Krótka wersja: nie ma w ogóle żadnego ustawionego kodu compliance 10G - te bajty są po prostu puste, podczas gdy ciągi vendor i part są wypełnione dokładnie tak, jak można się spodziewać dla DELL M14MK rev A1.
ethtool lan28nadal pokazujeAdvertised link modes: 10000baseCR/FulliLink detected: no, admesg | grep lan25nie pokazuje nic poza tymi dwoma liniami z mojego pierwszego posta.Czyli moduł mówi hostowi prawie nic o tym, co faktycznie potrafi, a QSFPTEK w tej samej klatce nadal łączy się na 10 Gbps.
Warto to zapisać, bo wcześniejszy raport o błędzie dla dokładnie tej samej pary zgadywał inaczej. Tamta teoria mówiła, że moduł dual-rate zgłasza 25gbase-r, sterownik rtl930x nie implementuje tego trybu, przecięcie wychodzi puste i z samym modułem nic nie jest nie tak. Zrzut hex obala to wyjaśnienie: moduł nie zgłasza nic, nie 25G. Ten sam komunikat kernela, inna przyczyna, i tylko zrzut odróżnia te dwa przypadki.
To też przypomnienie, że optyka z marką producenta nie zawsze jest poprawnie zakodowana. Własny OS10 od Della pokaże prawdziwy Q28-128GFC-SW4 (part KP0VM) jako QSFP28 100GBASE-SR4 z Qualified false, bo niektóre partie mają kodowanie EEPROM, którego jego kwalifikacja mediów nie rozpoznaje, i link FC zostaje wyłączony, dopóki ręcznie nie pozwolisz na nieobsługiwane transceivery.
Zbudowałem obraz z wpisem SFP_QUIRK_S dla DELL / M14MK i robi dokładnie to, co opisałeś. Port łączy się na 10 Gbps,
ethtool lan28teraz zgłasza 10000baseSR/Full z linkiem up, a log jest czysty - nigdzie ani jednej linii unsupported-module. Zostawiłem to z prawdziwym ruchem na kilka dni, zanim dotknąłem czegokolwiek innego na tej maszynie, żadnych flapów.Teraz czyszczę łatkę, żeby wysłać ją do netdev, bo trzymanie jej tylko we własnym drzewie nikomu nie pomaga. Dzięki, że popchnąłeś mnie najpierw do zrzutu module-info, ja czytałem tabele trybów sterownika przez dwa wieczory.