Un Intel X520 en un R630 rechaza un SFP+ de cobre 10GBASE-T con comp_codes_10g=0x00 pese a allow_unsupported_sfp=1
Estamos consolidando un par de R630 en 10G y el cableado hasta la parte superior del rack es de cobre, así que en vez de tender fibra puse módulos SFP+ 10GBASE-T en las tarjetas X520. El lado del switch los acepta sin rechistar. Los servidores se niegan.
- Dell PowerEdge R630, Intel X520 (82599), doble puerto
- FS SFP-10GM-T-30, codificado como Dell, un módulo por servidor
- ixgbe de Intel fuera de árbol, compilado mediante DKMS
- /etc/modprobe.d/ixgbe.conf con la anulación fijada en ambos puertos
# cat /etc/modprobe.d/ixgbe.conf
options ixgbe allow_unsupported_sfp=1,1
# dmesg
ixgbe: failed to load because an unsupported SFP+ module type was detected
# 10G compliance codes read back from the module
comp_codes_10g=0x00Qué he probado ya:
modprobe ixgbe allow_unsupported_sfp=1a mano además de la entrada en modprobe.d- reconstruí el initramfs y arranqué en frío la máquina, no solo recargué el módulo
- moví el módulo al segundo puerto y luego al segundo servidor, mismo resultado
Lo interesante es ese byte de compliance: el módulo no reporta nada en absoluto para 10G. ¿El driver comprueba eso antes de siquiera mirar la anulación, y hay algo que hacer aparte de comprar óptica con la codificación correcta?
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
No estás luchando contra una lista blanca, estás luchando contra el orden de las comprobaciones.
SFF-8472 no tiene ningún bit de compliance para 10GBASE-T. Simplemente no existe ese punto de código, así que un SFP+ de cobre honesto reporta códigos de compliance de 10G todo a cero, que es exactamente tu
comp_codes_10g=0x00. ixgbe lee ese byte, no encuentra nada que reconozca como módulo de 10G y se rinde ahí mismo, antes de llegar siquiera a la anulaciónallow_unsupported_sfp. Por eso el flag funciona bien con un módulo óptico no cualificado o un DAC y no hace absolutamente nada con tus módulos de cobre.Existe un parche de la comunidad contra el ixgbe fuera de árbol de Intel que mueve la comprobación de compliance: cuando el administrador ha fijado explícitamente
allow_unsupported_sfp=1, un módulo que reporta códigos de compliance de 10G todo a cero se clasifica como SR en vez de descartarse pronto. Se envió upstream y sigue sin fusionarse, así que lo aplicas a mano sobre el código fuente de DKMS y lo mantienes con tu compilación. Quien lo escribió reportó 10 Gb/s full duplex en un par de servidores después, y otra persona confirmó que el mismo parche hace funcionar los módulos de cobre HLX-SFPX en un X520.Dos advertencias antes de hacerlo. Una óptica que Intel no ha cualificado queda fuera de su garantía de compatibilidad, así que esto se convierte en tu problema, no en el suyo. Y el PHY 10GBASE-T es una pieza que calienta mucho -en una jaula de servidor sin flujo de aire propio se quedará bastante por encima de cualquier óptica en la ranura vecina, así que vigila la temperatura del módulo una vez que el enlace esté arriba.
Dos cosas que aclarar antes de ponerte a parchear nada.
Primero, imprime el parámetro tal como lo ve realmente el kernel,
/sys/module/ixgbe/parameters/allow_unsupported_sfp, en una máquina que haya pasado por un arranque en frío y no por una recarga del módulo. Si eso no devuelve exactamente lo que pusiste en tu archivo de configuración, algo está cargando el driver antes de que tu configuración entre en juego, y el resto de la depuración se desperdicia.Segundo, ¿qué ixgbe está cargado?
ethtool -ino te sirve mientras el driver nunca termina de cargar y las interfaces están ausentes, así que publica lo que reportamodinfo ixgbey la versión del paquete DKMS que compilaste.Y ese
comp_codes_10g=0x00, ¿de dónde sale? ¿Te lo dice el driver, o volcaste tú mismo la EEPROM del módulo?El parámetro es
1,1en el archivo y/sys/module/ixgbe/parameters/allow_unsupported_sfpdevuelve1,1tras un arranque en frío, así que se aplica, no se ignora silenciosamente. El initramfs se reconstruyó antes del arranque. Misma línea en dmesg en ambos casos.Los códigos de compliance los leí yo mismo del módulo a partir de los datos de SFF-8472, no del driver -el byte de compliance de 10G es cero, todo lo demás en los campos de identificación parece razonable. El mismo módulo en el puerto del switch enlaza a 10G, así que no es un módulo muerto.
Vale la pena añadir, en el lado práctico: con DKMS cada actualización de kernel recompila desde las fuentes en disco, así que el parche tiene que vivir en ese árbol de fuentes, no en un directorio de compilación que luego limpiaste. Comprueba que el puerto vuelve tras la primera subida de kernel en vez de descubrirlo durante una ventana de reinicio.
La lección más amplia de esta clase de problema es que la antigüedad del driver decide más que la codificación del módulo. Misma historia en un X710 con un DAC pasivo: un cable, un puerto, contento bajo Ubuntu 24.04 y muerto bajo TrueNAS SCALE con
Link detected: noySpeed: Unknown, porque esa versión llevaba el i40e del kernel 6.6.44-production. En 25.04-BETA.1, donde el i40e viene del 6.12.9-production, el twinax subió solo -nada más se tocó, la tarjeta seguía en firmware 9.20. La óptica funcionaba bien en ese puerto en ambos sistemas, lo cual señaló el fallo hacia cómo el driver más antiguo maneja el cobre pasivo. Unethtool -ien ambos lados de la comparación habría ahorrado mucho intercambio de cables.Distinto tipo de módulo, mismo driver, y una trampa que conviene descartar ya que estás en ello. Dell R720 con una tarjeta hija X520, módulos LC multimodo de 10G de Cisco rechazados, interfaces simplemente ausentes. La opción estaba en modprobe.d, también estaba en GRUB, y no cambió nada -porque el host arranca por EFI y esa línea de comandos de GRUB nunca se usó.
En un Proxmox arrancado por EFI el parámetro va en
/etc/kernel/cmdlinecomoixgbe.allow_unsupported_sfp=1, seguido depve-efiboot-tool refresh. En ese caso ni siquiera eso lo arregló y acabaron comprando módulos de marca Intel, así que trátalo como algo que descartar y no como una cura.Lo otro de ese lío: los dos extremos tienen que estar conformes con la óptica de forma independiente. Un módulo que el switch acepta puede seguir siendo rechazado por el host, que es justo donde estás ahora.
Apliqué el parche al código fuente de DKMS y recompilé. Ambos puertos suben a 10 Gb/s full duplex y se han mantenido arriba bajo carga desde entonces.
Funciona, pero no lo llamaría resuelto. Es un parche sin fusionar que ahora arrastro en cada actualización de kernel, y el driver presenta el puerto como SR, lo que confundirá a quien mire este equipo después de mí. El módulo también corre notablemente más caliente que la óptica de la jaula de al lado, y esa ranura no tiene flujo de aire que valga la pena. Para el próximo lote de servidores tenderé fibra y dejaré de discutir con el driver.