Il driver del vendor per StarTech ST10GSPEXNB (Tehuti TN4010) non compila su Debian 11, kernel 5.10
Ho comprato una StarTech ST10GSPEXNB per dare a un server di backup una porta 10G SFP+, partendo dal presupposto che una scheda venduta con un driver Linux compilasse contro una distribuzione attuale. Ero ottimista.
- StarTech ST10GSPEXNB, chip Tehuti TN4010
- Debian 11, kernel 5.10.0-13-amd64, header corrispondenti installati
- pacchetto driver del vendor così come fornito per la scheda
- modulo SFP+ 10G generico nella cage, non che la scheda sia arrivata abbastanza avanti da accorgersene
make procede parecchio e poi cade nel percorso di trasmissione:
$ 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'Gli ultimi due cadono nelle chiamate di mapping DMA.
Provato finora:
- chmod +x mvidtoh.sh, perché la build si fermava prima con un permission denied e non generava gli header del PHY - quella parte è sistemata
- confrontato uname -r con gli header installati, corrispondono
- cercato un pacchetto più recente di quello fornito dal vendor e non ho trovato assolutamente nulla
C'è qualcuno che ne fa girare una su un kernel di questo decennio, e se sì, come?
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
Quale pacchetto driver esattamente - c'è una versione stampigliata sul tarball, e che range di kernel dichiara il suo readme? Ogni scheda basata su Tehuti che mi è passata tra le mani porta un albero sorgenti che nomina i kernel supportati nel readme, e di solito è parecchio indietro rispetto a quello che stai effettivamente usando.
Vale la pena anche dire quale albero stai compilando. C'è il pacchetto del vendor che arriva con la scheda, e ci sono gli alberi comunitari tn40xx - tn40xx-006 e tn40xx-003, più i rami linux-6.6 e linux-6.7 - e non sono affatto allo stesso punto della storia. La gente si scambia note tra questi in continuazione senza accorgersi che sta parlando di codice diverso.
Ultima cosa: la 3644 è davvero il primo errore nel log, o c'è qualcosa più sopra che hai letto come rumore di fondo? Quelle tre righe sembrano un singolo cambio di API, ma se la build si è rotta prima, il resto è solo una conseguenza.
Gli alberi comunitari sono una novità per me - ho sempre avuto solo il tarball arrivato nella scatola, e tutto qui è compilato da quello, scompattato così com'è stato fornito. Quei rami sono la prossima cosa che leggo. Nessuna versione da nessuna parte sul tarball o nel makefile, per quel che vale.
Il readme è esattamente come lo descrivi. Parla di kernel 3.x e si ferma alla linea 4.14. L'avevo letta come un'annotazione su cosa avevano testato piuttosto che un limite rigido, il che adesso sembra ingenuo.
E sì, 3644 è il primo errore. Sopra non c'è altro che warning - variabili inutilizzate, dichiarazioni implicite, il genere di cose che a quanto pare quell'albero produce di routine - e la build li attraversa tutti tranquillamente prima di fermarsi di colpo nel percorso di trasmissione. Le stesse tre righe, 3644, 3648 e 3651, nello stesso ordine, a ogni esecuzione.
È un limite rigido, qualunque cosa intendesse il readme, e gli errori che hai incollato spiegano perché.
Il kernel ha cambiato il modo in cui vengono rappresentati i frammenti skb. Dalla 5.4 in poi skb_frag_t è un bio_vec, e struct skb_frag_struct semplicemente non esiste più. Il sorgente che assegna a uno struct skb_frag_struct * si guadagna esattamente il tuo errore alla riga 3644, e tutto ciò che poi lo dereferenzia per passare una page e un offset alle chiamate di mapping DMA si guadagna l'uso non valido di un tipo indefinito alle righe 3648 e 3651. Nessun header, nessun flag e nessun compilatore più vecchio ti fa aggirare un tipo che non esiste più.
Quindi su 5.10 quell'albero va modificato, non configurato. La gestione dei frammenti nel percorso di trasmissione va riscritta contro gli accessor attuali, ed è una patch vera e propria e non una correzione di una riga, perché il mapping DMA intorno a quegli accessi cambia forma nello stesso momento.
Non possiedo una di queste schede, quindi prendila come una diagnosi e non come una promessa. Posso dirti perché la build fallisce e che è un problema nel sorgente; non posso dirti che dopo il driver porti su un link.
Prima di affondarci dentro un intero weekend con quella patch, dai un'occhiata a cosa ti aspetta dall'altra parte.
Ho qui una StarTech PEX10000SFP, la variante TN9510, PCI 1fc9:4025 con subsystem 1fc9:3015. Il driver tn40xx out-of-tree compila e si carica per lei, e dmesg è decisamente incoraggiante:
E poi l'interfaccia resta su NO-CARRIER con la spia rossa sul modulo, per sempre. Stessa scheda, stessa cage, stessa ottica sotto il driver Windows di StarTech: si aggancia all'istante. Quindi l'hardware è sano e il firmware del PHY si carica, è la fase di link di quel driver che non finisce mai il lavoro.
Ho provato Ubuntu 22.04 e Rocky Linux 8.10, kernel 4.18, 5.15, 6.5 e 6.9, e i rami tn40xx-006, tn40xx-003, linux-6.6 e linux-6.7. Nemmeno uno mi ha dato un carrier. Farlo compilare è onestamente la metà facile.
Questo è l'argomento a favore di spendere soldi invece di un weekend, e lo dico da uno a cui normalmente piace l'opzione weekend. Una scheda 10G Intel o Mellanox usata costa meno di un pomeriggio del tuo tempo e il suo driver è già nel kernel che stai avviando.
Una cosa da sapere se scegli Intel e ci metti dentro un'ottica di terze parti. Una X520 rifiuta il modulo su due piedi con "unsupported SFP+ module type was detected" e ti ritrovi senza interfaccia del tutto. La correzione è un'opzione del modulo:
Le schede dual port lì vogliono 1,1. Poi update-initramfs -u e un cold boot invece di limitarti a scaricare e ricaricare il modulo, perché quello stato disabilitato resta agganciato nel firmware e un reload a caldo spesso non lo pulisce. Questo vale solo per 82599 e X520, dove il controllo vive nel driver. Su X710 il controllo è nel firmware e questa opzione non ti salva.
Consiglio giusto, problema sbagliato, nello stesso respiro. allow_unsupported_sfp riguarda la whitelist delle ottiche del driver, e la scheda di questo thread non compila proprio - qui nessuno è nemmeno vicino al punto in cui un'ottica viene rifiutata. Utile da sapere per dopo, non una risposta per adesso.
Se però l'usato è sul tavolo, l'altra scheda che funziona e basta è una HP NC523SFP, che è la OEM QLogic QLE3242, codice HP 593715-001. Gira sul driver qlcnic già nel kernel, quindi non c'è proprio niente da compilare - ho qui un box che riporta qlcnic 5.3.66 contro firmware dell'adattatore 4.8.20, e non ha richiesto nessuna attenzione da quando è entrato in servizio.
Due avvertenze. Scalda parecchio, qualcosa come 16-17 W a riposo, e si nota in una stanza silenziosa. E lo SR-IOV su questa scheda è un pasticcio che nessuno di quelli a cui ho chiesto ha saputo confermare in un senso o nell'altro. Se ti serve SR-IOV allora la NC552SFP è l'acquisto migliore, usa bnx2x e lo supporta correttamente, ma devi abilitare l'ARI forwarding a monte o non comparirà.