Solarflare SFN7122F onder TrueNAS: kaart wordt gedetecteerd, maar werkende multimode SFP+-modules blijven donker
Ik bouw thuis een storage-doos en heb een dual 10GbE Solarflare SFN7122F (SFC9120) op de kop getikt omdat hij goedkoop was. De kaart zelf ziet er gezond uit, het systeem ziet hem en beide poorten enumereren, maar geen enkele van mijn bestaande multimode SFP+-modules krijgt er een link in omhoog.
- Solarflare SFN7122F, dual port, SFC9120-controller
- TrueNAS SCALE op de NAS, CORE was het oorspronkelijke plan
- 10G multimode SFP+-modules die zonder klagen linken in een andere NIC
- korte multimode patchkabel, dezelfde die gebruikt is bij de werkende test
eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP>
eth3: <NO-CARRIER,BROADCAST,MULTICAST,UP>Wat ik geprobeerd heb:
- beide poorten, beide modules, alle vier combinaties, er linkt nooit iets
- exact dezelfde modules en dezelfde patchkabel naar de andere kaart verplaatst, link komt meteen op
- patchkabels gewisseld voor het geval van een vuil eindvlak
Dus de fiber en de modules zijn niet het probleem. Weigert deze kaart optiek die niet voor haar gecodeerd is, of zit er iets fout aan de driverkant, en zou CORE zich hier anders gedragen dan SCALE? Als het codering is, welke modules hebben mensen daadwerkelijk draaien in een SFN7122F?
Comments 3
De driverkant is niet je probleem. De FreeBSD sfxge-driver dekt de Solarflare SFC9000-familie van 10GbE-adapters, dus een SFC9120 is prima op CORE, en je ziet al dat SCALE de hardware enumereert. Waar je tegenaan loopt is de eigen transceiver-check van de kaart: die accepteert modules die voor Solarflare gecodeerd zijn en negeert de rest stilletjes, wat er precies zo uitziet als wat jij hebt - een gezonde kaart met poorten die nooit opkomen.
Onderdelen die mensen er daadwerkelijk in draaiend hebben: FTLX8571D3BCL-SL en SFM10G-SR. FS levert ook modules voorgecodeerd voor Solarflare als je bij het bestellen het doel opgeeft, wat meestal makkelijker is dan jagen op origineel gecodeerde voorraad.
Voordat je iets uitgeeft: denk na over hoe lang deze kaart nog te leven heeft. Solarflare is overgegaan naar Xilinx en het driverwerk is gestopt, dus er komt niets meer voor bij. Voor een doos die je wilt kunnen vergeten, zou ik op dit platform Chelsio als eerste keus zetten en Intel als tweede. Voor wat het waard is: één langlopend verslag hier ging over twee jaar probleemloze dienst van de nauw verwante SFN6122F, die als toleranter werd beoordeeld voor willekeurige transceivers dan de Intel X520 ernaast - maar dat is de oudere kaart en het verandert niets aan het coderingsgedrag van de jouwe.
Een setje SFM10G-SR besteld, gecodeerd voor de kaart, en beide poorten kwamen op bij de eerste keer insteken, dus de coderingstheorie klopt. Wel maar een gedeeltelijk resultaat van mijn kant: de oude multimode-modules blijven volledig dood in deze NIC en werken alleen in de andere kaart, dus ik houd nu twee sets optiek gelabeld en gescheiden.
De kaart blijft voorlopig staan want hij doet zijn werk, maar de Chelsio-hint is genoteerd voor de volgende keer - ik koop liever niet elke keer dat ik een poort toevoeg speciaal gecodeerde optiek.
De moeite waard om één controle aan de algemene procedure toe te voegen, want "niet-ondersteunde optiek" betekent al naargelang de doos heel verschillende dingen. Op een Instant On 1930 24G was het eigen antwoord van de vendor dat een niet-ondersteunde module (SX, LH en dergelijke) alleen gemarkeerd wordt - knipperend poort-ledje plus een syslog-melding - en de poort helemaal niet uitgeschakeld wordt, dus een link die daar down blijft wijst naar het fysieke pad, niet naar een lock. Dat geval eindigde met een nieuwe fiberloop plus een 10G single-mode LR SFP+ van een derde partij, en de link kwam op.
Dezelfde valkuil loopt in de andere richting bij HBA's: een Brocade 825 verschijnt twee keer in lspci, en het insteken van optiek levert niets op in dmesg, wat mensen lezen als een storing. Drivers loggen link-status, geen module-insertie, dus stilte daar is ook geen diagnose.
In jouw geval heb je al de ene test gedaan die het beslecht: dezelfde module en dezelfde kabel linken in een andere NIC, dus een coderingslock is de juiste conclusie. Laat je alleen door niemand die conclusie aanpraten op een doos waar het maar om een ledje en een logregel gaat.