Le driver vendor du StarTech ST10GSPEXNB (Tehuti TN4010) ne compile pas sur Debian 11, kernel 5.10
J'ai acheté un StarTech ST10GSPEXNB pour donner un port SFP+ 10G à un serveur de sauvegarde, en supposant qu'une carte vendue avec un driver Linux compilerait contre une distribution actuelle. C'était optimiste de ma part.
- StarTech ST10GSPEXNB, puce Tehuti TN4010
- Debian 11, kernel 5.10.0-13-amd64, headers correspondants installés
- paquet driver vendor tel que fourni pour la carte
- module SFP+ 10G générique dans la cage, pas que la carte en soit arrivée assez loin pour s'en soucier
make avance pas mal puis tombe dans le chemin de transmission :
$ 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'Les deux dernières atterrissent dans les appels de mapping DMA.
Essayé jusqu'ici :
- chmod +x mvidtoh.sh, parce que la compilation s'arrêtait plus tôt avec un permission denied et ne générait pas les headers PHY - cette partie est réglée
- vérifié uname -r contre les headers installés, ils correspondent
- cherché un paquet plus récent que celui fourni par le vendor et n'ai rien trouvé du tout
Y a-t-il quelqu'un qui fait tourner l'une de ces cartes sur un kernel de cette décennie, et si oui, comment ?
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
Quel paquet driver exactement - y a-t-il une version marquée sur l'archive, et quelle plage de kernels son readme prétend-il supporter ? Chaque carte basée sur Tehuti qui m'est passée entre les mains fournit un arbre source qui nomme ses kernels supportés dans le readme, et c'est généralement très en retard sur ce que vous faites réellement tourner.
Ça vaut le coup de dire aussi quel arbre vous compilez. Il y a le paquet du vendor livré avec la carte, et il y a les arbres communautaires tn40xx - tn40xx-006 et tn40xx-003, plus les branches linux-6.6 et linux-6.7 - et ils ne sont pas du tout au même point de leur histoire. Les gens comparent des notes entre eux tout le temps sans remarquer qu'ils discutent de codes différents.
Dernière chose : est-ce que 3644 est vraiment la première erreur du journal, ou y a-t-il quelque chose au-dessus que vous avez lu comme du bruit ? Ces trois lignes ressemblent à un seul changement d'API, mais si la compilation a cassé plus tôt, le reste n'est que la conséquence.
Les arbres communautaires sont nouveaux pour moi - je n'ai jamais eu que l'archive fournie dans la boîte, et tout ici est compilé à partir de ça, décompressé tel que livré. Ces branches sont la prochaine chose que je vais lire. Aucune version nulle part sur l'archive ni dans le makefile, pour ce que ça vaut.
Le readme est exactement comme vous le décrivez. Il parle de kernels 3.x et s'arrête à la ligne 4.14. J'ai lu ça comme une note sur ce qu'ils avaient testé plutôt qu'une limite dure, ce qui semble naïf maintenant.
Et oui, 3644 est la première erreur. Au-dessus il n'y a rien que des avertissements - variables non utilisées, déclarations implicites, le genre de choses que cet arbre produit visiblement en routine - et la compilation traverse tout ça assez tranquillement avant de s'arrêter net dans le chemin de transmission. Les mêmes trois lignes, 3644, 3648 et 3651, dans le même ordre, à chaque exécution.
C'est une limite dure, quoi qu'ait voulu dire le readme, et les erreurs que vous avez collées expliquent pourquoi.
Le kernel a changé la façon de représenter les fragments skb. À partir de 5.4, skb_frag_t est un bio_vec, et struct skb_frag_struct n'existe simplement plus. Du code source qui assigne à un struct skb_frag_struct * mérite exactement votre plainte de la ligne 3644, et tout ce qui le déréférence ensuite pour passer une page et un offset aux appels de mapping DMA mérite l'usage invalide d'un type indéfini sur 3648 et 3651. Aucun header, aucun flag et aucun compilateur plus ancien ne vous contourne un type qui n'existe plus.
Donc sur 5.10, cet arbre a besoin d'être édité plutôt que configuré. La gestion des fragments dans le chemin de transmission doit être réécrite contre les accesseurs actuels, et c'est un vrai patch plutôt qu'une correction d'une ligne, parce que le mapping DMA autour de ces accès change de forme en même temps.
Je ne possède pas une de ces cartes, donc prenez ça comme un diagnostic et non une promesse. Je peux vous dire pourquoi la compilation échoue et que c'est un problème source ; je ne peux pas vous dire que le driver fait ensuite monter un lien.
Avant de sacrifier un week-end à ce patch, regardez ce qui vous attend de l'autre côté.
J'ai ici un StarTech PEX10000SFP, la variante TN9510, PCI 1fc9:4025 avec sous-système 1fc9:3015. Le driver hors arbre tn40xx compile et se charge pour elle, et dmesg est franchement encourageant :
Et ensuite l'interface reste en NO-CARRIER avec une lumière rouge sur le module, indéfiniment. Même carte, même cage, même optique sous le driver Windows de StarTech : ça se lie immédiatement. Donc le matériel est sain et le firmware du PHY se charge, c'est l'étape de liaison de ce driver qui ne finit jamais le travail.
J'ai testé Ubuntu 22.04 et Rocky Linux 8.10, kernels 4.18, 5.15, 6.5 et 6.9, et les branches tn40xx-006, tn40xx-003, linux-6.6 et linux-6.7. Aucun d'eux ne m'a donné de porteuse. Faire compiler le truc est la moitié facile, honnêtement.
C'est l'argument pour dépenser de l'argent plutôt qu'un week-end, et je le dis en tant que quelqu'un qui apprécie normalement l'option week-end. Une carte 10G Intel ou Mellanox d'occasion coûte moins qu'un après-midi de votre temps et son driver est déjà dans le kernel que vous démarrez.
Une chose à savoir si vous partez sur Intel et y mettez une optique tierce. Un X520 refuse carrément le module avec "unsupported SFP+ module type was detected" et vous vous retrouvez sans aucune interface. La correction est une option de module :
Les cartes à deux ports veulent 1,1 là-dedans. Puis update-initramfs -u et un démarrage à froid plutôt que juste décharger et recharger le module, parce que cet état désactivé se fige dans le firmware et un rechargement à chaud ne l'efface souvent pas. Ça, c'est 82599 et X520 uniquement, où la vérification vit dans le driver. Sur X710 la vérification est dans le firmware et cette option ne vous sauvera pas.
Bon conseil, mauvais problème, dans le même souffle. allow_unsupported_sfp concerne la liste blanche d'optiques du driver, et la carte de ce fil ne compile pas du tout - personne ici n'en est même proche du point où une optique serait rejetée. Utile à savoir plus tard, pas une réponse maintenant.
Si l'occasion est envisageable, l'autre carte qui fonctionne simplement est une HP NC523SFP, qui est l'OEM QLogic QLE3242, référence HP 593715-001. Elle tourne sur le driver qlcnic intégré au kernel, donc il n'y a rien du tout à compiler - j'ai un boîtier ici rapportant qlcnic 5.3.66 contre le firmware adaptateur 4.8.20, et il n'a demandé aucune attention depuis son installation.
Deux réserves. Elle chauffe, quelque chose comme 16 à 17 W au repos, ce qui se remarque dans une pièce calme. Et le SR-IOV dessus est un flou que personne à qui j'ai demandé n'a pu confirmer dans un sens ou l'autre. Si vous avez besoin de SR-IOV, le NC552SFP est le meilleur achat, il utilise bnx2x et le supporte correctement, mais il faut activer le forwarding ARI en amont sinon il n'apparaîtra pas.