Supermicro AOC-STGN-i1S (X520) na Proxmox 7.1: brak interfejsu w ip link z osadzonym DAC-iem HP
Mam w domu małe pudełko Proxmoksa i chciałem porządną ścieżkę 10G do noda storage, więc wsadziłem używane Supermicro AOC-STGN-i1S. To zwykły projekt na Intel 82599, płytka oznaczona E157872, i zakładałem, że to będzie nudna część budowy. Nie jest.
- Supermicro AOC-STGN-i1S, Intel X520-DA1, oznaczenie płytki E157872
- Proxmox 7.1, kernel 5.15.30-1-pve
- pasywny DAC SFP+ marki HP do drugiego pudełka
- karta enumeruje się na magistrali PCI bez problemu
Sterownik nigdy nie kończy ładowania. Log jądra mówi, że przerwał, bo wykrył typ modułu SFP+/QSFP, którego nie wspiera, i po tym po prostu nie ma portu do skonfigurowania:
lspci -> the X520 is listed, no complaints
ip link -> lo and the onboard 1G only, no 10G interface at all
dmesg -> ixgbe aborts loading, unsupported SFP+/QSFP module typeCo już zrobiłem:
- utworzyłem /etc/modprobe.d/ixgbe.conf z
options ixgbe allow_unsupported_sfp=1, potemupdate-initramfs -ui restart: bez zmian - przekazałem tę samą opcję zamiast tego jako parametr jądra: bez zmian
rmmod ixgbeimodprobe ixgberęcznie: wciąż nic nowego wip link
Karta jest martwa, czy jest jakiś sposób ominięcia tej kontroli na kernelu 5.15, którego mi brakuje?
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
To, co opisujesz, to dokładnie tak wygląda trafienie w whitelistę EEPROM na ixgbe. Sterownik czyta ID modułu, uznaje, że nie ma go na akceptowanej liście Intela, i przerywa, zanim w ogóle zarejestruje netdev, i dlatego
lspciwidzi kartę, aip linknie pokazuje zupełnie nic. Nic z tego nie jest usterką sprzętową, i dlatego też port wraca w chwili, gdy moduł wyjdzie z gniazda.Udokumentowana furtka to ta, której już użyłeś:
Na 5.15 ta opcja po prostu nie jest niezawodna. Dostałem ten sam brak rezultatu na tym kernelu, więc nie ma sensu tego powtarzać ani szukać literówki w pliku conf.
Co przesądziło sprawę u mnie: z pustym gniazdem interfejs wstawał po
modprobe ixgbe, włożenie kabla HP z powrotem znowu go wygaszało, a ten sam kabel HP złapał link bez żadnego dramatu w Mellanox ConnectX-2. Kabel jest elektrycznie sprawny, Intelowi po prostu nie podoba się, jak jest zakodowany.Naprawą, która zadziałała, było wstawienie zamiast niego zwykłego niemarkowego generycznego DAC-a SFP+. Link wstał od razu, żadnych opcji modułu, żadnych tańców z restartem. Co do supportu: z jakimkolwiek kablem niezakodowanym przez Intela i tak jesteś poza matrycą Intela, więc jeśli to pudełko kiedykolwiek ma być supportowalne, kup DAC-a zakodowanego przez Intela, a nie od HP.
Zanim spiszesz kartę na straty, zrób jeden test. Wyciągnij DAC z gniazda całkowicie, potem
rmmod ixgbe,modprobe ixgbei spójrz znowu naip link. Jeśli interfejs pojawi się przy pustym gnieździe, karta i sterownik są oba w porządku, a to kabel dławi tę kontrolę.Druga rzecz warta wiedzy: czy ten DAC HP łapie link gdziekolwiek indziej? Karta sieciowa nie od Intela zwykle przyjmie go bez słowa skargi. I czy to na pewno kabel kodowany przez HP, czy masz gdzieś generyczny do porównania?
Możesz się uważać za szczęściarza, że masz X520, gdzie przynajmniej jest pokrętło w sterowniku, choćby i zawodne. Na X710 i XL710 kontrola modułu przeniosła się do firmware, więc
allow_unsupported_sfpnie robi dla i40e zupełnie nic. Wsadź moduł nie od Intela w X710-DA2 i dostajesz:i na tym koniec rozmowy. Stamtąd opcje to optyka kodowana przez Intela, społecznościowa droga xl710-unlocker (wgranie świeżego obrazu NVM własnym updaterem Intela, a potem grzebanie w jedenastobitowych polach gdzieś koło 0x6800-0x7000 w EEPROM narzędziami innych firm, całkowicie na własne ryzyko), albo wybranie od razu wariantu OEM: HPE 562SFP+ to pod spodem X710, i po aktualizacjach firmware i i40e przyjmował moduły miedziane 10G i 1G innych producentów bez żadnych hacków.
Co do kąta OEM, dla kart X710-DA2 markowanych przez Della i Lenovo działa to w drugą stronę: odrzucają nie zatwierdzone SFP+ i DAC, a własne narzędzia Intela nawet nie widzą tej płytki na liście. To, na czym ludzie skończyli, to wgranie na nie standardowego NVM Intela. Najpierw potrzebujesz sterownika QV z pełnego pakietu BootUtil Intela, inaczej narzędzia w ogóle nie porozmawiają z płytką; option ROM wymienia się przed wszystkim innym, i dopiero wtedy robisz inwentaryzację karty i ją flashujesz:
Między inwentaryzacją a flashowaniem przytnij nvmupdate.cfg do jednego wpisu X710 pasującego do rozmiaru flasha SPI karty, 4 MB albo 8 MB. Wybierz zły rozmiar i masz cegłę, którą trzeba ratować zapisanym obrazem NVM i sprzętowym flasherem, więc najpierw przeczytaj ETrackID i miej pewność. Firmware z zakresu 9.30-9.40 zgłaszano jako działający potem, a ludzie przy okazji łapali SR-IOV na płytkach Lenovo. Ja i tak spróbowałbym tego tylko na karcie, której stratę mógłbym sobie pozwolić.
Uważałbym z celowaniem w tym wątku drogami crossflasha i łatania EEPROM, bo żadna z nich nie pomaga w opisanej sytuacji. Edycja flagi OEM w EEPROM X520 wymaga najpierw działającego interfejsu, żeby w ogóle dostać się do karty, a tutaj nie ma żadnego interfejsu, dopóki kabel nie wyjdzie z gniazda. To naprawa dla portu, który istnieje i odrzuca jeden moduł, nie dla sterownika, który przerywa przy ładowaniu.
Drugą rzeczą, której bym nie przeceniał, jest test w innej karcie sieciowej. Moduł łapiący link w innym hoście dowodzi sprawności modułu, nie hosta, w którym faktycznie go chcesz. Mam moduły miedziane Ubiquiti UACC-CM-RJ45-MG, które chodzą bez zarzutu w CCR2004 i w Intel X520-DA2 pod Debianem, a w gniazdach SFP+ CRS309 i CRS328 w ogóle nigdy nie łapią linku, ani z autonegocjacją włączoną, ani z prędkością przypiętą ręcznie. Zależność od hosta jest realna, więc zweryfikuj na dokładnie tej maszynie, zanim kupisz stos czegokolwiek.