Sterownik producenta StarTech ST10GSPEXNB (Tehuti TN4010) nie buduje się na Debianie 11, kernel 5.10
Kupiłem StarTech ST10GSPEXNB, żeby dać serwerowi zapasowemu port 10G SFP+, w założeniu, że karta sprzedawana ze sterownikiem pod Linuksa zbuduje się na aktualnej dystrybucji. To było z mojej strony zbyt optymistyczne.
- StarTech ST10GSPEXNB, chip Tehuti TN4010
- Debian 11, kernel 5.10.0-13-amd64, zainstalowane pasujące headery
- pakiet sterownika producenta, taki jak dostarczony do karty
- ogólny moduł 10G SFP+ w klatce, nie żeby karta zaszła wystarczająco daleko, by się nim przejmować
make dochodzi daleko, a potem wywraca się w ścieżce transmisji:
$ make
...
tn40.c:3644: error: assignment to 'struct skb_frag_struct *' from incompatible pointer type
tn40.c:3648: error: invalid use of undefined type 'struct skb_frag_struct'
tn40.c:3651: error: invalid use of undefined type 'struct skb_frag_struct'Te dwa ostatnie lądują w wywołaniach mapowania DMA.
Co już próbowałem:
- chmod +x mvidtoh.sh, bo wcześniej build zatrzymywał się na permission denied i nie generował headerów PHY - to jest już ogarnięte
- sprawdziłem uname -r względem zainstalowanych headerów, zgadzają się
- szukałem pakietu nowszego niż ten, który wysyła producent, i nie znalazłem zupełnie nic
Czy ktoś odpala coś takiego na kernelu z tej dekady, a jeśli tak, to jak?
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
Który dokładnie pakiet sterownika - czy na tarballu jest wybita wersja i jaki zakres kerneli deklaruje jego readme? Każda karta na Tehuti, jaka przeszła mi przez ręce, wysyła drzewo źródłowe, które w readme wymienia wspierane kernele, i zwykle jest to daleko w tyle za tym, co faktycznie odpalasz.
Warto też powiedzieć, które drzewo budujesz. Jest wrzutka od producenta, która przychodzi z kartą, i są społecznościowe drzewa tn40xx - tn40xx-006 i tn40xx-003, plus branche linux-6.6 i linux-6.7 - i są one zupełnie w innym miejscu historii. Ludzie porównują notatki między nimi cały czas, nie zauważając, że mówią o innym kodzie.
Ostatnia rzecz: czy 3644 to naprawdę pierwszy błąd w logu, czy jest coś wyżej, co odczytujesz jako szum? Te trzy linie wyglądają jak jedna zmiana API, ale jeśli build się wywalił wcześniej, to reszta to tylko tego konsekwencje.
Drzewa społecznościowe to dla mnie nowość - miałem tylko tarball, który przyszedł w pudełku, i wszystko tutaj jest zbudowane z tego, rozpakowane tak, jak dostarczone. Te branche to następna rzecz, którą przeczytam. Żadnej wersji nigdzie na tarballu ani w makefile, tyle w temacie.
Readme jest dokładnie takie, jak opisujesz. Mówi o kernelach 3.x i kończy się na linii 4.14. Odczytałem to jako notatkę o tym, na czym testowali, a nie twardy limit, co teraz wygląda naiwnie.
I tak, 3644 to pierwszy błąd. Powyżej nie ma nic poza warningami - nieużywane zmienne, niejawne deklaracje, tego rodzaju rzeczy, które to drzewo najwyraźniej produkuje jako coś normalnego - i build przechodzi przez to wszystko całkiem spokojnie, zanim staje martwo w ścieżce transmisji. Te same trzy linie, 3644, 3648 i 3651, w tej samej kolejności, za każdym razem.
To twardy limit, cokolwiek readme miało na myśli, a błędy, które wkleiłeś, tłumaczą dlaczego.
Kernel zmienił sposób reprezentowania fragmentów skb. Od 5.4 wzwyż skb_frag_t jest bio_vec, a struct skb_frag_struct po prostu już tam nie ma. Kod, który przypisuje do struct skb_frag_struct *, zarabia dokładnie twoją skargę z linii 3644, a wszystko, co potem dereferencjuje to, żeby przekazać stronę i offset do wywołań mapowania DMA, zarabia invalid use of an undefined type na 3648 i 3651. Żaden header, żadna flaga i żaden starszy kompilator nie obejdzie ci typu, którego już nie ma.
Więc na 5.10 to drzewo trzeba edytować, a nie konfigurować. Obsługę fragmentów w ścieżce transmisji trzeba przepisać pod aktualne akcesory, i to jest prawdziwa łatka, a nie poprawka na jedną linię, bo mapowanie DMA wokół tych dostępów zmienia kształt w tym samym czasie.
Nie mam jednej z tych kart, więc traktuj to jako diagnozę, a nie obietnicę. Mogę ci powiedzieć, dlaczego build pada i że to problem w źródle; nie mogę ci powiedzieć, że sterownik potem podniesie link.
Zanim zatopisz weekend w tej łatce, zerknij, co czeka po drugiej jej stronie.
Mam tu StarTech PEX10000SFP, wariant TN9510, PCI 1fc9:4025 z subsystemem 1fc9:3015. Sterownik out-of-tree tn40xx buduje się i ładuje dla niego, a dmesg jest w pełni zachęcający:
A potem interfejs siedzi na NO-CARRIER z czerwonym światłem w module, na zawsze. Ta sama karta, ta sama klatka, ta sama optyka pod sterownikiem StarTech dla Windows: linkuje natychmiast. Więc sprzęt jest sprawny, a firmware PHY się ładuje, to etap linkowania tego portu sterownika nigdy nie kończy roboty.
Przeszedłem przez Ubuntu 22.04 i Rocky Linux 8.10, kernele 4.18, 5.15, 6.5 i 6.9, i branche tn40xx-006, tn40xx-003, linux-6.6 i linux-6.7. Ani jeden nie dał mi carriera. Uczciwie mówiąc, doprowadzenie tego do skompilowania się to łatwiejsza połowa.
To jest argument za wydaniem pieniędzy zamiast weekendu, i mówię to jako ktoś, kto zwykle woli opcję weekendową. Używana karta 10G Intela albo Mellanoksa kosztuje mniej niż popołudnie twojego czasu, a jej sterownik jest już w kernelu, który odpalasz.
Jedna rzecz, o której warto wiedzieć, jeśli idziesz w Intela i wsadzisz w niego optykę firmy trzeciej. X520 od razu odrzuca moduł z "unsupported SFP+ module type was detected" i zostajesz zupełnie bez interfejsu. Naprawa to opcja modułu:
Karty dwuportowe chcą tam 1,1. Potem update-initramfs -u i zimny restart zamiast zwykłego wyładowania i przeładowania modułu, bo ten stan wyłączenia zatrzaskuje się w firmware i ciepły reload często tego nie czyści. To dotyczy tylko 82599 i X520, gdzie sprawdzenie siedzi w sterowniku. Na X710 sprawdzenie jest w firmware i ta opcja cię nie uratuje.
Dobra rada, zły problem, w jednym zdaniu. allow_unsupported_sfp dotyczy whitelisty optyki sterownika, a karta z tego wątku w ogóle się nie kompiluje - nikt tu nie jest nawet blisko punktu, w którym optyka zostaje odrzucona. Przydatne do wiedzy na później, nie odpowiedź na teraz.
Jeśli jednak rynek wtórny wchodzi w grę, to druga karta, która po prostu działa, to HP NC523SFP, czyli OEM-owany QLogic QLE3242, HP part 593715-001. Działa na wbudowanym w kernel sterowniku qlcnic, więc nie ma w ogóle nic do budowania - mam tu box zgłaszający qlcnic 5.3.66 wobec firmware adaptera 4.8.20, i nie potrzebował żadnej uwagi, odkąd go wstawiłem.
Dwa zastrzeżenia. Grzeje się mocno, gdzieś koło 16 do 17 W na biegu jałowym, co czuć w cichym pomieszczeniu. I SR-IOV na niej to bałagan, którego nikt, kogo pytałem, nie potrafił potwierdzić w żadną stronę. Jeśli potrzebujesz SR-IOV, to lepszym zakupem jest NC552SFP, używa bnx2x i wspiera to porządnie, ale trzeba włączyć ARI forwarding wyżej w drzewie, inaczej się nie pojawi.