Dell M14MK SFP28在OpenWrt上因no common interface modes被拒绝,而QSFPTEK SFP+能正常建链
小型家庭实验室。我把一台Linksys LGS328C刷成了OpenWrt SNAPSHOT,想摆脱原厂的Web界面。除了一个原本工作得好好的SFP28端口,其他都平稳过渡了。
- 交换机:Linksys LGS328C(Realtek rtl930x),OpenWrt SNAPSHOT
- 模块:Dell S28-10G-25G-SR-85C,双速率10G/25G,EEPROM读出来是DELL M14MK rev A1
- 同一个笼子里用作对照的模块:QSFPTEK QT-SFP+-SR
- 两次测试用的都是同一根光纤和同一个对端
Dell模块被检测到之后立刻就被扔出来了:
sfp sfp-p49: module DELL M14MK rev A1
rtl83xx-switch ...: unsupported SFP module: no common interface modes
# ethtool lan28
Advertised link modes: 10000baseCR/Full
Link detected: no我已经检查过的地方:
- 把QSFPTEK SFP+插进同一个笼子:日志显示端口选中了inband/10gbase-r,能得到干净的10Gbps链路;
- 同一个Dell模块在这台交换机的原厂固件下工作正常,所以模块本身没坏;
- 重插并清洁了接头,日志没有任何变化。
这个模块是不是真的编码有问题,还是说交换机驱动对一个支持25G的模块过于挑剔?我更想搞明白原因,而不只是再买一个模块了事。
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 5
那份日志已经把整件事解释清楚了。内核的sfp层在判断一个模块能跑哪些接口模式时,唯一的输入就是那些一致性字节。这些字节一个都没设置,算出来就是一个空集合,再和MAC这边能提供的模式取交集,结果自然是空,于是打印出你看到的那条消息。ethtool里的10000baseCR/Full是端口这一侧留下来的东西,不是模块申报的。原厂固件不在乎这些,因为那些镜像通常整个跳过一致性字节,而是拿厂商和型号字符串去匹配一份写死的列表——这就是为什么这个光模块在你刷机之前是能用的。
真正能站得住的修法是加一条模块quirk。在drivers/net/phy/sfp.c里加一条SFP_QUIRK_S条目,匹配厂商DELL、型号M14MK,强制设置ETHTOOL_LINK_MODE_10000baseSR_Full和PHY_INTERFACE_MODE_10GBASER,然后重新编译镜像。端口就会以普通10G链路的方式起来,报告10000baseSR/Full,日志里那条unsupported-module的消息也会消失。
有两点要注意。把这个补丁维护成能提交给netdev的样子,而不是自己压在下游一直用:EEPROM是不会自己修好的,别人手里也有同款Dell模块。如果你不想维护自己编译的内核,那就用你手头已经有的QSFPTEK SFP+这个省心方案——反正这个端口能给你的也就是10G。
在怪罪交换机驱动之前,先把EEPROM导出来看看模块自己申报的内容:
ethtool --module-info lan28。把十六进制dump的前几行加上完整的ethtool lan28贴出来。"no common interface modes"的意思是内核算不出一个可用的模式,所以这几个字节里的内容就是这里的全部真相。再确认一件事:QSFPTEK是插在同一个笼子里,不是相邻的另一个吧?你的日志那行写的是p49,而ethtool的输出是lan28,这类测试里搞混端口会浪费不少时间。
导出来了。简单说:根本没有设置任何10G一致性代码——这些字节完全是空的,而厂商和型号字符串填得和一块DELL M14MK rev A1该有的样子完全一致。
ethtool lan28依然显示Advertised link modes: 10000baseCR/Full和Link detected: no,dmesg | grep lan25除了我第一条帖子里那两行之外什么都没有。所以这个模块几乎没告诉主机它到底能干什么,而同一个笼子里的QSFPTEK依然在10Gbps下正常建链。
值得记一笔,因为之前针对这个组合的一份bug报告猜的是另一个原因。那边的理论是,这个双速率模块申报了25gbase-r,而rtl930x驱动没有实现这个模式,取交集结果为空,模块本身没有任何问题。这份十六进制dump把那个解释否掉了:这个模块什么都没申报,不是25G。同样的内核消息,原因却不一样,只有dump才能把这两种情况区分开。
这也提醒了一件事:一个打着厂商品牌的光模块,不代表编码就一定正确。Dell自家的OS10会把一个正牌的Q28-128GFC-SW4(型号KP0VM)显示为QSFP28 100GBASE-SR4、Qualified为false,因为有些批次的EEPROM编码是它的媒质鉴定逻辑不认识的,FC链路会一直down,直到你手动允许不受支持的光模块。
编译了一个带DELL/M14MK这条SFP_QUIRK_S的镜像,效果和你说的完全一样。端口以10Gbps建链,
ethtool lan28现在报告10000baseSR/Full且link up,日志干干净净——哪里都没有unsupported-module那一行了。让它带着真实流量跑了几天,期间没碰这台设备的其他东西,没有任何抖动。现在正在整理这个补丁准备提交给netdev,毕竟只留在自己的代码树里对谁都没帮助。谢谢你推我先去做module-info这个dump,我之前对着驱动的模式表看了两个晚上。