Supermicro AOC-STGN-i1S (X520) sous Proxmox 7.1 : aucune interface dans ip link avec un DAC HP en place

Avant de condamner la carte, fais un test. Retire complètement le DAC de la cage, puis rmmod ixgbe, modprobe ixgbe et regarde à nouveau ip link. Si l'interface apparaît avec la cage vide, la carte et le driver sont tous les deux bons et c'est le câble qui coince la vérification.

Autre chose qui vaut la peine d'être sue : ce DAC HP lie-t-il ailleurs ? Une carte réseau non-Intel le prend normalement sans un mot de plainte. Et es-tu sûr que c'est bien le câble codé HP, ou as-tu un générique qui traîne pour comparer ?

Estime-toi chanceux d'être sur un X520, où tu as au moins un levier au niveau du driver, aussi capricieux soit-il. Sur X710 et XL710, la vérification de module est passée dans le firmware, donc allow_unsupported_sfp ne fait absolument rien pour i40e. Mets un module non-Intel dans un X710-DA2 et tu obtiens :

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

et c'est la fin de la discussion. À partir de là, les options sont des optiques codées Intel, la voie communautaire xl710-unlocker (pousser une image NVM neuve avec l'outil de mise à jour propre d'Intel, puis aller fouiller des champs de onze bits quelque part autour de 0x6800-0x7000 dans l'EEPROM avec des outils tiers, entièrement à tes risques), ou choisir dès le départ une variante OEM : un HPE 562SFP+ est un X710 en dessous, et après des mises à jour du firmware et d'i40e, il a accepté des modules cuivre 10G et 1G tiers sans aucun bidouillage.

Sur l'angle OEM, ça joue dans l'autre sens pour les cartes X710-DA2 de marque Dell et Lenovo : elles rejettent les SFP+ et DAC non approuvés, et les propres outils d'Intel ne listent même pas la carte. Ce sur quoi les gens se sont arrêtés, c'est de flasher du NVM Intel stock dessus. Il faut d'abord le driver QV du paquet BootUtil complet d'Intel, sinon les utilitaires ne parlent pas du tout à la carte ; l'option ROM est remplacée avant tout le reste, et c'est seulement ensuite qu'on inventorie la carte et qu'on la flashe :

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

Entre l'inventaire et le flashage, réduis nvmupdate.cfg à la seule entrée X710 correspondant à la taille de flash SPI de la carte, 4 Mo ou 8 Mo. Choisis la mauvaise taille et tu as une brique qui a besoin d'une image NVM sauvegardée et d'un flasheur matériel pour se récupérer, donc lis d'abord l'ETrackID et sois sûr. Du firmware dans la plage 9.30-9.40 a été rapporté comme fonctionnel ensuite, et les gens ont récupéré le SR-IOV sur les cartes Lenovo en prime. Je ne l'essaierais quand même que sur une carte que je peux me permettre de perdre.

Attention à orienter les voies de crossflash et de patch EEPROM vers ce fil, parce qu'aucune des deux n'aide la situation telle que décrite. Modifier le drapeau OEM dans une EEPROM X520 nécessite déjà une interface fonctionnelle pour atteindre la carte, et ici il n'y a aucune interface du tout tant que le câble n'est pas sorti de la cage. C'est une correction pour un port qui existe et rejette un module, pas pour un driver qui abandonne au chargement.

L'autre chose que je ne surinterpréterais pas, c'est le test dans une autre carte réseau. Un module qui lie dans un autre hôte prouve le module, pas l'hôte dans lequel tu veux réellement l'utiliser. J'ai des modules cuivre Ubiquiti UACC-CM-RJ45-MG qui tournent joyeusement dans un CCR2004 et dans une Intel X520-DA2 sous Debian, et dans les cages SFP+ d'un CRS309 et d'un CRS328 ils ne lient jamais, que l'autonégociation soit activée ou que la vitesse soit fixée à la main. La dépendance à l'hôte est réelle, donc vérifie sur la machine exacte avant d'acheter un lot de quoi que ce soit.