El driver del fabricante para StarTech ST10GSPEXNB (Tehuti TN4010) no compila en Debian 11, kernel 5.10
Compré un StarTech ST10GSPEXNB para darle a un servidor de respaldo un puerto SFP+ de 10G, dando por hecho que una tarjeta vendida con driver para Linux compilaría contra una distribución actual. Fue optimismo de mi parte.
- StarTech ST10GSPEXNB, chip Tehuti TN4010
- Debian 11, kernel 5.10.0-13-amd64, con los headers correspondientes instalados
- paquete del driver del fabricante tal como viene con la tarjeta
- módulo SFP+ de 10G genérico en la jaula, aunque la tarjeta ni ha llegado tan lejos como para que eso importe
make avanza bastante y luego falla en la ruta de transmisión:
$ 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'Las últimas dos caen en las llamadas de mapeo de DMA.
Lo que ya probé:
- chmod +x mvidtoh.sh, porque la compilación se detenía antes con un permission denied y no generaba los headers del PHY; esa parte ya está resuelta
- comparé uname -r contra los headers instalados, coinciden
- busqué un paquete más nuevo que el que da el fabricante y no encontré absolutamente nada
¿Alguien tiene una de estas corriendo en un kernel de esta década, y si es así, cómo?
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
¿Qué paquete de driver exactamente? ¿Tiene una versión marcada en el tarball, y qué rango de kernel dice su readme que soporta? Cada tarjeta basada en Tehuti que ha pasado por mis manos trae un árbol de fuentes que nombra los kernels soportados en el readme, y normalmente va muy por detrás de lo que realmente estás corriendo.
Vale la pena decir también qué árbol estás compilando. Está el paquete del fabricante que viene con la tarjeta, y están los árboles comunitarios tn40xx: tn40xx-006 y tn40xx-003, más las ramas linux-6.6 y linux-6.7, y no están ni cerca del mismo punto en su historia. La gente compara notas entre ellos todo el tiempo sin notar que están hablando de código distinto.
Última cosa: ¿3644 es realmente el primer error en el log, o hay algo más arriba que estás leyendo como ruido? Esas tres líneas parecen un solo cambio de API, pero si la compilación falló antes, el resto es solo consecuencia de eso.
Los árboles comunitarios son noticia para mí, solo he tenido el tarball que venía en la caja, y todo esto está compilado a partir de eso, descomprimido tal cual venía. Esas ramas son lo siguiente que voy a leer. No hay ninguna versión ni en el tarball ni en el makefile, por si sirve de algo.
El readme es exactamente como lo describes. Habla de kernels 3.x y se detiene en la línea 4.14. Lo leí como una nota sobre en qué habían probado, más que como un límite estricto, lo cual ahora se ve ingenuo.
Y sí, 3644 es el primer error. Arriba no hay más que warnings, variables sin usar, declaraciones implícitas, el tipo de cosas que ese árbol evidentemente produce de forma habitual, y la compilación pasa por todo eso sin problema antes de detenerse en seco en la ruta de transmisión. Las mismas tres líneas, 3644, 3648 y 3651, en el mismo orden, cada vez.
Es un límite estricto, sea lo que sea que quisiera decir el readme, y los errores que pegaste explican por qué.
El kernel cambió cómo se representan los fragmentos de skb. Desde 5.4 en adelante skb_frag_t es un bio_vec, y struct skb_frag_struct simplemente ya no existe. Un código que asigna a un struct skb_frag_struct * se gana exactamente tu queja de la línea 3644, y cualquier cosa que luego lo desreferencia para pasar una página y un offset a las llamadas de mapeo de DMA se gana el uso inválido de un tipo indefinido en 3648 y 3651. Ningún header, ninguna flag y ningún compilador más viejo te libran de un tipo que ya no existe.
Así que en 5.10 ese árbol necesita edición, no configuración. El manejo de fragmentos en la ruta de transmisión hay que reescribirlo contra los accesores actuales, y es un parche de verdad, no un arreglo de una línea, porque el mapeo de DMA alrededor de esos accesos cambia de forma al mismo tiempo.
No tengo una de estas tarjetas, así que tómalo como un diagnóstico y no como una promesa. Puedo decirte por qué falla la compilación y que es un problema de fuente; no puedo decirte que el driver levante el enlace después.
Antes de que le metas un fin de semana a ese parche, mira lo que te espera del otro lado.
Tengo aquí un StarTech PEX10000SFP, la variante TN9510, PCI 1fc9:4025 con subsistema 1fc9:3015. El driver tn40xx fuera del árbol compila y carga para él, y el dmesg es bastante alentador:
Y después la interfaz se queda en NO-CARRIER con la luz roja en el módulo, para siempre. La misma tarjeta, la misma jaula, el mismo óptico bajo el driver de Windows de StarTech: enlaza de inmediato. O sea que el hardware está bien y el firmware del PHY carga, es la etapa de enlace de ese driver la que nunca termina el trabajo.
Pasé por Ubuntu 22.04 y Rocky Linux 8.10, kernels 4.18, 5.15, 6.5 y 6.9, y las ramas tn40xx-006, tn40xx-003, linux-6.6 y linux-6.7. Ninguna me dio carrier. Conseguir que compile es, honestamente, la mitad fácil.
Ese es el argumento para gastar dinero en vez de un fin de semana, y lo digo como alguien a quien normalmente le gusta la opción del fin de semana. Una tarjeta Intel o Mellanox de 10G usada cuesta menos que una tarde de tu tiempo, y su driver ya está en el kernel que estás arrancando.
Una cosa que hay que saber si vas con Intel y le pones un óptico de terceros. Una X520 rechaza el módulo directamente con "unsupported SFP+ module type was detected" y te quedas sin interfaz. El arreglo es una opción del módulo:
Las tarjetas de doble puerto quieren 1,1 ahí. Luego update-initramfs -u y un arranque en frío, no solo descargar y recargar el módulo, porque ese estado deshabilitado queda fijado en el firmware y una recarga en caliente frecuentemente no lo limpia. Eso es solo para 82599 y X520, donde la verificación vive en el driver. En X710 la verificación está en el firmware y esta opción no te va a salvar.
Consejo correcto, problema equivocado, dicho de una vez. allow_unsupported_sfp trata sobre la lista blanca de ópticos del driver, y la tarjeta de este hilo directamente no compila, aquí nadie está ni cerca del punto de que un óptico sea rechazado. Útil saberlo más adelante, no una respuesta ahora.
Si la opción de segunda mano está sobre la mesa, la otra que simplemente funciona es una HP NC523SFP, que es la OEM de QLogic QLE3242, parte HP 593715-001. Corre con el driver qlcnic ya incluido en el kernel, así que no hay nada que compilar, tengo aquí un equipo reportando qlcnic 5.3.66 contra firmware de adaptador 4.8.20, y no ha necesitado atención desde que se instaló.
Dos advertencias. Corre caliente, algo así como 16 a 17 W en reposo, cosa que se nota en un cuarto silencioso. Y el SR-IOV en ella es un lío que nadie a quien pregunté pudo confirmar en un sentido u otro. Si necesitas SR-IOV, la NC552SFP es la mejor compra, usa bnx2x y lo soporta correctamente, pero tienes que habilitar ARI forwarding aguas arriba o no va a aparecer.