R630のIntel X520が、allow_unsupported_sfp=1でもcomp_codes_10g=0x00の10GBASE-T銅線SFP+を拒否する
R630を2台まとめて10G化していますが、ラック最上段までの配線が銅線なので、ファイバーを引く代わりにX520カードへ10GBASE-T SFP+モジュールを挿しました。スイッチ側は何も言わずに受け入れます。サーバー側は拒否します。
- Dell PowerEdge R630、Intel X520 (82599)、デュアルポート
- FS SFP-10GM-T-30、Dellコード、サーバー1台につき1モジュール
- IntelのDKMS経由でビルドしたout-of-tree版ixgbe
- 両ポート分のオーバーライドを設定した/etc/modprobe.d/ixgbe.conf
# cat /etc/modprobe.d/ixgbe.conf
options ixgbe allow_unsupported_sfp=1,1
# dmesg
ixgbe: failed to load because an unsupported SFP+ module type was detected
# 10G compliance codes read back from the module
comp_codes_10g=0x00既に試したこと:
- modprobe.dのエントリに加えて、
modprobe ixgbe allow_unsupported_sfp=1を手動でも実行 - initramfsを再構築し、モジュールの再読み込みだけでなくマシンをコールドブート
- モジュールを2番目のポート、さらに2台目のサーバーへ移動、結果は同じ
興味深いのはあのcomplianceバイトです。モジュールは10Gについて何も報告していません。ドライバはoverrideを見る前にそこをテストしているのでしょうか。正しいコーディングの光モジュールを買う以外に、できることはあるでしょうか。
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 6
戦っている相手はホワイトリストではなく、チェックの順番です。
SFF-8472には10GBASE-T用のcomplianceビットがありません。単純にコードポイントが存在しないので、正直な銅線SFP+はオール0の10G complianceコードを報告します。これがまさにあなたの
comp_codes_10g=0x00です。ixgbeはそのバイトを読み、10Gモジュールとして認識できるものが何もないとわかった時点で、allow_unsupported_sfpのoverrideに近づくよりずっと前にそこで諦めます。だからこのフラグは、非適格な光モジュールやDACには効くのに、あなたの銅線モジュールには全く何もしないのです。Intelのout-of-tree版ixgbeに対する、complianceのテストの位置を動かすコミュニティパッチがあります。管理者が明示的に
allow_unsupported_sfp=1を設定している場合、オール0の10G complianceコードを報告するモジュールは、早期に弾かれる代わりにSRとして分類されるようになります。これはupstreamに提出されましたが、まだマージされていないので、DKMSのソースに自分の手で当てて、ビルドのたびに保持する必要があります。書いた本人はその後サーバー2台で10 Gb/s全二重を報告していますし、別の人も同じパッチでHLX-SFPXの銅線モジュールがX520で動くことを確認しています。やる前に注意点が二つあります。Intelが適格性を認めていない光モジュールは彼らの互換性保証の対象外なので、これは彼らの問題ではなくあなたの問題になります。そして10GBASE-TのPHYは発熱の大きい部品です。自前の通風のないサーバーケージの中では、隣のスロットの光モジュールよりもかなり高温になるので、リンクが上がったらモジュールの温度も見ておいてください。
何かパッチを当てる前に、はっきりさせておきたいことが二つあります。
まず、モジュールの再読み込みではなくコールドブートを経たマシンで、カーネルが実際に見ているパラメータそのものを
/sys/module/ixgbe/parameters/allow_unsupported_sfpで出力してください。それがconfファイルに書いてある内容と一字一句一致していなければ、あなたの設定が効く前に何かがドライバを読み込んでいることになり、残りのデバッグは無駄になります。次に、どのixgbeが読み込まれていますか。ドライバの読み込みが終わらずインターフェースが存在しない間は
ethtool -iは役に立たないので、modinfo ixgbeが返す内容と、ビルドしたDKMSパッケージのバージョンを貼ってください。そして、その
comp_codes_10g=0x00はどこから来たものですか。ドライバがそう言っているのか、それとも自分でモジュールのEEPROMをダンプしたのか。ファイル内のパラメータは
1,1で、コールドブート後に/sys/module/ixgbe/parameters/allow_unsupported_sfpを読み返しても1,1が返るので、黙って無視されているわけではなく適用されています。initramfsはブート前に再構築済みです。dmesgのその行はどちらにしても同じです。complianceコードはドライバからではなく、SFF-8472のデータから自分でモジュールを読み出して確認しました。10Gのcomplianceバイトはゼロで、ID項目の他の部分は正常に見えます。同じモジュールをスイッチ側のポートに挿すと10Gでリンクするので、死んだモジュールではありません。
実務面でもう一つ付け加えると、DKMSはカーネル更新のたびにディスク上のソースから再ビルドするので、パッチは後で消してしまうビルドディレクトリではなく、そのソースツリーの中に置いておく必要があります。再起動のタイミングで発覚するのではなく、最初のカーネル更新の後にポートが戻ってくることを確認してください。
この種の問題からのより広い教訓は、モジュールのコーディングよりもドライバのビンテージの方が物を言うということです。パッシブDACを挿したX710でも同じ話がありました。同じ1本のケーブル、同じ1つのポートが、Ubuntu 24.04では問題なく、TrueNAS SCALEでは
Link detected: noとSpeed: Unknownで死んでいました。そのビルドが6.6.44-productionカーネル由来のi40eを積んでいたからです。i40eが6.12.9-production由来の25.04-BETA.1では、他は何も触らずカードのファームウェアも9.20のままで、ツイナックスは自分から上がってきました。どちらのシステムでもそのポートの光モジュールは問題なかったので、これで不具合が旧いドライバのパッシブ銅線の扱いにあると特定できました。比較の両側でethtool -iを取っていれば、ケーブルの差し替えにあれほど時間を使わずに済んだはずです。モジュールの種類は違いますが、ドライバは同じで、ついでに潰しておく価値のある罠です。X520ドーターカードを積んだDell R720で、Cisco 10GマルチモードLCモジュールが拒否され、インターフェースがそもそも存在しませんでした。オプションはmodprobe.dにもGRUBにも入っていましたが、何も変わりませんでした。ホストがEFIブートだったので、そのGRUBのコマンドラインは一度も使われていなかったのです。
EFIブートのProxmoxでは、パラメータは
/etc/kernel/cmdlineにixgbe.allow_unsupported_sfp=1として置き、続けてpve-efiboot-tool refreshを実行します。このケースではそれでも直らず、結局Intelブランドのモジュールを買うことになったので、これは直すものというより消去法の一項目として扱ってください。そのごたごたからのもう一つの教訓は、光モジュールについては両端それぞれが独立に納得している必要があるということです。スイッチが受け入れるモジュールでも、ホスト側に拒否されることはあり、あなたは既にそこにいます。
DKMSのソースにパッチを当てて再ビルドしました。両ポートとも10 Gb/s全二重で上がり、それ以降は負荷をかけても落ちていません。
動いてはいますが、解決したとは言えません。これはマージされていないパッチで、カーネル更新のたびに今も持ち運んでいますし、ドライバはポートをSRとして見せるので、自分の後にこの箱を見る誰かを混乱させるはずです。モジュールも隣のケージの光モジュールよりはっきり熱くなり、そのスロットにはまともな通風がありません。次のサーバーの調達では、ファイバーを引いてドライバと言い争うのをやめるつもりです。