☰
WX1860AL4网卡千兆降百兆故障排查:后两对差分线是关键
2026/9/29 19:57:13 网站建设 项目流程

WX1860AL4这块四口千兆网卡芯片,最近在国产网卡里出镜率很高,很多服务器和工控板卡都拿它做千兆网络接入。我这两周连着处理了两起“千兆变百兆”的故障,症状完全不同,最后定位到的根子却出奇一致:都在四对差分线中的后两对上。一个案例是连接器虚焊,协商始终只有100M;另一个案例更隐蔽,协商显示1000M,但实测速度就是百兆水平,ethtool里rx_crc_errors疯狂增长。这篇文章把完整的排查链路写出来,包括中间用到的原理判断、工具和验证方法。搞过国产网卡或者正在被类似问题困扰的人,可以直接照着这个思路走。

文章基本就是我现场怎么查、怎么想、最后怎么修的复盘。涉及的命令和工具都是Linux环境下最常见的,Windows下的差异我会单独标注。

1. 问题现象与第一轮排查:先别急着甩锅驱动

1.1 两个故障现场,症状完全不一样

现场A是一块四口WX1860AL4网卡,系统环境是Ubuntu 20.04。故障很直接:eth0、eth1两个口千兆正常,eth2、eth3怎么协商都只能到100M。我先把eth2用一根确认没问题的六类线接到一台千兆正常的笔记本上,笔记本这边显示的也是100M。换了交换机、换了线、换了驱动版本,eth2和eth3咬死100M不放。这种“个别口降速、其他口正常”的情况,基本就能判定是物理链路问题,和系统、驱动关系不大。

现场B就狡猾多了。同一款WX1860AL4方案的板卡,四个口在ethtool里都显示1000Mb/s full duplex,看起来一切正常。但只要一开始跑流量就露馅:iperf3单线程测速稳定在93Mbps左右,跑UDP丢包严重,如果持续打流量几分钟,dmesg里还会出现链路异常和PHY报错的日志。我看了ethtool -S的输出,rx_crc_errors、rx_errors这两个计数一直在涨,Tx方向基本干净。这就是典型的“假千兆”——协商显示正常,实际物理层链路质量一塌糊涂。

1.2 先做减法:软件、驱动与系统层排查

遇到千兆降速,第一反应很容易是“驱动挂了吧”。我不否认有驱动问题,但排查顺序很重要:先把软件层排除干净,再往硬件走。

我先确认了驱动版本和固件版本是否是最新的,同时把dmesg整个翻了一遍,没有发现内存分配失败、TX timeout、中断风暴之类的异常。接着用ethtool把网卡的高级特性全部关掉试了一遍——TSO、GRO、LRO、流控这些统统关闭,看是不是卸载引擎或CPU瓶颈导致的测速偏低。实测结果没有变化,故障依旧,这基本排除了协议栈和驱动卸载功能的问题。

然后我做了强制协商测试。在故障口上执行:

ethtool -s ethX autoneg off speed 1000 duplex full

现场A表现是直接协商不上,或者协商上以后立刻掉链子;现场B是强制1000M后也能Link up,但CRC错误继续涨。这说明了什么?现场A的情况说明PHY在自协商阶段就判定链路不合格,主动降级到了100M;现场B则说明“千兆协商成功”和“千兆能正常传输”完全是两码事,链路层存在硬件缺陷。

1.3 顺手排除PCIe链路和供电问题

在锁定“物理层”之前,还有两个容易被忽略的低级问题需要先排除干净。

第一个是PCIe链路降速。WX1860AL4这类四口千兆控制器,如果PCIe链路跑在x1甚至Gen1上,多口同时跑满时总带宽会不够。单独测某个口时可能看不出太大差别,四口同时打流就会露馅。排查时用:

lspci -vvv -s 02:00.0 | grep -A2 LnkSta

注意看LnkSta里显示的当前速度和宽度。如果实际只有2.5GT/s或者x1,可以尝试换到带宽更充足的插槽再验证。这个排查对现场A和现场B都没发现问题,算是排除了一项。

第二个是供电。PCIe插槽供电不足、转接卡质量差、背板供电异常,都会让控制器和PHY在上电后工作在不稳定状态。表现也很多样,有的就是某几个口协商异常,有的干脆直接识别不到网卡。我的习惯是遇到疑难杂症先换插槽、换电源口,排除掉供电因素再继续。这两块板卡换过插槽后故障依旧,继续深挖物理链路。

2. 底层原理:百兆没事、千兆翻车的链路逻辑

2.1 百兆只用两对线,千兆必须四对全通

这是整个问题最核心的理论基础。10/100BASE-TX在物理层只使用4芯线,也就是1-2和3-6这两对双绞线,一对负责发送,一对负责接收。千兆的1000BASE-T则完全不同,它把1-2、3-6、4-5、7-8四对双绞线全部用上,每一对线都是双向传输,速率是250Mbps,四对加起来才是1000Mbps。

打个比方:百兆链路就像一条四车道马路但只开放了两条单行道;千兆链路是把四条车道全部变成双向行车。只要任何一条车道出事,整条路就瘫痪,但你走那两条没出事的车道时,感觉一切正常。

所以一条非常实用的判断规则是:只要一个设备“百兆正常、千兆异常”,优先怀疑四对线里的4-5对和7-8对。这也是我在现场A一开始就重点查后两对差分线的思路来源。同理,如果你用的是普通水晶头、网线只压了4根芯,那必然是百兆,这不是网卡的问题。

2.2 “协商成功”不等于“链路健康”

现场B那种“ethtool显示1000M但实测百兆”的情况,很多刚入行的人想不通:既然协商成功了,为什么不是千兆?

关键在于,以太网的自协商是一个低速的握手过程。自动协商使用的前两对线(1-2、3-6),通过发送和识别DME码流来交换双方支持的速度能力。这个过程本身对链路质量的要求非常低,只要前两对线能通,双方打着千兆的能力牌,协商结果就可能显示1000M。真正进入1000BASE-T数据传输后,四对线都要工作,信号频率变成125MHz的PAM5五电平信号,任何一对线的细微劣化都会直接导致误码。

1000BASE-T在协商后还有一步链路训练(link training),理论上会检测四个线对的质量,但不同PHY芯片实现差异很大。有的PHY检测到后两对失败,干脆整体降到100M,这就是现场A的现象;有的PHY协商和链路训练都能过,但数据一跑就报错,这就是现场B的现象。这也是为什么同一个根因会出现“协商100M”和“协商1000M但CRC爆炸”两种截然不同表现的原因。

2.3 CRC错误到底是谁报出来的

现场B最典型的表现是ethtool -S里rx_crc_errors疯狂增长。这里要搞清楚一个概念:这个计数器是PHY还是MAC报的。

在WX1860AL4这类集成度比较高、控制器直接输出电口的方案里,rx_crc_errors一般来自PHY前端,也就是模拟信号转数字信号、做解码和FCS校验的环节。这个计数增长,直接说明了物理层收到的模拟信号质量太差,采样出来的bit流里出现了错码,导致帧尾的CRC校验失败。引起这种问题的原因,不外乎信号反射、阻抗不连续、差分线断开、变压器不良、连接器弹片接触差、时钟频偏、电源纹波过大。排查方向非常明确:RJ45到变压器到差分走线再到芯片引脚这一整条模拟链路。

如果是外置PHY方案,比如MAC做在WX1860里、外面再接一颗YT8521这种国产千兆PHY,那就要多留一个心眼:ethtool -S里的错误计数,要看清是PHY统计的还是MAC统计的。PHY统计的rx_crc_errors,指向网口侧模拟链路;MAC统计的rx_fcs_errors、rx_errors,则可能指向MAC与PHY之间的RGMII/SGMII接口时序问题。很多人一看到“千兆大量接收CRC错误”,第一反应是PHY芯片不行,其实有相当一部分问题出在RGMII走线或时序配置上,尤其是“百兆正常、千兆CRC很多”这种情况,要优先检查RGMII在千兆模式下的时序和数据眼图。

3. 硬件陷阱定位:从万用表到示波器的实战

3.1 隔离法:先把锅从网线和交换机头上摘掉

进入硬件排查之前,我习惯先用隔离法把外因全部排除干净。这一步看似简单,但非常关键,因为网线老化、水晶头接触不良、对端交换机端口故障,都会产生和现场B几乎一模一样的现象。

具体做法分三步。第一步,用一段确认绝对没问题的六类成品网线,把故障网卡直连到一台确认千兆正常的笔记本或者另一块千兆网卡上,不经过交换机。第二步,如果直连还是不行,换一台设备当对端再试一次。第三步,把故障口旁边的正常口(比如现场A的eth0)接到同样的网线和同样的对端上,如果正常口能协商千兆,说明网线和对端都没问题,问题就在故障口本身。

现场A经过这三步,很快锁定eth2和eth3这两个口在板卡上就是异常状态。现场B更彻底,我把整块板卡换到另一台服务器、别的PCIe插槽上,故障依旧,说明问题不在整机、不在系统,就在这块网卡板卡上。

3.2 万用表按压法:挖出虚焊和接触不良

锁定故障在网卡本身之后,最朴素也最有效的工具是万用表。

先把网卡从机器上拆下来,断电,用万用表的蜂鸣档(二极管/通断档),从RJ45引脚侧量到网络变压器次级绕组,确认每一对线的直流导通性。注意,这里量的是网线插座引脚到变压器对应绕组之间的通路,不是量变压器初级和次级之间的隔离关系。如果你有该网卡的原理图,直接对着网络名称查最稳;没原理图,就顺着RJ45的引脚一路量到变压器焊盘,逐点确认。

这里有个现场维修特别管用的技巧,我叫它“按压复现法”:一手拿绝缘棒或镊子轻轻按压RJ45连接器、轻压网络变压器、稍微弯折一下PCB板边缘,另一只手观察万用表蜂鸣是否出现时断时续或者电阻值跳变。很多虚焊、冷焊、连接器弹片接触不良,在静止状态下用万用表量是正常的,但只要一施加应力就会暴露。现场A的eth3就是这么抓到的——按压RJ45时,7-8这对线对应的变压器引脚到RJ45引脚之间的导通时断时续,明显是连接器引脚虚焊。补焊之后,eth3恢复千兆。

现场A的eth2类似,但位置不同,是变压器引脚焊盘出现了细微裂纹。这种裂纹在目检时不仔细看根本发现不了,万用表按压法一测就现出原形。我后续的批量返修清单里,把“RJ45和变压器焊点”列进了重点目检项。

3.3 示波器与阻抗检查:找出“直流通、高频挂”的暗病

现场B比现场A麻烦。万用表把四对线从RJ45到变压器的直流通路全量了一遍,通断全部正常,按压也没有任何反应。如果只停留在“直流导通”这个层面,很容易误判成“硬件没问题”。

这就引出了一个很重要的概念:直流导通不代表高频链路正常。现场B的故障最后是在PCB走线上找到的——变压器次级到RJ45的4-5这对差分线中间,有一段极细的划痕。刮开阻焊层后看到铜箔已经有明显的损伤痕迹,截面大幅缩窄,但还残留一点相连。这种“半断不断”的状态,直流电阻只增加零点几欧,万用表根本读不出来;但高频信号经过这里时,阻抗突变和反射损耗非常严重。千兆发生时是125MHz符号率,对这种微缺陷极度敏感,所以现象就是CRC错误爆炸;百兆时频率低,损耗和反射都很小,链路反而能正常工作。

有条件的话,这个阶段可以用示波器(建议带宽不低于500MHz)跨在RJ45或变压器初级上看差分信号,对比故障口和正常口的射频发射波形。故障对信号的幅值会明显偏低、波形杂乱,眼图闭合。没有示波器也不致命,平时我更依赖“现象+计数”来佐证:先确认只有4-5或7-8其中一对有问题,再用修复后的验证结果反推。

这里要特别提醒一句:万用表只能测“完全断”或者“明显阻值变化”的故障,对near-open这类暗病几乎无能为力。所以不要因为“万用表全通”就说硬件没问题,该抠细节还是要抠。

3.4 外置PHY方案里的额外嫌疑:YT8521与RGMII

文章前面提到过外置PHY方案,这里单独展开说一下。有些基于WX1860的板卡会采用MAC+外置PHY的结构,比如外接裕太微YT8521这种国产PHY芯片,实现从SGMII/RGMII到电口的转换。这类方案里如果出现“百兆正常、千兆大量RX硬件CRC错误”,除了网口侧物理链路,还有一个重量级嫌疑:MAC与PHY之间的RGMII接口。

RGMII在百兆模式下,时钟只有25MHz,数据沿采样,时序容限非常大,走线稍微长一点、歪一点都能正常工作。但切到千兆模式时,时钟变成125MHz,数据在时钟上下沿都要采样,一个bit周期只有8ns,建保时间余量通常只有1到2ns。如果PCB上RGMII的时钟走线和数据走线不等长,或者时钟相位配置不对,千兆模式就会出现大量数据采样错误,百兆模式却一点事没有。现象上和网口侧链路问题高度相似。

排查方法也不复杂。第一,看错误计数器名称,如果报的是MAC侧的rx_fcs_errors、rx_errors而PHY侧rx_crc_errors不涨,优先怀疑RGMII。第二,看PHY驱动是否支持调整TX/RX delay,很多国产PHY驱动里有类似rgmii-txid/rgmii-rxid或者通过寄存器配置相位延迟的选项,可以试着切换ID模式。第三,用示波器测PHY和MAC之间的RGMII时钟与数据信号,看数据是否在时钟沿附近稳定建立,这是最直接的证据。另外,外置PHY方案的25MHz参考晶振也是排查重点,频偏过大会直接导致千兆误码,用频率计测一下,偏差最好控制在50ppm以内。

4. 修复验证与批量板卡规避

4.1 补焊后的验证流程与测速脚本

现场A的处理比较直接:补焊虚焊点、补焊变压器焊盘,然后重新上电验证。换完件先目检,确认没有连锡、桥接、明显空焊,再把网卡插回机器。

验证我按三个步骤走。第一步,重启网卡,让计数器归零:

ip link set dev ethX down ip link set dev ethX up

第二步,检查协商结果和错误计数:

ethtool ethX ethtool -S ethX | grep -E 'rx_crc_errors|rx_errors|rx_fcs_errors'

第三步,双向跑iperf3,同时观察计数变化。测速命令参考:

iperf3 -c 192.168.10.2 -t 30 -i 0

测完TCP再补一轮UDP打流,看丢包率:

iperf3 -c 192.168.10.2 -u -b 900M -t 30

修好的板卡,TCP应该跑满千兆,950Mbps左右,UDP丢包率在千分级别以下,连续打流半小时rx_crc_errors不增长。现场A修复后eth2、eth3都恢复正常,现场B补好PCB走线上的划伤(重新补铜处理)后,那个口连续打流一小时,错误计数始终为0。

4.2 产线测试怎么堵住这个坑

像现场A、现场B这类问题,本质上是生产制造或设计环节的缺陷,如果产线老化测试能覆盖到位,完全可以提前暴露。

我的建议是产线测试不要只测“能不能link up”,一定要加上“千兆模式下持续打流+错误计数监控”。四口网卡要四口同时千兆打流,双向都测,至少连续跑几个小时。测试脚本很简单,循环采集ethtool -S里的错误计数,某口错误超过阈值直接判fail。这一步能筛掉绝大多数连接器虚焊、变压器不良、PCB走线暗伤。

目检环节也重要。需要重点看的位置包括:RJ45连接器引脚、网络变压器焊盘、共模电感、PCB差分走线区域,尤其是靠近连接器和变压器的地方。使用放大镜或显微镜做外观检查,发现引脚少锡、焊盘裂纹、铜箔划伤的板卡直接拦截。原材料的来料检查也不能省,连接器弹片氧化、变压器绕组不良是重灾区,有条件可以对来料做抽检。

4.3 设计上怎么规避硬件陷阱

从设计角度讲,有几个点值得在原理图和PCB阶段就注意,不然生产出来一批就要返工一批。

第一,千兆差分对必须按100Ω±10%的差分阻抗控制,四对线组内等长,尽量避免跨分割和过长stub。很多板卡为了省面积,差分线绕来绕去,过孔又不对称,千兆信号出来就是歪的。第二,网络变压器、共模电感不要省,中心抽头和Bob Smith端接的电阻电容必须按参考设计位放到位,这是共模回流和EMI抑制的关键。第三,RJ45连接器尽量选带屏蔽、弹片镀金层厚度足的方案,无屏蔽的廉价连接器在复杂电磁环境下容易出千兆误码。第四,PCB上在变压器次级和RJ45之间预留测试点,方便产线和售后用示波器、TDR做检测,真出了问题不用刮开阻焊层找信号。

另外提醒一句,如果方案里用了外置PHY,RGMII走线等长、时钟相位配置这些一定要在样板阶段就验证好,不要等到量产发现问题再改。RGMII的时序问题改板成本很高,前期多花半小时测眼图,后面能省下大量返工时间。

5. 常见问题速查与独家排查技巧

5.1 千兆降速百兆/虚连的排查优先级表

我根据这两个案例,整理了一份排查优先级表。遇到类似问题可以直接对照,少走弯路。

现象可能原因快速排查手段最终处理方向
所有口都只协商100M驱动/BIOS配置、PHY初始化失败、系统把网口锁成了100M检查Windows高级设置或Linux ethtool恢复自动协商,升级驱动/固件
个别口协商100M网线、水晶头、对端端口、连接器/变压器焊接换线、交叉测试、万用表按压法补焊、更换连接器
全部口协商1000M但速度上不去多口同时满速时PCIe链路带宽不足lspci -vvv 看LnkSta换插槽/换主板
协商1000M但CRC错误暴涨四对线中的后两对物理链路不良、时钟频偏、电源纹波ethtool -S看计数、示波器/万用表结合修走线、补焊、换晶振/换PHY
强制1000M完全不通线对断路、PHY/变压器严重损坏万用表逐段量通断换件
间歇性降速/链路反复up-down连接器氧化、虚焊、温度变化导致接触不良按压复现法、温度循环测试补焊/更换连接器
网线测试仪显示全通,但千兆失败差分线阻抗异常、near-open暗病示波器/TDR、打流+错误计数监控修复走线,镀金/换件

5.2 几个只有踩过坑才知道的细节

这里分享几个平时文档里很少写、但实际操作中很值钱的细节。

第一,不要迷信“Link detected: yes”和“Speed: 1000Mb/s”。这两个信息只能说明PHY的状态寄存器里写的是千兆,不能代表链路质量。真正能反映链路质量的,是错误计数器这些统计值。

第二,网线测试仪只能测通断和线序,测不出阻抗、串扰和衰减。现场很多网线测试仪“全通”但千兆不通的案子,最后都是高频参数不合格。正常的网络链路认证测试要用福禄克级别的仪表。

第三,用万用表按压法时,最好把网卡完全断电,并且在量到疑似虚焊位置时,用轻微力道按压即可,不要用力过猛把焊盘按掉。这是个经验活,多试几次手感就对了。

第四,如果故障只在特定温度或者特定湿度环境下出现,不要排除连接器弹片氧化或者焊点热胀冷缩的问题。这种问题最隐蔽,平时正常,一热机就掉速,需要做温度循环复现。

第五,Windows系统下有个常见坑:网卡高级属性里的“速度和双工”被手动设成了100Mbps全双工。这种设置下无论如何都是百兆,而且换线换交换机都没用。排查前先把这个选项恢复为“自动协商”。

5.3 一个顺手可用的监控脚本

最后给一个我在产测和售后排查时经常用的脚本思路。它做的事情很简单:循环打流、采集错误计数、对比增长情况。你也可以按自己的网卡计数器名称改一下字段。

#!/bin/bash IFACE=ethX REMOTE=192.168.10.2 for i in $(seq 1 20); do before=$(ethtool -S $IFACE | grep -E 'rx_crc_errors|rx_errors|rx_fcs_errors' | awk '{print $2}' | tr '\n' ' ') iperf3 -c $REMOTE -t 10 -i 0 > /tmp/iperf_run.log 2>&1 rate=$(grep 'receiver' /tmp/iperf_run.log | awk '{print $7}') after=$(ethtool -S $IFACE | grep -E 'rx_crc_errors|rx_errors|rx_fcs_errors' | awk '{print $2}' | tr '\n' ' ') echo "$(date +%T) rate=${rate}Mbps before=[$before] after=[$after]" sleep 1 done

如果after比before稳定变大,基本可以确认物理链路在掉包,问题在硬件侧;如果计数一直为0但速度就是上不去,再去查PCIe带宽、驱动卸载、CPU频率这些方向。这套思路用熟了,能帮你快速把“软件问题”和“硬件问题”劈成两半。

修完这次两个故障以后,我自己最大的体会是:WX1860AL4这类国产网卡芯片本身已经比较成熟,软件驱动也相对稳定,真正消耗时间的反而是外面这些不起眼的连接器、变压器、焊点和PCB走线。以后你再遇到“百兆正常、千兆翻车”,别急着骂芯片,先把RJ45到变压器到差分走线这条链路过一遍,大概率能省下好几个小时。要是再能配合按压复现法,很多虚焊问题当场就能现形。

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询