TrueNAS के नीचे Solarflare SFN7122F: card detect होता है, पर काम करते multimode SFP+ modules dark रहते हैं
घर पर एक storage box बना रहा हूं और सस्ता होने की वजह से एक dual 10GbE Solarflare SFN7122F (SFC9120) ले लिया. Card खुद healthy लगता है, system उसे देखता है और दोनों ports enumerate होते हैं, पर मेरे मौजूदा multimode SFP+ modules में से एक भी इसमें link नहीं ला पा रहा.
- Solarflare SFN7122F, dual port, SFC9120 controller
- NAS पर TrueNAS SCALE, शुरुआती plan CORE का था
- 10G multimode SFP+ modules जो किसी और NIC में बिना शिकायत link हो जाते हैं
- छोटा multimode patch cord, वही जो काम करते हुए test में use हुआ
eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP>
eth3: <NO-CARRIER,BROADCAST,MULTICAST,UP>मैंने जो try किया:
- दोनों ports, दोनों modules, चारों combinations, कभी कुछ link नहीं होता
- बिल्कुल वही modules और वही patch cord दूसरे card पर move किए, link तुरंत आ जाता है
- dirty end face के शक में patch cords बदले
तो fibre और modules problem नहीं हैं. क्या ये card ऐसे optics को मना कर रहा है जो इसके लिए coded नहीं, या driver तरफ कुछ गड़बड़ है, और क्या यहां CORE, SCALE से अलग व्यवहार करेगा? अगर ये coding है, तो लोगों के पास असल में SFN7122F में कौन से modules चल रहे हैं?
Comments 3
Driver तरफ आपकी problem नहीं है. FreeBSD का sfxge driver Solarflare SFC9000-family 10GbE adapters को cover करता है, तो CORE पर एक SFC9120 ठीक चलेगा, और आप पहले ही देख चुके हैं कि SCALE hardware enumerate कर लेता है. आप जिससे टकरा रहे हैं वो card का अपना transceiver check है: वो Solarflare के लिए coded modules accept करता है और बाकी को चुपचाप नज़रअंदाज़ कर देता है, जो बिल्कुल वैसा ही दिखता है जैसा आपके पास है - एक healthy card जिसके ports कभी नहीं आते.
जो parts लोगों के पास असल में इनमें चल रहे हैं: FTLX8571D3BCL-SL और SFM10G-SR. Order करते वक्त target बता दें तो FS भी Solarflare के लिए pre-coded modules दे देगा, जो आमतौर पर original-coded stock ढूंढने से आसान पड़ता है.
कुछ भी खर्च करने से पहले, सोचें कि इस card को अभी कितना और चलना है. Solarflare Xilinx के पास चला गया और driver का काम रुक चुका है, तो इसके लिए आगे कुछ नहीं आने वाला. जिस box को आप भूल जाना चाहते हैं उसके लिए, मैं इस platform पर पहले Chelsio और दूसरे नंबर पर Intel रखूंगा. जो भी हो, यहां एक लंबे समय से चली आ रही report थी करीबी SFN6122F से दो साल की बिना किसी झंझट वाली service के बारे में, जिसे बगल में बैठे Intel X520 से random transceivers को लेकर ज़्यादा tolerant बताया गया - पर वो पुराना card है और इससे आपके card का coding व्यवहार नहीं बदलता.
Card के लिए coded SFM10G-SR की एक जोड़ी order की और पहली बार लगाते ही दोनों ports आ गए, तो coding theory सही बैठती है. मेरी तरफ से बस आधा नतीजा है: पुराने multimode modules इस NIC में अब भी पूरी तरह मरे पड़े हैं और सिर्फ दूसरे card में काम करते हैं, तो अब मैं optics के दो सेट अलग-अलग label करके रखता हूं.
Card फिलहाल टिका है क्योंकि अपना काम कर रहा है, पर अगली बार के लिए Chelsio वाला hint नोट कर लिया - हर बार port जोड़ने पर खासतौर पर coded optics खरीदना मुझे पसंद नहीं.
General procedure में एक check जोड़ने लायक है, क्योंकि "unsupported optics" का मतलब box के हिसाब से बहुत अलग-अलग होता है. एक Instant On 1930 24G पर vendor का अपना जवाब था कि unsupported module (SX, LH वगैरह) सिर्फ flag होता है - flashing port LED plus एक syslog message - और port बिल्कुल भी disabled नहीं होता, तो वहां जो link down रहता है वो physical path की तरफ इशारा करता है, किसी lock की तरफ नहीं. वो case एक नई fibre run plus एक third-party 10G single-mode LR SFP+ पर खत्म हुआ और link आ गया.
वही trap दूसरी दिशा में HBAs के साथ भी चलता है: एक Brocade 825 lspci में दो बार दिखता है, और optics लगाने पर dmesg में कुछ नहीं आता, जिसे लोग fault समझ लेते हैं. Drivers link state log करते हैं, module insertion नहीं, तो वहां की चुप्पी भी कोई diagnosis नहीं है.
आपके case में आप वो एक test पहले ही चला चुके हैं जो फैसला कर देता है, वही module और वही cord किसी और NIC में link हो जाना, तो coding lock ही सही नतीजा है. बस किसी को आपको उस नतीजे पर ऐसे box के लिए राज़ी मत करने दें जहां बात सिर्फ एक LED और एक log line की हो.