TrueNAS altında Solarflare SFN7122F: kart algılanıyor, ama çalışan çok modlu SFP+ modülleri karanlık kalıyor
Evde bir depolama kutusu kuruyorum ve ucuz olduğu için dual 10GbE bir Solarflare SFN7122F (SFC9120) aldım. Kartın kendisi sağlıklı görünüyor, sistem onu görüyor ve iki port da enumerate oluyor, ama mevcut çok modlu SFP+ modüllerimden hiçbiri içinde bir link kaldırmıyor.
- Solarflare SFN7122F, dual port, SFC9120 controller
- NAS'ta TrueNAS SCALE, orijinal plan CORE'du
- başka bir NIC'te şikayetsizce link kuran 10G çok modlu SFP+ modülleri
- çalışan testte kullanılanla aynı, kısa çok modlu patch kordon
eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP>
eth3: <NO-CARRIER,BROADCAST,MULTICAST,UP>Denediklerim:
- her iki port, her iki modül, dört kombinasyonun tamamı, hiçbiri hiçbir zaman link kurmuyor
- tam olarak aynı modülleri ve aynı patch kordonu diğer karta taşıdım, link anında geliyor
- kirli bir uç yüzeyi ihtimaline karşı patch kordonları değiştirdim
Yani fiber ve modüller sorun değil. Bu kart kendisi için kodlanmamış optikleri mi reddediyor, yoksa driver tarafında bir şey mi bozuk, ve burada CORE, SCALE'den farklı mı davranırdı? Eğer kodlamaysa, insanlar bir SFN7122F'de gerçekte hangi modülleri çalıştırıyor?
Comments 3
Driver tarafı sizin sorununuz değil. FreeBSD sfxge driver'ı Solarflare SFC9000 ailesi 10GbE adaptörlerini kapsıyor, yani bir SFC9120, CORE'da sorunsuz, ve zaten SCALE'in donanımı enumerate ettiğini görüyorsunuz. Sizin çarptığınız şey kartın kendi transceiver kontrolü: Solarflare için kodlanmış modülleri kabul ediyor ve geri kalanını sessizce görmezden geliyor, bu da tam olarak elinizdekine benziyor: portları hiç gelmeyen sağlıklı bir kart.
İnsanların bunlarda gerçekten çalıştırdığı parçalar: FTLX8571D3BCL-SL ve SFM10G-SR. Sipariş verirken hedefi belirtirseniz FS de Solarflare için önceden kodlanmış modüller tedarik ediyor, bu da genelde orijinal kodlu stok aramaktan daha kolay.
Bir şey harcamadan önce, bu kartın ne kadar ömrü olduğunu düşünün. Solarflare, Xilinx'e geçti ve driver çalışması durdu, yani onun için başka bir şey gelmiyor. Unutmak istediğiniz bir kutu için, bu platformda önce Chelsio'yu sonra Intel'i koyardım. Değeri kadarıyla, buradaki uzun soluklu bir rapor, yakından ilişkili SFN6122F'den iki yıl sorunsuz hizmet hakkındaydı, yanındaki Intel X520'den rastgele transceiver'lara daha toleranslı olarak değerlendirilmişti - ama o daha eski kart, ve sizinkindeki kodlama davranışını değiştirmiyor.
Kart için kodlanmış bir çift SFM10G-SR sipariş ettim ve iki port da ilk takışta geldi, yani kodlama teorisi tutuyor. Ama benim tarafımdan sadece kısmi bir sonuç: eski çok modlu modüller bu NIC'te hâlâ tamamen ölü ve sadece diğer kartta çalışıyor, yani şimdi iki optik setini etiketli ve ayrı tutuyorum.
Kart işini yaptığı için şimdilik kalıyor, ama Chelsio ipucu bir sonraki için not edildi - her port eklediğimde özel kodlanmış optik satın almak istemem.
Genel prosedüre bir kontrol daha eklemeye değer, çünkü "unsupported optics" kutuya bağlı olarak çok farklı şeyler ifade ediyor. Bir Instant On 1930 24G'de vendor'ın kendi cevabı, desteklenmeyen bir modülün (SX, LH ve benzerleri) sadece işaretlendiğiydi - yanıp sönen port LED'i artı bir syslog mesajı - ve port hiç devre dışı bırakılmıyor, yani orada down kalan bir link fiziksel yolu işaret ediyor, bir kilidi değil. O vaka, yeni bir fiber hattı artı üçüncü parti bir 10G tek modlu LR SFP+ ile sonuçlandı ve link geldi.
Aynı tuzak HBA'larla ters yönde de işliyor: bir Brocade 825, lspci'de iki kez görünüyor, ve optik takmak dmesg'de hiçbir şey üretmiyor, insanlar bunu bir arıza olarak okuyor. Driver'lar link durumunu loglar, modül takılmasını değil, yani oradaki sessizlik de bir teşhis değil.
Sizin durumunuzda, işi çözen tek testi zaten yaptınız: aynı modül ve aynı kordon başka bir NIC'te link kuruyor, yani bir kodlama kilidi doğru sonuç. Sadece sizi bu sonuca sadece bir LED ve bir log satırının olduğu bir kutuda ikna etmelerine izin vermeyin.