Le Solarflare SFN7122F sous TrueNAS : la carte est détectée, mais des modules SFP+ multimode qui fonctionnent restent éteints
Je monte une machine de stockage à la maison et j'ai pris un Solarflare SFN7122F double 10GbE (SFC9120) car il était bon marché. La carte elle-même a l'air en bonne santé, le système la voit et les deux ports s'énumèrent, mais aucun de mes modules SFP+ multimode existants ne veut établir de lien dessus.
- Solarflare SFN7122F, double port, contrôleur SFC9120
- TrueNAS SCALE sur le NAS, CORE était le plan initial
- des modules SFP+ multimode 10G qui établissent le lien sans problème sur une autre carte réseau
- un court cordon de brassage multimode, celui utilisé dans le test qui fonctionne
eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP>
eth3: <NO-CARRIER,BROADCAST,MULTICAST,UP>Ce que j'ai essayé :
- les deux ports, les deux modules, les quatre combinaisons, rien n'établit jamais de lien
- déplacé exactement les mêmes modules et le même cordon de brassage vers l'autre carte, le lien monte immédiatement
- échangé les cordons de brassage au cas où il y aurait une face de connecteur sale
Donc la fibre et les modules ne sont pas le problème. Est-ce que cette carte refuse des optiques qui ne sont pas codées pour elle, ou est-ce quelque chose du côté du pilote, et est-ce que CORE se comporterait différemment de SCALE ici ? Si c'est une histoire de codage, quels modules les gens font-ils réellement tourner sur un SFN7122F ?
Comments 3
Le côté pilote n'est pas votre problème. Le pilote sfxge de FreeBSD couvre les adaptateurs 10GbE de la famille Solarflare SFC9000, donc un SFC9120 va bien sous CORE, et vous voyez déjà que SCALE énumère le matériel. Ce que vous rencontrez, c'est le propre contrôle de transceiver de la carte : elle accepte les modules codés pour Solarflare et ignore discrètement le reste, ce qui ressemble exactement à ce que vous avez - une carte en bonne santé avec des ports qui ne montent jamais.
Des pièces que les gens font tourner sur ces cartes : FTLX8571D3BCL-SL et SFM10G-SR. FS fournira aussi des modules pré-codés pour Solarflare si vous précisez la cible à la commande, ce qui est généralement plus simple que de chercher du stock d'origine.
Avant de dépenser quoi que ce soit, pensez à combien de temps cette carte doit encore vivre. Solarflare est passé chez Xilinx et le travail sur le pilote s'est arrêté, donc rien de plus n'arrivera pour elle. Pour une machine que vous voulez oublier, je mettrais Chelsio en premier choix sur cette plateforme et Intel en second. Pour ce que ça vaut, un retour d'expérience de longue durée ici parlait de deux ans de service sans problème avec le SFN6122F, étroitement apparenté, jugé plus tolérant envers des transceivers aléatoires que l'Intel X520 posé juste à côté - mais c'est la carte plus ancienne et ça ne change pas le comportement de codage sur la vôtre.
Commandé une paire de SFM10G-SR codés pour la carte et les deux ports sont montés dès la première insertion, donc la théorie du codage tient. Résultat partiel de mon côté cependant : les anciens modules multimode sont toujours complètement morts sur cette carte réseau et ne fonctionnent que sur l'autre carte, donc je garde maintenant deux jeux d'optiques étiquetés et séparés.
La carte reste pour l'instant puisqu'elle fait son travail, mais l'indice Chelsio est noté pour la prochaine - je préférerais ne pas acheter des optiques spécialement codées à chaque port ajouté.
Ça vaut la peine d'ajouter une vérification à la procédure générale, parce que « optiques non supportées » veut dire des choses très différentes selon le boîtier. Sur un Instant On 1930 24G, la réponse du fabricant lui-même était qu'un module non supporté (SX, LH et similaires) est seulement signalé - LED de port clignotante plus un message syslog - et le port n'est pas du tout désactivé, donc un lien qui reste down là pointe vers le chemin physique, pas vers un verrou. Ce cas s'est terminé avec un nouveau tirage de fibre plus un SFP+ LR monomode 10G tiers et le lien est monté.
Le même piège existe dans l'autre sens avec les HBA : un Brocade 825 apparaît deux fois dans lspci, et insérer des optiques ne produit rien dans dmesg, ce que les gens lisent comme une panne. Les pilotes journalisent l'état du lien, pas l'insertion du module, donc le silence là non plus n'est pas un diagnostic.
Dans votre cas vous avez déjà fait le seul test qui tranche, le même module et le même cordon établissant un lien sur une autre carte réseau, donc un verrou de codage est la bonne conclusion. Juste, ne laissez personne vous convaincre de cette conclusion sur un boîtier où ce n'est qu'une LED et une ligne de journal.