Intel X520 w R630 odrzuca miedziany SFP+ 10GBASE-T z comp_codes_10g=0x00 mimo allow_unsupported_sfp=1
Konsolidujemy parę R630 na 10G, a okablowanie do góry racka jest miedziane, więc zamiast ciągnąć światłowód wsadziłem moduły SFP+ 10GBASE-T do kart X520. Strona switcha bierze je bez słowa sprzeciwu. Serwery odmawiają.
- Dell PowerEdge R630, Intel X520 (82599), dwuportowy
- FS SFP-10GM-T-30, zakodowany pod Della, jeden moduł na serwer
- out-of-tree ixgbe od Intela, zbudowany przez DKMS
- /etc/modprobe.d/ixgbe.conf z ustawionym override dla obu portów
# cat /etc/modprobe.d/ixgbe.conf
options ixgbe allow_unsupported_sfp=1,1
# dmesg
ixgbe: failed to load because an unsupported SFP+ module type was detected
# 10G compliance codes read back from the module
comp_codes_10g=0x00Co już sprawdziłem:
modprobe ixgbe allow_unsupported_sfp=1ręcznie, a także wpis w modprobe.d- przebudowałem initramfs i zrobiłem zimny restart maszyny, nie tylko przeładowanie modułu
- przełożyłem moduł do drugiego portu, a potem do drugiego serwera, ten sam wynik
Ciekawa część to ten bajt compliance: moduł nie zgłasza kompletnie nic dla 10G. Czy sterownik sprawdza to, zanim w ogóle spojrzy na override, i czy da się coś zrobić poza kupieniem optyki z właściwym kodowaniem?
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 6
Nie walczysz z whitelistą, walczysz z kolejnością sprawdzeń.
SFF-8472 nie ma bitu compliance dla 10GBASE-T. Po prostu nie ma dla niego code pointu, więc uczciwy miedziany SFP+ zgłasza same zera w kodach compliance 10G, co dokładnie odpowiada twojemu
comp_codes_10g=0x00. ixgbe czyta ten bajt, nie znajduje niczego, co rozpoznaje jako moduł 10G, i poddaje się w tym miejscu, zanim jeszcze zbliży się do override'uallow_unsupported_sfp. Dlatego ta flaga działa dobrze dla niezakwalifikowanego modułu optycznego albo DAC i nie robi kompletnie nic dla twoich miedzianych.Istnieje community'owy patch na out-of-tree ixgbe od Intela, który przesuwa ten test compliance: gdy administrator jawnie ustawił
allow_unsupported_sfp=1, moduł zgłaszający same zera w kodach compliance 10G zostaje sklasyfikowany jako SR zamiast być odrzuconym na wczesnym etapie. Został zgłoszony upstream i wciąż nie jest zmergowany, więc aplikujesz go do źródeł DKMS ręcznie i trzymasz razem z buildem. Autor zgłosił potem 10 Gb/s full duplex na parze serwerów, a ktoś inny potwierdził, że ten sam patch sprawia, że miedziane moduły HLX-SFPX działają w X520.Dwa zastrzeżenia, zanim to zrobisz. Optyka, której Intel nie zakwalifikował, wypada poza ich gwarancję kompatybilności, więc to staje się twoim problemem, nie ich. A PHY 10GBASE-T to gorący element - w gnieździe serwera bez własnego przepływu powietrza usiądzie wyraźnie powyżej wszystkiego optycznego w sąsiednim slocie, więc pilnuj temperatury modułu, gdy link już wstanie.
Dwie rzeczy do ustalenia, zanim zaczniesz cokolwiek łatać.
Po pierwsze, wypisz parametr tak, jak faktycznie widzi go jądro,
/sys/module/ixgbe/parameters/allow_unsupported_sfp, na maszynie, która przeszła przez zimny restart, a nie tylko przeładowanie modułu. Jeśli to nie zwraca dokładnie tego, co stoi w twoim pliku conf, coś ładuje sterownik, zanim twoja konfiguracja wchodzi w grę, i reszta debugowania jest zmarnowana.Po drugie, który ixgbe jest załadowany?
ethtool -inic ci nie da, dopóki sterownik nigdy nie kończy ładowania, a interfejsy są nieobecne, więc wklej, co zgłaszamodinfo ixgbei jaką wersję pakietu DKMS zbudowałeś.I skąd bierze się to
comp_codes_10g=0x00- to sterownik ci to mówi, czy sam zrzuciłeś EEPROM modułu?Parametr to
1,1w pliku, a/sys/module/ixgbe/parameters/allow_unsupported_sfpzwraca1,1po zimnym restarcie, więc jest zaaplikowany, nie po cichu zignorowany. Initramfs został przebudowany przed rozruchem. Ta sama linia w dmesg za każdym razem.Kody compliance odczytałem z modułu sam, z danych SFF-8472, nie od sterownika - bajt compliance 10G jest zerowy, wszystko inne w polach ID wygląda sensownie. Ten sam moduł w porcie switcha linkuje na 10G, więc to nie martwy moduł.
Warto dodać od strony praktycznej: przy DKMS każda aktualizacja jądra przebudowuje się ze źródeł na dysku, więc patch musi siedzieć w tym drzewie źródłowym, nie w katalogu builda, który potem posprzątałeś. Sprawdź, czy port wraca po pierwszym skoku wersji jądra, zamiast dowiadywać się o tym w oknie restartu.
Szersza lekcja z tej klasy problemów jest taka, że wiek sterownika decyduje bardziej niż kodowanie modułu. Ta sama historia na X710 z pasywnym DAC: jeden kabel, jeden port, szczęśliwy pod Ubuntu 24.04 i martwy pod TrueNAS SCALE z
Link detected: noiSpeed: Unknown, bo ten build niósł i40e z jądra 6.6.44-production. Na 25.04-BETA.1, gdzie i40e pochodzi z 6.12.9-production, twinax wstał sam z siebie - nic innego nie było ruszane, karta wciąż na firmware 9.20. Optyka na tym porcie działała dobrze pod obydwoma systemami, co właśnie przypięło winę do tego, jak starszy sterownik obsługuje pasywną miedź.ethtool -ipo obu stronach porównania oszczędziłoby sporo przekładania kabli.Inny typ modułu, ten sam sterownik, i pułapka warta wykluczenia, skoro już tam grzebiesz. Dell R720 z kartą córką X520, moduły Cisco 10G multimode LC odrzucone, interfejsy po prostu nieobecne. Opcja była w modprobe.d, była też w GRUB, i nic się nie zmieniało - bo host startuje przez EFI, a ta linia poleceń GRUB nigdy nie była używana.
Na Proxmoksie rozruchowym przez EFI parametr należy do
/etc/kernel/cmdlinejakoixgbe.allow_unsupported_sfp=1, a potempve-efiboot-tool refresh. W tamtym przypadku nawet to nie pomogło i skończyło się na kupnie modułów z etykietą Intel, więc traktuj to jako coś do wykluczenia, nie jako lekarstwo.Druga rzecz z tego całego bałaganu: oba końce muszą być zadowolone z optyki niezależnie od siebie. Moduł, który akceptuje switch, wciąż może zostać odrzucony przez hosta, i właśnie tam już jesteś.
Zaaplikowałem patch do źródeł DKMS i przebudowałem. Oba porty wstają na 10 Gb/s full duplex i trzymają się pod obciążeniem od tamtej pory.
Działa, ale nie nazwałbym tego rozwiązanym. To niezmergowany patch, który teraz przenoszę przez każdą aktualizację jądra, a sterownik prezentuje port jako SR, co zmyli każdego, kto spojrzy na to urządzenie po mnie. Moduł działa też wyraźnie goręcej niż optyka w sąsiednim gnieździe, a ten slot nie ma przepływu powietrza wartego tej nazwy. Dla kolejnej partii serwerów pociągnę światłowód i przestanę się kłócić ze sterownikiem.