R630上的Intel X520拒绝一个10GBASE-T铜缆SFP+，comp_codes_10g=0x00，尽管已经设置了allow_unsupported_sfp=1
我们正在把一对R630整合到10G网络上，机架顶部的布线是铜缆，所以我没有拉光纤，而是给X520网卡装上了10GBASE-T的SFP+模块。交换机那端二话不说就接受了。服务器这端不干。
- Dell PowerEdge R630，Intel X520（82599），双口
- FS SFP-10GM-T-30，Dell编码，每台服务器一个模块
- Intel提供的树外ixgbe，通过DKMS构建
- /etc/modprobe.d/ixgbe.conf，两个端口都设置了override
# 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 ixgbe allow_unsupported_sfp=1，也加了modprobe.d的配置项 - 重建了initramfs并冷启动整台机器，而不只是重新加载模块
- 把模块换到第二个端口，再换到第二台服务器，结果一样
有意思的是那个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+对10G的compliance codes只能全报零，这正是你的
comp_codes_10g=0x00。ixgbe读到这个字节，发现里面没有任何它认识的10G模块标志，就在那一步直接放弃了，根本还没走到allow_unsupported_sfp这个override判断那里。这就是为什么这个flag对一个不合格的光模块或者一根DAC能起作用，对你这种铜缆模块却完全没用。有一个针对Intel树外ixgbe的社区补丁，把compliance检查的位置挪了一下：当管理员显式设置了
allow_unsupported_sfp=1之后，一个10G compliance codes全为零的模块会被归类为SR，而不是在早期就被扔掉。这个补丁提交到了上游，但至今没有被合并，所以你得自己把它打到DKMS的源码里，并且随你的构建一起保留下来。写这个补丁的人后来在一对服务器上报告能跑到10 Gb/s全双工，另外还有人确认同一个补丁能让HLX-SFPX铜缆模块在X520上工作。动手之前有两点要提醒。Intel没有认证过的光模块，本来就不在他们的兼容性保证范围内，所以这就变成了你自己的问题，而不是他们的。而且10GBASE-T的PHY是个发热大户——在没有自身风道的服务器插槽里，它的温度会明显高于旁边插槽里的任何光模块，链路起来之后记得盯着模块温度。
在动手打补丁之前，先确认两件事。
第一，在一台经过冷启动而不是重新加载模块的机器上，打印一下内核实际看到的参数，
/sys/module/ixgbe/parameters/allow_unsupported_sfp。如果读出来的值和你配置文件里写的不完全一致，那说明有什么东西在你的配置生效之前就已经加载了驱动，后面再怎么排查都是白费功夫。第二，加载的是哪个版本的ixgbe？
ethtool -i在驱动一直没加载成功、接口都不存在的情况下对你没什么用，所以贴一下modinfo ixgbe的输出，以及你构建的DKMS包的版本号。还有，那个
comp_codes_10g=0x00是从哪儿来的——是驱动告诉你的，还是你自己dump了模块的EEPROM？配置文件里参数是
1,1，冷启动之后/sys/module/ixgbe/parameters/allow_unsupported_sfp读出来也是1,1，所以确实生效了，不是被悄悄忽略。initramfs是在启动前重建过的。不管怎样dmesg里都是同一行。我自己从SFF-8472的数据里读出了compliance codes，不是驱动告诉我的——10G compliance字节是零，ID字段里的其他内容看起来都正常。同一个模块插在交换机端口上是能以10G起链路的，所以不是模块坏了。
补充一个实际经验：用DKMS的话，每次内核更新都会从磁盘上的源码重新构建，所以补丁得放进那个源码树里，而不是一个你事后清理掉的构建目录。最好在第一次内核升级之后就确认端口还能起来，而不是等到某次重启窗口才发现问题。
这类问题更大的教训是：驱动版本比模块编码更能决定结果。X710上一根无源DAC也是同样的故事：同一根线、同一个端口，在Ubuntu 24.04下好好的，在TrueNAS SCALE下却是
Link detected: no和Speed: Unknown，因为那个版本带的i40e来自6.6.44-production内核。在25.04-BETA.1上，i40e取自6.12.9-production，同一根twinax线自己就起来了——其他什么都没动，网卡固件还是9.20。同一个端口上光模块在两个系统下都没问题，这正说明问题出在旧驱动怎么处理无源铜缆上。两边都跑一下ethtool -i本可以省下不少换线的功夫。模块类型不一样，但驱动是同一个，顺带提一个值得排除的坑。Dell R720配X520子卡，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，以后接手这台机器的人看了大概率会一头雾水。这个模块跑起来也明显比旁边插槽里的光模块热不少，而那个插槽基本没什么像样的风道。下一批服务器我打算直接拉光纤，不再跟驱动较劲了。