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做检测真出了问题不用刮开阻焊层找信号。另外提醒一句如果方案里用了外置PHYRGMII走线等长、时钟相位配置这些一定要在样板阶段就验证好不要等到量产发现问题再改。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 IFACEethX REMOTE192.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 21 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到变压器到差分走线这条链路过一遍大概率能省下好几个小时。要是再能配合按压复现法很多虚焊问题当场就能现形。