记一次 Intel X710-DA2 光口“LED灯不亮”的排障全过程:从疑似硬件故障到 NVM 解锁

背景

在给 Proxmox VE 主机(以下简称 PVE)配置一张 Intel X710-DA2(双口 10GbE SFP+)网卡时,插上光模块后两个口的指示灯都不亮,ethtool 显示 Link detected: no。这篇文章记录完整的排障路径,包括踩过的坑,方便以后自己回顾,也希望能帮到遇到同样问题的人。

环境:

• 主机:Proxmox VE 8,内核 7.0.14-8-pve / 7.0.14-11-pve
• 网卡:Intel X710-DA2(Ethernet Controller X710 for 10GbE SFP+,PCI ID 8086:1572,Subsystem X710-2)
• 光模块:某杂牌(标注 ATOP)万兆 SFP+ 模块,Vendor OUI: 00:00:00

先记住一个容易混淆的点:X710 只是芯片/产品家族名称,实际行为还取决于板卡 OEM、Subsystem ID、NVM 版本和端口类型。下面的结论针对这张 X710-DA2 和这组模块验证过,不应直接推断为所有 X710 都能通过同样方式解锁。

第一步:确认是不是硬件坏了

先用 ethtool 查看端口和光模块状态:

ethtool enp1s0f0np0
ethtool -m enp1s0f0np0

结果显示:

• Link detected: no,速率/双工全部 Unknown
• 接收端(RX)正常:Receiver signal average optical power: -1.53 dBm,说明对端信号能正常传过来
• 发射端(TX)完全没有输出:Laser bias current: 0.000 mA,Laser output power: -40.00 dBm(等于关闭),伴随一堆 low alarm / low warning

在继续拆机或更换硬件前,建议把以下信息保存到工单中。ethtool -m 在模块被拒绝时可能读取失败,这是正常现象,不要把“读不到 EEPROM”误判成模块一定损坏:

ethtool -i enp1s0f0np0                 # 驱动、固件、bus-info
ethtool -m enp1s0f0np0 > /tmp/sfp.txt  # 模块 EEPROM（能读到时）
lspci -nnk -s 01:00.0                 # PCI ID、当前驱动
udevadm info /sys/class/net/enp1s0f0np0 | grep -E 'ID_NET_NAME|PHYS_PORT'

同时确认模块和对端交换机的物理参数：10GBASE-SR/LR、波长、单模/多模、LC/双工或 DAC/AOC 类型必须匹配；交换机侧若强制了速率、FEC 或自动协商，也要记录下来。光功率读数只能说明模块的 DOM 报告状态，不能单独证明链路协议已经协商成功。

RX 正常、TX 为零,第一反应是怀疑模块的激光器坏了,或者是网卡这个口的驱动电路故障。

第二步:排除驱动/接口层面的问题

依次确认:

• ip link set enp1s0f0np0 up:接口本身能正常启用,UP 状态正常
• dmesg | grep -i i40e:没有任何驱动层面的报错
• lspci -vvv | grep LnkSta:PCIe 链路速率/带宽跟 LnkCap 完全一致(8GT/s x8),排除插槽接触不良或供电异常

第三步:两个口都不亮,怀疑范围扩大

进一步观察发现,网卡的两个口指示灯都不亮,并且两个口插的两颗模块表现出几乎一模一样的异常数据(RX 正常、TX 精确为零)。两颗不同的物理激光二极管同时以完全相同的方式失效,这个概率极低,这个线索把怀疑方向从“单颗模块硬件坏了”转向了“驱动或固件在统一拦截”。

翻查完整的开机日志(用 journalctl -b 0 而不是容易被冲掉的 dmesg 缓冲区),终于找到关键信息:

i40e 0000:01:00.1: Rx/Tx is disabled on this device because an unsupported SFP module type was detected.
i40e 0000:01:00.0: Rx/Tx is disabled on this device because an unsupported SFP module type was detected.

真相大白:不是硬件故障,而是 i40e 驱动配合网卡 NVM 对模块 EEPROM 做了兼容性/认证检查,检测失败后关闭了该端口的收发。这条日志比 LED、Link detected 或 DOM 数值更有诊断价值。不同 OEM 和 NVM 版本的检查范围可能不同,因此应以本机日志和实测为准。

走过的弯路(按时间顺序,方便大家避坑)

弯路一:allow_unsupported_sfp 模块参数

一开始误以为跟 ixgbe(82599 系列)一样,i40e 也有一个 allow_unsupported_sfp 模块参数可以放开限制。折腾了半天加载参数,结果 dmesg 报:

i40e: unknown parameter 'allow_unsupported_sfp' ignored

后来查证:这个参数根本不属于 i40e 驱动,是 ixgbe 驱动的专属参数,i40e 从来没有过这个开关。Intel 官方社区对这个诉求的回复也是明确的“不支持”。

弯路二:DKMS 编译最新版 Intel 官方驱动

以为是发行版内核阉割了这个参数,于是从 GitHub 拉了 Intel 官方最新驱动源码(ethernet-linux-i40e),用 DKMS 编译安装。折腾过程中还踩了几个小坑:

• GitHub tag 命名格式记错,下载链接猜错版本号
• 目录名要跟 dkms.conf 里的 PACKAGE_NAME/PACKAGE_VERSION 严格对应
• 编译报错缺内核头文件,需要装 pve-headers-$(uname -r)

编译安装成功后,依然报 unknown parameter 'allow_unsupported_sfp' ignored——彻底证实这个参数在 i40e 里就是不存在的东西,DKMS 这条路线白折腾了。而且这次操作还带来一个副作用:网卡接口名从 enp1s0f0np0 变成了 enp1s0f0(丢失了 phys port 后缀),一度让人担心 bond 配置失效,后来 dkms remove 卸载回退,接口名才恢复正常。

教训:动手改驱动前,先确认这个参数到底是不是这个驱动系列真实支持的东西,不要想当然。

弯路三:固件升级(9.57)

抱着“新固件说不定放宽了限制”的心态,用 Intel 官方 NVM Update Tool 把固件从 8.50 升级到 9.57。结果:

• 升级过程本身很顺利(Flash update successful)
• 升级后光口依然是老样子,TX 还是 0
• 而且这次连 unsupported SFP module type was detected 这行报错都不打了——校验逻辑变得更底层、更“沉默”

教训:版本越新,这类“防呆”校验通常只会更严格,不会放松,不要抱侥幸心理往新版本方向赌。

变更前必须做的准备

NVM 修改属于持久化变更,风险高于普通驱动升级。先安排维护窗口,准备本地控制台或带外管理,并记录原始状态:

ethtool -i enp1s0f0np0
ip -br link
ip -d link show enp1s0f0np0

确认接口没有承载管理网络或存储流量,从 bond/bridge 中临时摘除,并按照网卡/OEM 文档备份 NVM。不要把 ethtool -m 导出的模块 EEPROM 当作网卡 NVM 备份,两者不是同一份数据；也不要在没有恢复路径时批量修改两张卡。

弯路四:固件降级,但卡在版本号不匹配

反过来想,既然新固件更严格,能不能降级到更老的版本?正好手上另一台 Unraid 机器上有一张同型号(Subsystem 完全一致)的 X710 卡,固件是 6.01,用的是同一颗杂牌模块,居然能正常工作——这是个很有力的证据,说明老固件确实没有这个限制(或者限制更宽松)。

但降级这条路走得也不顺:

• Intel 官方 NVM Downgrade Package 最低只能降到 6.80,到不了 6.01
• 更麻烦的是,官方降级包严格校验“当前版本必须精确是 9.56“才允许操作,而我们升级后是 9.57,直接被拒绝(Update not available / Device not found)
• 尝试先退回 8.50 再降级,同样因为版本号不精确匹配而失败

教训:官方降级工具的版本匹配非常死板,发布节奏跟不上的话,一个小版本号差异(9.57 vs 9.56)就可能让整条官方路径失效。

最终方案:第三方 NVM 解锁工具

在几乎要放弃、准备直接换模块的时候,找到了一个专门解决这个问题的开源项目:xl710-unlocker。

原理:Intel 官方数据手册里其实明确写过,“模块认证校验”本身是一个可以被启用/禁用的功能开关,只是默认被锁定。这个工具做的事情很纯粹:动态扫描网卡自身 NVM 里存放这个开关标志位的偏移量,把它从“锁定”翻转成“放开”,不涉及整体固件版本的升降级,也不需要跟 Intel 官方降级包的版本白名单打交道。

操作过程:

apt install build-essential git
git clone https://github.com/bibigon812/xl710-unlocker.git
cd xl710-unlocker
make
./xl710_unlock -n enp1s0f0np0

该工具不是 Intel 或 Proxmox 的官方支持路径,使用前应审阅源码、确认板卡型号和 NVM 版本在项目支持范围内,并先阅读项目 README 的备份/恢复说明。命令中的接口名要替换成实际端口；如果端口属于 bond、Linux bridge 或 PVE 管理网络,先在带外控制台操作,避免重启后失联。

工具会先扫描并打印出准备修改的内容,等待确认后才真正写入:

EMP SR offset: 0x6874
PHY offset: 0x69c4
PHY data struct size: 0x000d
MISC: 0x6b0c <- locked
MISC: 0x6b0c <- locked
MISC: 0x6b0c <- locked
MISC: 0x6b0c <- locked
Ready to fix it? [y/N]: y

确认执行、重启后,效果立竿见影:

i40e 0000:01:00.0 eth3: NIC Link is Up, 10 Gbps Full Duplex, Flow Control: None
i40e 0000:01:00.1 eth0: NIC Link is Up, 10 Gbps Full Duplex, Flow Control: None

Laser bias current                        : 6.438 mA
Laser output power                        : 0.6849 mW / -1.64 dBm

两个口全部满速链接,发射功率恢复正常,之前那一堆 low alarm 也全部变成 Off。

上线前再做一次双向验证,不要只看 LED:

ethtool enp1s0f0np0
ethtool -S enp1s0f0np0 | grep -Ei 'err|drop|crc|fault'
ping -M do -s 8972 <对端地址>       # 按 MTU 调整,验证大包路径
iperf3 -c <对端地址> -P 4 -t 30     # 在维护窗口内验证吞吐

检查 Speed、Duplex、FEC、错误计数和对端端口状态；若能链路但吞吐异常,优先核对两端 FEC、MTU、光纤类型和交换机端口配置。若修改后无法启动或端口持续报错,立即停止继续写入,按工具和 OEM 文档恢复原 NVM 或更换已验证的兼容模块。

复盘与经验总结

1. 两个口同时异常时,要优先怀疑“统一规则拦截”,而不是“两个硬件同时巧合损坏”。 概率论上后者极低,前者(驱动/固件的策略性拦截)才是更合理的第一假设。

2. dmesg 缓冲区会被冲刷,排查开机时的问题优先用 journalctl -b 0,能拿到完整的当次开机日志,不会漏掉关键报错。

3. 不要凭记忆假设某个模块参数存在,先查证。 allow_unsupported_sfp 是 ixgbe 的参数,不是 i40e 的,这个先入为主的错误方向浪费了不少时间。

4. 固件/驱动版本的调整方向要基于实测证据,而不是“感觉”。 我们靠对比两台机器实际固件版本和实际表现,才得出“版本越老限制越松”这个可信结论,而不是凭空猜测。

5. 官方渠道不是万能的。 Intel 官方降级包对版本号的匹配非常严格,一旦你的版本比官方包发布得更新(比如 9.57 晚于官方包描述的 9.56),官方路径可能直接走不通,这时候需要考虑第三方社区方案。

6. 判断第三方工具是否可信,可以看:是否有对应的官方文档佐证原理合理性、是否有多个独立用户的正面反馈、操作过程是否有“预览确认”环节而不是无脑直接写入。 xl710-unlocker 这三点都满足,所以在评估后选择了尝试。

7. 这类底层修改是写入网卡自身 NVM 的,会持久保留(甚至换主机也不受影响),但会被官方固件升级/降级工具覆盖。 记得在运维文档里留一笔,避免未来做固件维护时忘了这个前情,重新踩一遍坑。

8. 把“能亮”和“可长期运行”分开验收。 先确认链路协商,再用错误计数、长时间吞吐和重启后的持久性验证；只凭 LED 或一次 Link detected: yes 不能证明模块、FEC 和光纤组合稳定。

9. 优先使用有明确兼容性声明的模块或 DAC/AOC。 解锁认证会绕过网卡的一层保护,不会修复波长、光功率、编码、温度或 EEPROM 数据不规范等真实硬件问题；出现 CRC、丢包或温度告警时应换用经过验证的模块,而不是继续扩大 NVM 修改范围。

参考链接

• xl710-unlocker (bibigon812 fork)
• Intel NVM Downgrade Packages for 700 Series
• Intel NVM Update Utility for 700 Series