Dell M14MK SFP28がOpenWrtでno common interface modesとして拒否される、QSFPTEK製SFP+は普通にリンクする
小さなホームラボです。純正のWeb UIから離れたくて、Linksys LGS328CをOpenWrt SNAPSHOTに書き換えました。移行してもほとんどのものは無事でしたが、それまで完璧に動いていたSFP28ポートが1つだけ動かなくなりました。
- スイッチ: Linksys LGS328C(Realtek rtl930x)、OpenWrt SNAPSHOT
- モジュール: Dell S28-10G-25G-SR-85C、10G/25Gデュアルレート、EEPROMの表示はDELL M14MK rev A1
- 同じケージでの比較用モジュール: QSFPTEK QT-SFP+-SR
- 両テストとも同じファイバー、同じ対向
Dellのモジュールは検出はされますが、そのまま弾かれます。
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すでに確認したこと:
- 同じケージにQSFPTEK製SFP+を挿し替えると、ログはinband/10gbase-rを選んだことを示し、きれいに10Gbpsでリンクする
- 同じDellモジュールは純正ファームウェアではこのスイッチで問題なく動いていたので、オプティクス自体は死んでいない
- 挿し直して清掃してみたが、ログに変化なし
このモジュールは実際に不正なプログラムがされているのでしょうか、それともスイッチドライバが25G対応パーツにうるさいだけなのでしょうか。オプティクスを買い足すよりも、これをちゃんと理解したいです。
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
そのダンプで全部説明がつきます。カーネルのsfpレイヤーがモジュールの対応インターフェースモードを判断するときの入力はただひとつ、あのコンプライアンスバイトです。それが1つもセットされていないと空集合になり、それをMAC側が提供するものと突き合わせても共通点がなく、まさにあなたが見ているメッセージが出ます。ethtoolの10000baseCR/Fullはポート側に残っていた値であって、モジュール側が要求したものではありません。純正ベンダーファームウェアが気にしないのは、そういったイメージが通常コンプライアンスバイトを丸ごと無視して、ベンダー文字列とパーツ文字列をハードコードされたリストと照合しているからです。書き換える前にオプティクスが動いていたのはそのためです。
実際に効く直し方はモジュールクワークです。drivers/net/phy/sfp.cに、ベンダーDELL、パーツM14MKにマッチするSFP_QUIRK_Sエントリを追加して、ETHTOOL_LINK_MODE_10000baseSR_FullとPHY_INTERFACE_MODE_10GBASERを強制的にセットし、イメージを再構築します。そうするとポートは10000baseSR/Fullを報告する普通の10Gリンクとして上がり、unsupported-moduleの行はログから消えます。
注意点は2つです。このパッチは手元に溜め込まず、netdevに送れる形にしておいてください。EEPROMが自然に直ることはなく、同じDell製品を持っている人は他にもいます。それと、カーネルビルドを維持したくないなら、地味な代替策として手元にあるQSFPTEK製SFP+を使う手があります。どのみちこのポートが出せるのは10Gまでですから。
スイッチのドライバを責める前に、EEPROMをダンプしてモジュールが何を宣言しているか見てください。
ethtool --module-info lan28です。hex dumpの最初の数行と、ethtool lan28の全体を貼ってください。「no common interface modes」というのは、カーネルがモジュールから使えるモードを1つも導き出せなかったという意味なので、ここではそのバイトの中身がすべてです。もうひとつ確認したいのですが、QSFPTEKは本当に同じケージに挿していますか、隣のケージではなく。あなたのログの行はp49と言っていますが、ethtoolの出力はlan28です。この手のテストでポートを取り違えるとかなり時間を無駄にします。
ダンプしました。短く言うと、10Gコンプライアンスコードは一切セットされていません。あのバイトは単に空で、ベンダーとパーツの文字列はDELL M14MK rev A1として期待どおりに入っています。
ethtool lan28は相変わらずAdvertised link modes: 10000baseCR/FullとLink detected: noを示し、dmesg | grep lan25は最初の投稿の2行以上のものは何も出てきません。つまりこのモジュールは自分が実際何をできるかをホストにほとんど伝えていないということで、同じケージのQSFPTEKは相変わらず10Gbpsでリンクしています。
書き留めておく価値があります。まさに同じ組み合わせについての以前のバグレポートは違う推測をしていました。そちらの説では、デュアルレートモジュールが25gbase-rをアドバタイズし、rtl930xドライバがそのモードを実装していないため交差が空になり、モジュール自体には何も問題がないというものでした。hex dumpはその説明を否定します。モジュールは何もアドバタイズしておらず、25Gですらありません。同じカーネルメッセージでも原因は別で、dumpを見て初めてその2つを区別できます。
これはまた、ベンダーブランドのオプティクスが自動的に正しくコーディングされているわけではないという教訓でもあります。Dell自身のOS10でも、純正のQ28-128GFC-SW4(パーツKP0VM)をQSFP28 100GBASE-SR4、Qualified falseと表示することがあります。一部のロットには、その媒体資格を認識できないEEPROMコーディングが入っていて、手動でunsupported transceiverを許可するまでFCリンクはdownのままになるからです。
DELL / M14MK用のSFP_QUIRK_Sエントリを入れたイメージをビルドしたら、あなたが説明したとおりになりました。ポートは10Gbpsでリンクし、
ethtool lan28は今10000baseSR/Fullとlink upを報告していて、ログはきれいでunsupported-moduleの行はどこにもありません。ボックスの他の部分に触る前に、数日間実トラフィックを流したままにしましたが、フラップは一度もありません。自分のツリーに抱え込んでいても誰の役にも立たないので、今netdevに送るためにパッチを整理しています。先にmodule-infoのダンプを取るよう背中を押してくれてありがとうございます。2晩もドライバのモードテーブルを読んでいました。