Solarflare SFN7122F unter TrueNAS: Karte wird erkannt, aber funktionierende Multimode-SFP+-Module bleiben dunkel
Baue zu Hause eine Storage-Box und habe mir eine Dual-10GbE-Solarflare-SFN7122F (SFC9120) geholt, weil sie billig war. Die Karte selbst sieht gesund aus, das System sieht sie, und beide Ports enumerieren, aber keins meiner vorhandenen Multimode-SFP+-Module bringt darin einen Link hoch.
- Solarflare SFN7122F, Dual Port, SFC9120-Controller
- TrueNAS SCALE auf dem NAS, CORE war der ursprüngliche Plan
- 10G-Multimode-SFP+-Module, die in einer anderen NIC klaglos linken
- kurzes Multimode-Patchkabel, dasselbe wie im funktionierenden Test
eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP>
eth3: <NO-CARRIER,BROADCAST,MULTICAST,UP>Was ich probiert habe:
- beide Ports, beide Module, alle vier Kombinationen, nie linkt irgendetwas
- genau dieselben Module und dasselbe Patchkabel in die andere Karte verschoben, Link kommt sofort hoch
- Patchkabel getauscht, falls die Endfläche schmutzig war
Faser und Module sind also nicht das Problem. Lehnt diese Karte Optik ab, die nicht für sie codiert ist, oder ist etwas auf der Treiberseite falsch, und würde sich CORE hier anders verhalten als SCALE? Falls es an der Codierung liegt, welche Module haben Leute tatsächlich in einer SFN7122F laufen?
Comments 3
Die Treiberseite ist nicht dein Problem. Der FreeBSD-Treiber sfxge deckt die 10GbE-Adapter der Solarflare-SFC9000-Familie ab, ein SFC9120 ist unter CORE also in Ordnung, und du siehst schon, dass SCALE die Hardware enumeriert. Was dich trifft, ist die eigene Transceiver-Prüfung der Karte: Sie akzeptiert für Solarflare codierte Module und ignoriert den Rest still, was genau wie das aussieht, was du hast - eine gesunde Karte mit Ports, die nie hochkommen.
Teile, die Leute tatsächlich darin laufen haben: FTLX8571D3BCL-SL und SFM10G-SR. FS liefert auf Wunsch auch für Solarflare vorcodierte Module, wenn man beim Bestellen das Zielgerät angibt, was meist einfacher ist, als original codierten Bestand aufzutreiben.
Bevor du irgendetwas ausgibst, überleg, wie lange diese Karte noch leben muss. Solarflare ist zu Xilinx gewandert, und die Treiberarbeit ist eingestellt, es kommt also nichts mehr dafür. Für eine Box, die man vergessen möchte, würde ich auf dieser Plattform Chelsio an erste Stelle setzen und Intel an zweite. Für das, was es wert ist: Ein länger laufender Bericht hier sprach von zwei Jahren problemlosem Betrieb mit der eng verwandten SFN6122F, eingeschätzt als toleranter gegenüber beliebigen Transceivern als der daneben sitzende Intel X520 - aber das ist die ältere Karte, und das ändert nichts am Codierungsverhalten deiner.
Habe ein Paar SFM10G-SR bestellt, codiert für die Karte, und beide Ports kamen beim ersten Einstecken hoch, die Codierungstheorie hält also. Von meiner Seite trotzdem nur ein Teilerfolg: Die alten Multimode-Module sind in dieser NIC weiterhin völlig tot und funktionieren nur in der anderen Karte, ich halte jetzt also zwei Sätze Optik beschriftet und getrennt.
Die Karte bleibt vorerst, weil sie ihren Job macht, aber der Chelsio-Hinweis ist fürs nächste Mal vermerkt - ich würde lieber nicht jedes Mal, wenn ich einen Port hinzufüge, speziell codierte Optik kaufen.
Lohnt sich, dem allgemeinen Vorgehen eine Prüfung hinzuzufügen, denn "nicht unterstützte Optik" bedeutet je nach Box sehr Unterschiedliches. An einer Instant On 1930 24G war die eigene Antwort des Herstellers, dass ein nicht unterstütztes Modul (SX, LH und ähnliche) nur markiert wird - blinkende Port-LED plus eine Syslog-Meldung -, und der Port wird überhaupt nicht deaktiviert, ein dort unten bleibender Link deutet also auf den physischen Pfad, nicht auf eine Sperre. Dieser Fall endete mit einer neuen Faserstrecke plus einem 10G-Singlemode-LR-SFP+ eines Drittanbieters, und der Link kam hoch.
Dieselbe Falle läuft bei HBAs in die andere Richtung: Ein Brocade 825 erscheint zweimal in lspci, und das Einstecken von Optik erzeugt nichts in dmesg, was Leute als Fehler lesen. Treiber loggen Link-Status, nicht das Einstecken eines Moduls, Stille dort ist also auch keine Diagnose.
In deinem Fall hast du schon den einen Test gefahren, der es klärt, dasselbe Modul und dasselbe Kabel linken in einer anderen NIC, eine Codierungssperre ist also der richtige Schluss. Lass dir nur auf einer Box, wo es nur eine LED und eine Log-Zeile sind, nicht diesen Schluss einreden.