Un Intel X520 dans un R630 rejette un SFP+ cuivre 10GBASE-T avec comp_codes_10g=0x00 malgré allow_unsupported_sfp=1
On consolide une paire de R630 en 10G et le câblage vers le haut de la baie est en cuivre, donc au lieu de tirer de la fibre j'ai mis des modules SFP+ 10GBASE-T dans les cartes X520. Le côté switch les accepte sans broncher. Les serveurs refusent.
- Dell PowerEdge R630, Intel X520 (82599), double port
- FS SFP-10GM-T-30, codé Dell, un module par serveur
- ixgbe hors arbre d'Intel, compilé via DKMS
- /etc/modprobe.d/ixgbe.conf avec le contournement réglé pour les deux ports
# 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=0x00Ce que j'ai déjà essayé :
modprobe ixgbe allow_unsupported_sfp=1à la main, en plus de l'entrée modprobe.d- reconstruit l'initramfs et redémarré la machine à froid, pas juste rechargé le module
- déplacé le module vers le second port puis vers le second serveur, même résultat
La partie intéressante, c'est cet octet de conformité : le module ne rapporte absolument rien pour le 10G. Est-ce que le driver teste ça avant même de regarder le contournement, et y a-t-il quelque chose à faire sans acheter des optiques avec le bon codage ?
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
Vous ne luttez pas contre une liste blanche, vous luttez contre l'ordre des vérifications.
SFF-8472 n'a pas de bit de conformité pour le 10GBASE-T. Il n'y a tout simplement pas de code point pour ça, donc un SFP+ cuivre honnête rapporte des codes de conformité 10G entièrement à zéro, ce qui est exactement votre
comp_codes_10g=0x00. ixgbe lit cet octet, ne trouve rien qu'il reconnaisse comme module 10G et abandonne là, bien avant d'approcher le contournementallow_unsupported_sfp. C'est pourquoi le flag fonctionne bien pour un module optique non qualifié ou un DAC et ne fait absolument rien pour vos modules cuivre.Il existe un patch communautaire contre l'ixgbe hors arbre d'Intel qui déplace le test de conformité : quand l'administrateur a explicitement réglé
allow_unsupported_sfp=1, un module rapportant des codes de conformité 10G entièrement à zéro est classé comme SR au lieu d'être rejeté tôt. Il a été soumis en amont et reste encore non fusionné, donc vous l'appliquez vous-même à la source DKMS et le gardez avec votre build. La personne qui l'a écrit a rapporté du 10 Gb/s full duplex sur une paire de serveurs ensuite, et quelqu'un d'autre a confirmé que le même patch fait fonctionner des modules cuivre HLX-SFPX dans un X520.Deux réserves avant de le faire. Une optique qu'Intel n'a pas qualifiée est hors de leur garantie de compatibilité, donc ça devient votre problème, pas le leur. Et le PHY 10GBASE-T est une pièce qui chauffe - dans une cage serveur sans flux d'air propre, elle se retrouvera bien au-dessus de tout ce qui est optique dans l'emplacement voisin, donc surveillez la température du module une fois le lien monté.
Deux choses à préciser avant de patcher quoi que ce soit.
D'abord, affichez le paramètre tel que le noyau le voit réellement,
/sys/module/ixgbe/parameters/allow_unsupported_sfp, sur une machine qui est passée par un démarrage à froid plutôt qu'un rechargement de module. Si ça ne renvoie pas exactement ce qui figure dans votre fichier conf, quelque chose charge le driver avant que votre config ne soit prise en compte et le reste du débogage est gaspillé.Ensuite, quel ixgbe est chargé ?
ethtool -ine vous sert à rien tant que le driver ne finit jamais de charger et que les interfaces sont absentes, donc postez ce que rapportemodinfo ixgbeet la version du paquet DKMS que vous avez compilé.Et d'où vient ce
comp_codes_10g=0x00- est-ce le driver qui vous le dit, ou avez-vous dumpé l'EEPROM du module vous-même ?Le paramètre est
1,1dans le fichier et/sys/module/ixgbe/parameters/allow_unsupported_sfprenvoie1,1après un démarrage à froid, donc il est bien appliqué, pas ignoré en silence. L'initramfs a été reconstruit avant le démarrage. Même ligne dans dmesg dans les deux cas.Les codes de conformité, je les ai lus moi-même à partir des données SFF-8472 du module, pas depuis le driver - l'octet de conformité 10G est à zéro, tout le reste dans les champs d'identification a l'air sain. Le même module dans le port du switch monte à 10G, donc ce n'est pas un module mort.
Utile à ajouter côté pratique : avec DKMS, chaque mise à jour du noyau reconstruit à partir des sources sur disque, donc le patch doit vivre dans cet arbre de sources, pas dans un répertoire de build que vous avez nettoyé après coup. Vérifiez que le port revient après la première montée de noyau plutôt que de le découvrir pendant une fenêtre de redémarrage.
La leçon plus large de cette catégorie de problème, c'est que l'ancienneté du driver compte plus que le codage du module. Même histoire sur un X710 avec un DAC passif : un câble, un port, content sous Ubuntu 24.04 et mort sous TrueNAS SCALE avec
Link detected: noetSpeed: Unknown, parce que ce build embarquait l'i40e issu du noyau 6.6.44-production. Sous 25.04-BETA.1, où l'i40e vient du 6.12.9-production, le twinax est monté tout seul - rien d'autre touché, carte toujours en firmware 9.20. Les optiques allaient bien sur ce port sous les deux systèmes, ce qui a fixé la faute sur la façon dont l'ancien driver gère le cuivre passif. Unethtool -ides deux côtés de la comparaison aurait évité beaucoup d'échanges de câbles.Type de module différent, même driver, et un piège à écarter tant que vous y êtes. Un Dell R720 avec une carte fille X520, des modules Cisco 10G multimode LC refusés, interfaces tout simplement absentes. L'option était dans modprobe.d, elle était aussi dans GRUB, et rien n'a changé - parce que l'hôte démarre en EFI et que cette ligne de commande GRUB n'était jamais utilisée.
Sur un Proxmox démarré en EFI, le paramètre a sa place dans
/etc/kernel/cmdlinesous la formeixgbe.allow_unsupported_sfp=1, suivi depve-efiboot-tool refresh. Dans ce cas même ça n'a pas réglé le problème et ils ont fini par acheter des modules de marque Intel, donc traitez ça comme quelque chose à éliminer plutôt que comme un remède.L'autre chose issue de ce bazar : les deux extrémités doivent être satisfaites de l'optique indépendamment. Un module que le switch accepte peut quand même être rejeté par l'hôte, ce qui est exactement où vous en êtes déjà.
Patch appliqué à la source DKMS et reconstruit. Les deux ports montent à 10 Gb/s full duplex et sont restés up sous charge depuis.
Ça fonctionne, mais je ne dirais pas que c'est résolu. C'est un patch non fusionné que je dois maintenant porter à chaque mise à jour du noyau, et le driver présente le port comme SR, ce qui va perturber quiconque regardera ce boîtier après moi. Le module tourne aussi nettement plus chaud que les optiques de la cage voisine et cet emplacement n'a pas de flux d'air digne de ce nom. Pour le prochain lot de serveurs, je tirerai de la fibre et arrêterai de discuter avec le driver.