Driver do vendor do StarTech ST10GSPEXNB (Tehuti TN4010) não compila no Debian 11, kernel 5.10
Comprei um StarTech ST10GSPEXNB para dar a um servidor de backup uma porta SFP+ 10G, partindo do princípio de que uma placa vendida com driver para Linux compilaria numa distribuição atual. Foi otimismo demais da minha parte.
- StarTech ST10GSPEXNB, chip Tehuti TN4010
- Debian 11, kernel 5.10.0-13-amd64, headers correspondentes instalados
- pacote de driver do vendor como enviado junto com a placa
- módulo SFP+ 10G genérico na gaiola, não que a placa tenha chegado perto o bastante de se importar com isso
O make avança bastante e depois quebra no caminho de transmissão:
$ 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'As duas últimas caem nas chamadas de mapeamento de DMA.
Já tentei:
- chmod +x mvidtoh.sh, porque o build parava antes com um permission denied e não gerava os headers do PHY - essa parte está resolvida
- conferi o uname -r contra os headers instalados, eles batem
- procurei por um pacote mais novo do que o que o vendor distribui e não achei absolutamente nada
Alguém está rodando um desses num kernel desta década, e se sim, como?
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
Qual pacote de driver exatamente - tem alguma versão gravada no tarball, e que faixa de kernel o readme dele reivindica? Toda placa baseada em Tehuti que já passou pela minha mão vem com uma árvore de fontes que nomeia os kernels suportados no readme, e normalmente está bem atrasada em relação ao que você está realmente rodando.
Vale dizer também qual árvore você está compilando. Existe o pacote do vendor que vem com a placa, e existem as árvores tn40xx da comunidade - tn40xx-006 e tn40xx-003, mais os branches linux-6.6 e linux-6.7 - e elas não estão nem perto do mesmo ponto na história. As pessoas comparam notas entre elas o tempo todo sem perceber que estão discutindo códigos diferentes.
Última coisa: o 3644 é realmente o primeiro erro no log, ou tem algo mais acima que você está lendo como ruído? Essas três linhas parecem uma única mudança de API, mas se o build quebrou antes, o resto é só consequência disso.
Árvores da comunidade são novidade para mim - só tive o tarball que veio na caixa, e tudo aqui é compilado a partir dele, descompactado como veio. Esses branches são a próxima coisa que vou ler. Nenhuma versão em lugar nenhum, nem no tarball nem no makefile, para constar.
O readme é exatamente como você descreve. Fala de kernels 3.x e para na linha do 4.14. Entendi isso como uma nota sobre o que eles tinham testado, e não como um limite rígido, o que agora parece ingenuidade.
E sim, 3644 é o primeiro erro. Acima dele não há nada além de warnings - variáveis não usadas, declarações implícitas, o tipo de coisa que aquela árvore evidentemente produz por padrão - e o build passa por tudo isso tranquilamente antes de parar de vez no caminho de transmissão. As mesmas três linhas, 3644, 3648 e 3651, na mesma ordem, em toda execução.
É um limite rígido, seja lá o que o readme quisesse dizer com aquilo, e os erros que você colou explicam bem o porquê.
O kernel mudou a forma como os fragmentos de skb são representados. A partir da 5.4, skb_frag_t é um bio_vec, e a struct skb_frag_struct simplesmente não existe mais. Código que atribui a um struct skb_frag_struct * ganha exatamente a sua reclamação da linha 3644, e qualquer coisa que depois desreferencia isso para passar uma página e um offset às chamadas de mapeamento de DMA ganha o invalid use of an undefined type nas linhas 3648 e 3651. Nenhum header, nenhuma flag e nenhum compilador mais antigo te tira dessa, é um tipo que não existe mais.
Então na 5.10 essa árvore precisa de edição, não de configuração. O tratamento de fragmentos no caminho de transmissão tem que ser reescrito contra os acessores atuais, e é um patch de verdade, não um ajuste de uma linha só, porque o mapeamento de DMA em torno desses acessos muda de forma ao mesmo tempo.
Eu não tenho uma dessas placas, então encare isso como diagnóstico, não como promessa. Consigo te dizer por que o build falha e que é um problema de código-fonte; não consigo te dizer que o driver sobe um link depois disso.
Antes de afundar um fim de semana nesse patch, dá uma olhada no que está esperando do outro lado dele.
Tenho aqui um StarTech PEX10000SFP, a variante TN9510, PCI 1fc9:4025 com subsystem 1fc9:3015. O driver tn40xx fora da árvore compila e carrega nele, e o dmesg é bem animador:
E então a interface fica em NO-CARRIER com uma luz vermelha no módulo, para sempre. Mesma placa, mesma gaiola, mesma óptica sob o driver Windows da StarTech: linka na hora. Então o hardware está bom e o firmware do PHY carrega, é o estágio de link dessa porta do driver que nunca termina o trabalho.
Passei por Ubuntu 22.04 e Rocky Linux 8.10, kernels 4.18, 5.15, 6.5 e 6.9, e pelos branches tn40xx-006, tn40xx-003, linux-6.6 e linux-6.7. Nenhum deles me deu carrier. Fazer a coisa compilar é a metade fácil, sinceramente.
Esse é o argumento para gastar dinheiro em vez de um fim de semana, e digo isso como alguém que normalmente curte a opção do fim de semana. Uma placa Intel ou Mellanox 10G usada custa menos do que uma tarde do seu tempo, e o driver dela já está no kernel que você está bootando.
Uma coisa para saber se você for de Intel e colocar uma óptica de terceiros nela. Uma X520 recusa o módulo de cara com "unsupported SFP+ module type was detected" e você fica sem interface nenhuma. A correção é uma opção de módulo:
Placas de porta dupla querem 1,1 ali. Depois update-initramfs -u e um boot frio, em vez de só descarregar e recarregar o módulo, porque esse estado desabilitado fica travado no firmware e um reload a quente frequentemente não limpa isso. Isso é só para 82599 e X520, onde a checagem mora no driver. Na X710 a checagem está no firmware e essa opção não vai te salvar.
Conselho certo, problema errado, na mesma respiração. allow_unsupported_sfp é sobre a whitelist de óptica do driver, e a placa deste tópico nem compila - ninguém aqui está nem perto do ponto de ter uma óptica rejeitada. Útil de saber mais tarde, não é resposta agora.
Se usado estiver na mesa, porém, a outra opção que simplesmente funciona é uma HP NC523SFP, que é a OEM da QLogic QLE3242, part number HP 593715-001. Ela roda no driver qlcnic que já está no kernel, então não tem nada para compilar - tenho aqui uma caixa reportando qlcnic 5.3.66 contra firmware de adaptador 4.8.20, e ela não precisou de nenhuma atenção desde que entrou em serviço.
Duas ressalvas. Ela esquenta, algo em torno de 16 a 17 W em idle, o que dá para notar numa sala silenciosa. E o SR-IOV nela é uma confusão que ninguém que perguntei conseguiu confirmar de um jeito ou de outro. Se você precisa de SR-IOV, a NC552SFP é a melhor compra, ela usa bnx2x e suporta isso direito, mas você tem que habilitar ARI forwarding a montante dela, ou ela não vai aparecer.