StarTech ST10GSPEXNB (Tehuti TN4010) vendor driver bouwt niet op Debian 11, kernel 5.10
Een StarTech ST10GSPEXNB gekocht om een backupserver een 10G SFP+-poort te geven, in de veronderstelling dat een kaart die met een Linux-driver verkocht wordt ook tegen een actuele distributie zou bouwen. Dat was optimistisch van me.
- StarTech ST10GSPEXNB, Tehuti TN4010 chip
- Debian 11, kernel 5.10.0-13-amd64, bijpassende headers geïnstalleerd
- vendor driver package zoals meegeleverd bij de kaart
- generieke 10G SFP+-module in de cage, al is de kaart nog niet zo ver gekomen dat het daar iets toe doet
make komt een heel eind en valt dan om in het transmit-pad:
$ 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'De laatste twee landen in de DMA-mapping-calls.
Tot nu toe geprobeerd:
- chmod +x mvidtoh.sh, want de build stopte eerder met een permission denied en wilde de PHY-headers niet genereren - dat onderdeel is opgelost
- uname -r vergeleken met de geïnstalleerde headers, die komen overeen
- gezocht naar een nieuwer package dan wat de vendor meelevert en helemaal niets gevonden
Draait hier iemand zo'n kaart op een kernel uit dit decennium, en zo ja, hoe?
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
Welk driverpakket precies - staat er een versie op de tarball gestempeld, en welk kernelbereik claimt de readme? Elke Tehuti-kaart die ik ooit in handen heb gehad levert een sourcetree waarvan de readme de ondersteunde kernels noemt, en die loopt meestal een flink eind achter op wat je daadwerkelijk draait.
Ook de moeite waard om te zeggen welke tree je bouwt. Er is de vendor drop die bij de kaart zit, en er zijn de community tn40xx-trees - tn40xx-006 en tn40xx-003, plus de linux-6.6- en linux-6.7-branches - en die staan lang niet op hetzelfde punt in de geschiedenis. Mensen vergelijken er voortdurend aantekeningen over zonder te merken dat ze het over andere code hebben.
Laatste ding: is 3644 werkelijk de eerste fout in het log, of staat er verderop iets dat je als ruis hebt gelezen? Die drie regels zien eruit als één enkele API-wijziging, maar als de build eerder al brak dan is de rest gewoon bijkomende schade daarvan.
Community trees zijn nieuw voor me - ik heb altijd alleen de tarball gehad die in de doos zat, en alles hier is daaruit gebouwd, uitgepakt zoals geleverd. Die branches ga ik hierna lezen. Nergens een versie op de tarball of in de makefile, voor wat het waard is.
De readme is precies zoals je beschrijft. Hij heeft het over 3.x-kernels en stopt bij de 4.14-lijn. Ik las dat als een aantekening over waarop ze getest hadden in plaats van een harde grens, wat nu naïef blijkt.
En ja, 3644 is de eerste fout. Daarboven staan alleen maar warnings - ongebruikte variabelen, impliciete declaraties, het soort dingen dat die tree kennelijk standaard produceert - en de build loopt daar vrolijk doorheen voordat hij finaal vastloopt in het transmit-pad. Dezelfde drie regels, 3644, 3648 en 3651, in dezelfde volgorde, elke run.
Het is een harde grens, wat de readme er ook mee bedoelde, en de foutmeldingen die je plakte laten precies zien waarom.
De kernel heeft veranderd hoe skb-fragmenten worden weergegeven. Vanaf 5.4 is skb_frag_t een bio_vec, en struct skb_frag_struct bestaat simpelweg niet meer. Source die toewijst aan een struct skb_frag_struct * krijgt precies jouw klacht op regel 3644, en alles wat het vervolgens dereferentieert om een page en een offset door te geven aan de DMA-mapping-calls krijgt op 3648 en 3651 de invalid-use-of-undefined-type-fout te zien. Geen header, geen flag en geen oudere compiler brengt je om een type heen dat niet meer bestaat.
Dus op 5.10 moet die tree bewerkt worden in plaats van geconfigureerd. De fragmentafhandeling in het transmit-pad moet herschreven worden tegen de huidige accessors, en het is een echte patch en geen éénregelige fix, omdat de DMA-mapping rond die accesses tegelijkertijd van vorm verandert.
Ik heb zelf geen van deze kaarten, dus neem dit als een diagnose en geen belofte. Ik kan je vertellen waarom de build faalt en dat het een sourceprobleem is; ik kan je niet vertellen dat de driver daarna een link omhoog brengt.
Voor je een weekend in die patch steekt: kijk eerst wat er aan de andere kant op je wacht.
Ik heb hier een StarTech PEX10000SFP, de TN9510-variant, PCI 1fc9:4025 met subsystem 1fc9:3015. De out-of-tree tn40xx-driver bouwt en laadt ervoor, en dmesg is behoorlijk bemoedigend:
En dan blijft de interface voor altijd op NO-CARRIER staan, met een rood lampje in de module. Zelfde kaart, zelfde cage, zelfde optic onder de StarTech Windows-driver: linkt meteen. Dus de hardware is in orde en de PHY-firmware laadt, het is de linkfase van die driverport die nooit klaar komt.
Ik ben door Ubuntu 22.04 en Rocky Linux 8.10 gegaan, kernels 4.18, 5.15, 6.5 en 6.9, en de tn40xx-006-, tn40xx-003-, linux-6.6- en linux-6.7-branches. Niet één gaf me een carrier. Het ding aan de praat krijgen om te compileren is eerlijk gezegd de makkelijke helft.
Dat is het argument om geld uit te geven in plaats van een weekend, en ik zeg het als iemand die normaal gesproken de weekendoptie wel ziet zitten. Een tweedehands Intel- of Mellanox-10G-kaart kost minder dan een middag van je tijd en de driver zit al in de kernel die je boot.
Eén ding om te weten als je voor Intel gaat en er een third-party optic in stopt. Een X520 weigert de module ronduit met "unsupported SFP+ module type was detected" en je blijft helemaal zonder interface zitten. De fix is een module-optie:
Dual-port-kaarten willen daar 1,1. Dan update-initramfs -u en een cold boot in plaats van de module gewoon te unloaden en herladen, want die disabled-status wordt vastgezet in firmware en een warme reload wist dat lang niet altijd. Dat geldt alleen voor 82599 en X520, waar de check in de driver zit. Op X710 zit de check in firmware en die optie redt je daar niet.
Goed advies, verkeerd probleem, in één adem. allow_unsupported_sfp gaat over de optic-whitelist van de driver, en de kaart in deze thread compileert al helemaal niet - niemand hier is ook maar in de buurt van het punt waarop een optic geweigerd wordt. Later nuttig om te weten, nu geen antwoord.
Als tweedehands toch een optie is: de andere kaart die gewoon werkt is een HP NC523SFP, dat is de OEM QLogic QLE3242, HP-onderdeelnummer 593715-001. Die draait op de in-kernel qlcnic-driver, dus er valt helemaal niets te bouwen - ik heb hier een box die qlcnic 5.3.66 meldt tegen adapterfirmware 4.8.20, en die heeft geen omkijken gehad sinds hij erin zit.
Twee kanttekeningen. Hij loopt warm, ergens rond de 16 tot 17 W bij idle, en dat merk je in een stille ruimte. En SR-IOV erop is een zooitje waar niemand die ik het vroeg uitsluitsel over kon geven. Heb je SR-IOV nodig, dan is de NC552SFP de betere koop, die gebruikt bnx2x en ondersteunt het wel netjes, maar je moet ARI forwarding stroomopwaarts ervan inschakelen anders verschijnt hij niet.