Dell M14MK SFP28, OpenWrt पर no common interface modes के साथ refuse हो रहा जबकि एक QSFPTEK SFP+ link कर जाता है
छोटी home lab है. Stock web interface से बचने के लिए मैंने एक Linksys LGS328C को OpenWrt SNAPSHOT पर flash कर दिया. Move में सब कुछ बच गया सिवाय एक SFP28 port के जो पहले बिल्कुल ठीक काम करता था.
- switch: Linksys LGS328C (Realtek rtl930x), OpenWrt SNAPSHOT
- module: Dell S28-10G-25G-SR-85C, dual-rate 10G/25G, EEPROM DELL M14MK rev A1 पढ़ता है
- उसी cage में reference module: QSFPTEK QT-SFP+-SR
- दोनों tests में एक ही fibre और एक ही far end
Dell module detect होता है और फिर सीधे बाहर फेंक दिया जाता है:
sfp sfp-p49: module DELL M14MK rev A1
rtl83xx-switch ...: unsupported SFP module: no common interface modes
# ethtool lan28
Advertised link modes: 10000baseCR/Full
Link detected: noजो पहले ही check कर चुका हूं:
- उसी cage में QSFPTEK SFP+ लगाकर देखा: log में port inband/10gbase-r चुनता दिखता है, और साफ 10 Gbps link मिल जाता है;
- यही Dell module stock firmware में इसी switch पर ठीक चला, तो optic मरा हुआ नहीं है;
- reseat किया और connector साफ किया, log में कोई फर्क नहीं.
क्या module असल में गलत programmed है, या switch driver किसी 25G-capable part को लेकर नखरे कर रहा है? मैं सिर्फ दूसरा optic खरीदने की बजाय इसे समझना चाहूंगा.
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 5
वो dump पूरी बात explain कर देता है. Kernel की sfp layer के पास ये तय करने के लिए ठीक एक ही input होता है कि कोई module कौन से interface modes चला सकता है, और वो हैं वही compliance bytes. उनमें से कुछ भी set न होने पर एक empty set बनता है, उसे MAC जो offer करता है उससे intersect किया जाता है, कुछ common नहीं मिलता, और ठीक वही message print होता है जो आप देख रहे हैं. ethtool में 10000baseCR/Full port side से बचा हुआ है, module ने वो मांगा नहीं था. Stock vendor firmware को इससे फर्क नहीं पड़ता, क्योंकि वो images आमतौर पर compliance bytes को पूरी तरह skip कर देती हैं और इसकी बजाय vendor और part strings को एक hardcoded list से match करती हैं - यही वजह है कि flash करने से पहले optic काम कर रहा था.
जो fix असल में टिकता है वो एक module quirk है. drivers/net/phy/sfp.c में एक SFP_QUIRK_S entry जोड़ें जो vendor DELL को part M14MK से match करे और ETHTOOL_LINK_MODE_10000baseSR_Full और PHY_INTERFACE_MODE_10GBASER को force-set करे, फिर image rebuild करें. Port एक साधारण 10G link के तौर पर आता है, 10000baseSR/Full report करता है और unsupported-module वाली line log से गायब हो जाती है.
दो बातें ध्यान रखें. Patch को ऐसी shape में रखें कि netdev को भेज सकें, उसे downstream पर बैठाए रखने की बजाय: EEPROM अपने आप ठीक नहीं होने वाला और वही Dell part बाकी लोगों के पास भी है. और अगर आप बिल्कुल भी kernel build maintain नहीं रखना चाहते, तो boring alternative वही QSFPTEK SFP+ है जो आपके पास पहले से है - इस port से 10G ही मिलना है, बस इतना ही.
Switch driver को दोष देने से पहले, EEPROM dump करें और देखें module क्या declare करता है:
ethtool --module-info lan28. Hex dump की पहली rows plus पूराethtool lan28post करें. "no common interface modes" का मतलब है kernel module से एक भी usable mode निकाल नहीं पाया, तो इन bytes का content ही यहां पूरी कहानी है.एक और चीज़ confirm करनी है: क्या QSFPTEK उसी cage में बैठा है, किसी पड़ोसी cage में नहीं? आपकी log line p49 कहती है जबकि ethtool output lan28 है, और इस तरह के test में ports मिक्स हो जाना काफी वक्त बर्बाद करता है.
Dump कर लिया. Short version: कोई 10G compliance code set है ही नहीं - वो bytes बस खाली हैं, जबकि vendor और part strings बिल्कुल वैसे ही populated हैं जैसी एक DELL M14MK rev A1 से उम्मीद होगी.
ethtool lan28अब भीAdvertised link modes: 10000baseCR/FullऔरLink detected: noदिखाता है, औरdmesg | grep lan25मेरी पहली post की दो lines के अलावा कुछ नहीं देता.तो module host को लगभग कुछ नहीं बताता कि वो असल में क्या कर सकता है, और उसी cage में QSFPTEK अब भी 10 Gbps पर link है.
लिखकर रखने लायक बात है, क्योंकि इसी exact pairing पर पहले आई bug report ने अलग अंदाज़ा लगाया था. वहां theory ये थी कि dual-rate module 25gbase-r advertise करता है, rtl930x driver वो mode implement नहीं करता, intersection खाली निकलता है और module में खुद कुछ गलत नहीं है. Hex dump उस explanation को खारिज कर देता है: module कुछ भी advertise नहीं करता, 25G भी नहीं. वही kernel message, अलग वजह, और सिर्फ dump ही दोनों में फर्क बताता है.
ये एक याद दिलाने वाली बात भी है कि vendor-branded optic अपने आप सही coded नहीं होता. Dell का अपना OS10 एक genuine Q28-128GFC-SW4 (part KP0VM) को QSFP28 100GBASE-SR4 के तौर पर Qualified false के साथ दिखाएगा, क्योंकि कुछ batches में ऐसी EEPROM coding होती है जिसे उसका media qualification पहचानता नहीं, और FC link तब तक down रहता है जब तक आप हाथ से unsupported transceivers allow नहीं करते.
DELL / M14MK के लिए SFP_QUIRK_S entry के साथ एक image बनाई और वो बिल्कुल वैसा ही करती है जैसा आपने बताया था. Port 10 Gbps पर link होता है,
ethtool lan28अब 10000baseSR/Full के साथ link up report करता है, और log साफ है - कहीं कोई unsupported-module line नहीं. Box पर कुछ और छेड़ने से पहले कुछ दिन असली traffic के साथ चलने दिया, कोई flap नहीं.अब patch को साफ कर रहा हूं ताकि netdev को भेज सकूं, क्योंकि इसे अपने ही tree में रखे रहने से किसी का भला नहीं होता. मुझे पहले module-info dump की तरफ धकेलने के लिए शुक्रिया, मैं दो शामों से driver mode tables पढ़ रहा था.