Un Dell M14MK SFP28 refusé sous OpenWrt faute de mode d'interface commun alors qu'un SFP+ QSFPTEK établit le lien
Petit lab à la maison. J'ai flashé un Linksys LGS328C vers OpenWrt SNAPSHOT pour me débarrasser de l'interface web d'origine. Tout a survécu à la migration sauf un port SFP28 qui fonctionnait parfaitement bien auparavant.
- switch : Linksys LGS328C (Realtek rtl930x), OpenWrt SNAPSHOT
- module : Dell S28-10G-25G-SR-85C, double débit 10G/25G, l'EEPROM indique DELL M14MK rev A1
- module de référence dans la même cage : QSFPTEK QT-SFP+-SR
- même fibre et même extrémité distante dans les deux tests
Le module Dell est détecté puis immédiatement rejeté :
sfp sfp-p49: module DELL M14MK rev A1
rtl83xx-switch ...: unsupported SFP module: no common interface modes
# ethtool lan28
Advertised link modes: 10000baseCR/Full
Link detected: noCe que j'ai déjà vérifié :
- remplacé par le SFP+ QSFPTEK dans la même cage : le journal montre le port choisissant inband/10gbase-r, et j'obtiens un lien propre à 10 Gbps ;
- le même module Dell fonctionnait bien sur ce switch avec le firmware d'origine, donc l'optique n'est pas morte ;
- réinséré et nettoyé le connecteur, aucun changement dans le journal.
Est-ce que le module est réellement mal programmé, ou est-ce que le pilote du switch est simplement pointilleux sur une pièce capable de 25G ? Je préférerais comprendre ce cas plutôt que juste acheter une autre optique.
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 5
Ce dump explique tout. La couche sfp du noyau n'a qu'une seule entrée pour déterminer quels modes d'interface un module peut faire fonctionner, et ce sont ces octets de conformité. Si aucun n'est positionné, on obtient un ensemble vide, on l'intersecte avec ce que propose le MAC, on n'obtient rien en commun, et on affiche exactement le message que vous voyez. Le 10000baseCR/Full dans ethtool est ce qui reste côté port, pas quelque chose que le module a demandé. Le firmware constructeur d'origine s'en moque, parce que ces images sautent généralement les octets de conformité et comparent plutôt les chaînes de fabricant et de référence à une liste codée en dur - c'est pour ça que l'optique fonctionnait avant que vous ne flashiez.
Le correctif qui tient réellement est une quirk de module. Dans drivers/net/phy/sfp.c, ajouter une entrée SFP_QUIRK_S qui correspond au fabricant DELL avec la référence M14MK et force ETHTOOL_LINK_MODE_10000baseSR_Full et PHY_INTERFACE_MODE_10GBASER, puis reconstruire l'image. Le port monte comme un lien 10G ordinaire signalant 10000baseSR/Full et la ligne unsupported-module disparaît du journal.
Deux mises en garde. Gardez le patch dans un état envoyable à netdev plutôt que de le garder chez vous : l'EEPROM ne va pas se réparer toute seule et d'autres personnes possèdent la même pièce Dell. Et si vous préférez ne pas maintenir une build de noyau du tout, l'alternative sans histoire est le SFP+ QSFPTEK que vous avez déjà - ce port ne donnera de toute façon que du 10G.
Avant d'accuser le pilote du switch, dumpez l'EEPROM et regardez ce que le module déclare :
ethtool --module-info lan28. Postez les premières lignes du dump hexadécimal ainsi que leethtool lan28complet. « no common interface modes » signifie que le noyau n'a pas pu dériver un seul mode utilisable à partir du module, donc le contenu de ces octets, c'est toute l'histoire ici.Une chose de plus à confirmer : le QSFPTEK est-il bien dans la même cage, pas une cage voisine ? Votre ligne de journal indique p49 alors que la sortie ethtool indique lan28, et confondre les ports dans ce genre de test fait perdre beaucoup de temps.
Dumpé. En résumé : il n'y a aucun code de conformité 10G positionné du tout - ces octets sont simplement vides, tandis que les chaînes de fabricant et de référence sont renseignées exactement comme on s'y attendrait pour un DELL M14MK rev A1.
ethtool lan28montre toujoursAdvertised link modes: 10000baseCR/FulletLink detected: no, etdmesg | grep lan25ne remonte rien de plus que les deux lignes de mon premier message.Donc le module ne dit presque rien à l'hôte sur ce qu'il peut réellement faire, et le QSFPTEK dans la même cage établit toujours un lien à 10 Gbps.
Ça vaut le coup d'être noté, parce qu'un rapport de bug antérieur sur exactement cette même paire avait supposé autre chose. La théorie était que le module double débit annonce 25gbase-r, que le pilote rtl930x n'implémente pas ce mode, que l'intersection est vide et que le module lui-même n'a rien de défaillant. Le dump hexadécimal tue cette explication : le module n'annonce rien, pas du 25G. Même message du noyau, cause différente, et seul le dump permet de distinguer les deux.
C'est aussi un rappel qu'une optique de marque n'est pas automatiquement codée correctement. L'OS10 de Dell affichera un véritable Q28-128GFC-SW4 (référence KP0VM) comme QSFP28 100GBASE-SR4 avec Qualified à false, parce que certains lots portent un codage EEPROM que sa qualification média ne reconnaît pas, et le lien FC reste down tant qu'on n'autorise pas manuellement les transceivers non pris en charge.
J'ai construit une image avec l'entrée SFP_QUIRK_S pour DELL / M14MK et elle fait exactement ce que vous avez décrit. Le port monte à 10 Gbps,
ethtool lan28signale maintenant 10000baseSR/Full avec le lien up, et le journal est propre - aucune ligne unsupported-module nulle part. Je l'ai laissé tourner avec du vrai trafic pendant quelques jours avant de toucher à autre chose sur la machine, aucun flap.Je suis en train de nettoyer le patch pour l'envoyer à netdev, parce que le garder dans mon propre arbre n'aide personne. Merci de m'avoir poussé vers le dump module-info en premier, j'avais passé deux soirées à lire les tables de modes du pilote.