Supermicro AOC-STGN-i1S (X520) en Proxmox 7.1: sin interfaz en ip link con un DAC de HP puesto

Antes de dar la tarjeta por muerta, haz una prueba. Saca el DAC de la jaula por completo, luego rmmod ixgbe, modprobe ixgbe y vuelve a mirar ip link. Si la interfaz aparece con la jaula vacía, la tarjeta y el driver están ambos bien y el cable es lo que está atragantando la comprobación.

Otra cosa que vale la pena saber: ¿ese DAC de HP enlaza en algún otro sitio? Una NIC que no sea de Intel normalmente lo aceptará sin quejarse. ¿Y es definitivamente el cable codificado de HP, o tienes uno genérico por ahí para comparar?

Considérate afortunado de estar en un X520, donde al menos tienes una opción del driver, por poco fiable que sea. En el X710 y el XL710 la comprobación del módulo se trasladó al firmware, así que allow_unsupported_sfp no hace absolutamente nada para i40e. Pon un módulo que no sea de Intel en un X710-DA2 y obtienes:

Rx/Tx is disabled on this device because an unsupported SFP module type was detected

y ahí termina la conversación. Desde ahí las opciones son ópticas codificadas por Intel, la ruta comunitaria xl710-unlocker (subir una imagen de NVM nueva con la propia herramienta de actualización de Intel, y luego ir hurgando en campos de once bits en algún punto alrededor de 0x6800-0x7000 del EEPROM con herramientas de terceros, enteramente bajo tu propio riesgo), o elegir de entrada una variante OEM: una HPE 562SFP+ es un X710 por dentro, y tras actualizar firmware e i40e aceptó módulos de cobre de terceros de 10G y 1G sin trucos de ningún tipo.

En el ángulo OEM, el caso va al revés para las tarjetas X710-DA2 de marca Dell y Lenovo: rechazan SFP+ y DAC no aprobados, y las propias herramientas de Intel ni siquiera listan la placa. En lo que la gente se ha decantado es en flashear NVM de Intel de fábrica en ellas. Primero necesitas el driver QV del paquete BootUtil completo de Intel, de lo contrario las utilidades ni siquiera hablarán con la placa; la ROM de opción se reemplaza antes que nada más, y solo entonces inventarías la tarjeta y la flasheas:

./bootutil64e -NIC=1 -up=combo
./nvmupdate64e -i -l
ethtool -i enp1s0f0
./nvmupdate64e -rd

Entre el inventario y el flasheo, recorta nvmupdate.cfg hasta dejar la única entrada X710 que coincida con el tamaño de la flash SPI de la tarjeta, 4 MB u 8 MB. Elige el tamaño equivocado y tienes un ladrillo que necesita una imagen de NVM guardada y un flasheador de hardware para recuperarse, así que lee primero el ETrackID y asegúrate. Firmware en el rango 9.30-9.40 se reportó funcionando después, y la gente obtuvo SR-IOV en las placas Lenovo como efecto secundario. Yo aun así solo lo probaría en una tarjeta que pudiera permitirme perder.

Cuidado con apuntar las rutas de crossflash y parcheo de EEPROM a este hilo, porque ninguna ayuda en la situación descrita. Editar la bandera OEM en un EEPROM de X520 necesita, para empezar, una interfaz funcional a través de la cual llegar a la tarjeta, y aquí no hay ninguna interfaz en absoluto hasta que el cable sale de la jaula. Eso es un arreglo para un puerto que existe y rechaza un módulo, no para un driver que aborta al cargar.

La otra cosa que no sobrevaloraría es la prueba en otra NIC. Un módulo que enlaza en otro host prueba el módulo, no el host en el que realmente lo quieres. Tengo módulos de cobre Ubiquiti UACC-CM-RJ45-MG que funcionan felizmente en un CCR2004 y en un Intel X520-DA2 bajo Debian, y en las jaulas SFP+ de un CRS309 y un CRS328 nunca enlazan en absoluto, con autonegociación activada o con la velocidad fijada a mano. La dependencia del host es real, así que verifica en la máquina exacta antes de comprar un lote de cualquier cosa.