改写Intel X520的EEPROM(IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP位)以解锁所有SFP+光模块
楼主记录了一个发现:基于82599的X520网卡带有一个没有文档记载的EEPROM位(IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP,位于字节偏移0x58处能力字的最低位,通常锁定状态是0xFC、解锁状态是0xFD),这个位决定了在ESXi和Windows上是否接受非Intel的有源SFP+模块——这两个系统上都没有Linux那种驱动选项可用。文章给出了用lspci -nn查设备ID的方法、用ethtool -e enp1s0 offset 0x58 length 1读取,以及用ethtool -E enp1s0 magic 0x10fb8086 offset 0x58 value 0xfd写入,并提醒只翻转那一个位。跟帖者在X520-DA2上报告了结果,包括在eBay买的卡配ESXi和Finisar模块、Dell品牌的X520/i350 rNDC(0xFC)、HPE NC560SFP+(本来就是0xFD,配MikroTik S+RJ10能用),还有一块82599依然拒绝一个Ubiquiti 10GbE RJ45模块。
- 硬件: 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和厂商ID组成的magic值,只翻转最低位(比如把0xFC改成0xFD);之后这块卡在任何操作系统下都会接受第三方有源光模块。无源DAC和普通SFP模块通常即使在锁定状态下也能用。
HPE、Dell或Cisco的OEM卡出厂时可能就是解锁状态,说明这个锁本质上是Intel的一项策略设置;如果解锁之后某个模块依然不行,在Linux下用allow_unsupported_sfp测试一下,以区分是真正的不兼容,还是这个锁本身的问题。