StarTech ST10GSPEXNB (Tehuti TN4010): Hersteller-Treiber baut nicht auf Debian 11, Kernel 5.10
Einen StarTech ST10GSPEXNB gekauft, um einem Backup-Server einen 10G-SFP+-Port zu geben, in der Annahme, dass eine Karte, die mit Linux-Treiber verkauft wird, auch gegen eine aktuelle Distribution baut. Das war optimistisch von mir.
- StarTech ST10GSPEXNB, Tehuti-TN4010-Chip
- Debian 11, Kernel 5.10.0-13-amd64, passende Header installiert
- Hersteller-Treiberpaket, wie es für die Karte mitgeliefert wird
- generisches 10G-SFP+-Modul in der Cage, nicht dass die Karte je so weit käme, dass es sie interessiert
make kommt ein gutes Stück weit und fällt dann im Transmit-Pfad um:
$ 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'Die letzten beiden landen in den DMA-Mapping-Aufrufen.
Bisher versucht:
- chmod +x mvidtoh.sh, weil der Build vorher mit einem permission denied stehen blieb und die PHY-Header nicht erzeugen wollte - das ist erledigt
- uname -r gegen die installierten Header geprüft, sie passen
- nach einem neueren Paket als dem vom Hersteller gesucht und überhaupt nichts gefunden
Betreibt jemand eines von diesen auf einem Kernel aus diesem Jahrzehnt, und wenn ja, wie?
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
Welches Treiberpaket genau - steht eine Version auf dem Tarball, und welchen Kernelbereich behauptet das Readme? Jede Tehuti-basierte Karte, die mir je durch die Hände ging, liefert einen Source-Tree, der seine unterstützten Kernel im Readme nennt, und das liegt meist weit hinter dem, was man tatsächlich fährt.
Auch wert zu sagen, welchen Tree du gerade baust. Es gibt den Vendor-Drop, der mit der Karte kommt, und es gibt die Community-tn40xx-Trees - tn40xx-006 und tn40xx-003, dazu die Branches linux-6.6 und linux-6.7 - und die stehen an ganz unterschiedlichen Punkten ihrer Geschichte. Leute vergleichen sich ständig quer über all das, ohne zu merken, dass sie über unterschiedlichen Code reden.
Letzte Sache: ist 3644 wirklich der erste Fehler im Log, oder steht darüber noch etwas, das du als Rauschen liest? Diese drei Zeilen sehen nach einer einzigen API-Änderung aus, aber wenn der Build schon früher gebrochen ist, ist der Rest nur Folgeschaden davon.
Community-Trees sind mir neu - ich hatte bisher nur den Tarball, der in der Box lag, und alles hier ist daraus gebaut, entpackt genau wie geliefert. Diese Branches lese ich mir als Nächstes durch. Keine Version irgendwo auf dem Tarball oder im Makefile, für das, was das wert ist.
Das Readme ist genau, wie du es beschreibst. Es spricht von 3.x-Kerneln und hört bei der 4.14-Linie auf. Ich habe das als Notiz gelesen, worauf getestet wurde, nicht als harte Grenze, was jetzt naiv aussieht.
Und ja, 3644 ist der erste Fehler. Darüber steht nichts als Warnungen - ungenutzte Variablen, implizite Deklarationen, das, was dieser Tree offenbar routinemäßig produziert - und der Build geht das alles recht fröhlich durch, bevor er im Transmit-Pfad tot umfällt. Dieselben drei Zeilen, 3644, 3648 und 3651, in derselben Reihenfolge, bei jedem Lauf.
Es ist eine harte Grenze, was auch immer das Readme damit gemeint hat, und die Fehler, die du gepostet hast, buchstabieren genau warum.
Der Kernel hat geändert, wie skb-Fragmente dargestellt werden. Ab 5.4 ist skb_frag_t ein bio_vec, und struct skb_frag_struct gibt es schlicht nicht mehr. Quellcode, der einem struct skb_frag_struct * zuweist, verdient sich exakt deine Zeile-3644-Beschwerde, und alles, was das danach dereferenziert, um eine Page und einen Offset an die DMA-Mapping-Aufrufe zu übergeben, verdient sich die invalid use of an undefined type auf 3648 und 3651. Kein Header, kein Flag und kein älterer Compiler bringt dich um einen Typ herum, den es nicht mehr gibt.
Auf 5.10 muss dieser Tree also editiert werden, nicht konfiguriert. Die Fragment-Behandlung im Transmit-Pfad muss gegen die aktuellen Accessoren neu geschrieben werden, und das ist ein echter Patch, kein Ein-Zeilen-Fix, weil sich das DMA-Mapping rund um diese Zugriffe gleichzeitig mit ändert.
Ich besitze keine dieser Karten, nimm das also als Diagnose und nicht als Versprechen. Ich kann dir sagen, warum der Build scheitert und dass es ein Source-Problem ist; ich kann dir nicht sagen, dass der Treiber danach einen Link hochbringt.
Bevor du ein Wochenende in diesen Patch versenkst, schau dir an, was auf der anderen Seite davon wartet.
Ich habe hier einen StarTech PEX10000SFP, die TN9510-Variante, PCI 1fc9:4025 mit Subsystem 1fc9:3015. Der Out-of-Tree-tn40xx-Treiber baut und lädt dafür, und dmesg ist durchaus ermutigend:
Und dann sitzt das Interface für immer bei NO-CARRIER mit rotem Licht im Modul. Dieselbe Karte, dieselbe Cage, dieselbe Optik unter dem StarTech-Windows-Treiber: linkt sofort. Die Hardware ist also gesund und die PHY-Firmware lädt, es ist die Link-Stufe dieses Treiber-Ports, die nie fertig wird.
Ich bin durch Ubuntu 22.04 und Rocky Linux 8.10 gegangen, Kernel 4.18, 5.15, 6.5 und 6.9, und die Branches tn40xx-006, tn40xx-003, linux-6.6 und linux-6.7. Keiner davon hat mir einen Carrier gegeben. Das Ding zum Kompilieren zu bringen ist ehrlich gesagt die leichte Hälfte.
Das ist das Argument dafür, Geld statt eines Wochenendes auszugeben, und ich sage das als jemand, der die Wochenend-Option normalerweise mag. Eine gebrauchte Intel- oder Mellanox-10G-Karte kostet weniger als einen Nachmittag deiner Zeit, und ihr Treiber steckt schon im Kernel, den du bootest.
Eine Sache, die man wissen sollte, wenn man zu Intel greift und eine Third-Party-Optik reinsteckt. Ein X520 verweigert das Modul rundweg mit "unsupported SFP+ module type was detected", und man landet komplett ohne Interface. Der Fix ist eine Modul-Option:
Dual-Port-Karten wollen dort 1,1. Dann update-initramfs -u und ein Kaltstart statt nur das Modul zu entladen und neu zu laden, denn dieser deaktivierte Zustand wird in der Firmware festgeschrieben, und ein Warm-Reload räumt das oft nicht weg. Das gilt nur für 82599 und X520, wo die Prüfung im Treiber sitzt. Beim X710 sitzt die Prüfung in der Firmware, und diese Option rettet dich dort nicht.
Richtiger Rat, falsches Problem, im selben Atemzug. allow_unsupported_sfp betrifft die Optik-Whitelist des Treibers, und die Karte in diesem Thread kompiliert überhaupt nicht - hier ist niemand auch nur in die Nähe des Punkts gekommen, an dem eine Optik abgelehnt wird. Später nützlich zu wissen, jetzt keine Antwort.
Wenn Gebraucht aber infrage kommt: die andere Karte, die einfach funktioniert, ist ein HP NC523SFP, das ist das OEM-QLogic-QLE3242, HP-Teilenummer 593715-001. Er läuft auf dem im Kernel enthaltenen qlcnic-Treiber, da gibt es also überhaupt nichts zu bauen - ich habe hier eine Box, die qlcnic 5.3.66 gegen Adapter-Firmware 4.8.20 meldet, und sie hat seit dem Einbau keine Aufmerksamkeit gebraucht.
Zwei Einschränkungen. Er läuft heiß, ungefähr 16 bis 17 W im Leerlauf, das merkt man in einem ruhigen Raum. Und SR-IOV daran ist ein Durcheinander, das mir niemand, den ich gefragt habe, in die eine oder andere Richtung bestätigen konnte. Wenn du SR-IOV brauchst, ist der NC552SFP der bessere Kauf, er nutzt bnx2x und unterstützt es richtig, aber man muss ARI-Forwarding vorgelagert aktivieren, sonst taucht er nicht auf.