Intel X520のEEPROMをパッチして(IXGBE_DEVICE_CAPS_ALLOW_ANY_SFPビット)すべてのSFP+トランシーバを解禁する
スレッド起稿者は、82599ベースのX520カードに文書化されていないEEPROMビット(IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP、バイトオフセット0x58にあるケイパビリティワードの最下位ビット、通常0xFCがロック/0xFDがアンロック)があり、これがLinuxのドライバオプションが使えないESXiやWindowsでIntel以外のアクティブSFP+モジュールを受け入れるかどうかを決めていることを記録した。手順としては、デバイスIDを調べるlspci -nn、読み取り用のethtool -e enp1s0 offset 0x58 length 1、書き込み用のethtool -E enp1s0 magic 0x10fb8086 offset 0x58 value 0xfdが示され、そのビットだけを反転させるよう警告もついていた。追随した人たちはX520-DA2、ESXiとFinisarモジュールで使っているeBay調達のカード、Dellブランドのx520/i350 rNDC(0xFC)、HPE NC560SFP+(すでに0xFDでMikroTik S+RJ10と動作)、そしてUbiquiti製10GbE RJ45モジュールを依然として拒否する82599について結果を報告した。
- ハードウェア: Intel X520-DA1、Intel X520-DA2、Dell Intel 2P X520/2P i350 rNDC、HPE NC560SFP+、Intel 82599ES
- トランシーバ: Finisar SFP+、MikroTik S+RJ10、Ubiquiti UF-RJ45-10G
- フォームファクタ: SFP+
症状 / メッセージ:
non-Intel active SFP+ rejected on ESXi/Windows
EEPROM byte 0x58 = 0xFC
Comments 2
バイト0x58を読み、ethtool -EとPCIデバイス・ベンダーIDから作ったmagicを使って最下位ビットだけをセットします(例: 0xFCから0xFDへ)。その後はどのOSでもサードパーティ製アクティブオプティクスを受け付けるようになります。パッシブDACや普通のSFPモジュールは、ロックされたままでもたいてい動きます。
HPE、Dell、CiscoのOEMカードはアンロック済みで出荷されることがあり、このロックがIntelのポリシー設定であることをうかがわせます。アンロック後もモジュールが動作しない場合は、Linuxでallow_unsupported_sfpを使ってテストし、本当の非互換なのかロックのせいなのかを切り分けてください。