排查网卡丢包需聚焦硬件退化特征：盯住ethtool -s中rx_over_errors、rx_fifo_errors、rx_crc_errors、rx_missed_errors四类指标趋势，结合ethtool链路状态比对与dmesg硬件告警，确认光模块老化、dma异常或固件故障。
排查网卡丢包严重的硬件原因，核心是绕过协议栈干扰，直击物理链路、网卡固件与DMA行为的异常痕迹。不能只看“有没有丢包”，而要看“丢包是否伴随硬件退化特征”——比如缓慢爬升的错误计数、链路状态波动、内核底层报错。
盯住 ethtool -S 中最敏感的硬件信号
执行 ethtool -S eth0 | grep -E "(rx_over_errors|rx_fifo_errors|rx_crc_errors|rx_frame_errors|rx_missed_errors)"，重点关注以下四类字段：
- rx_over_errors 持续上升：Ring Buffer 溢出，但若业务流量稳定时仍缓慢增长（如每小时+3～8），大概率不是配置问题，而是网卡 DMA 响应变慢或驱动异常的早期征兆；
- rx_fifo_errors 同步上涨：说明网卡芯片内部 FIFO 缓冲区已满，常见于光模块老化、线缆微弯导致误码率升高后重试加剧；
- rx_crc_errors / rx_frame_errors 稳定增加：不直接等于丢包，却是物理链路劣化的“金标准”。每小时新增 1–2 个 CRC 错误持续超过 24 小时，基本可锁定光纤衰减、模块温度漂移或端口氧化；
- rx_missed_errors 显著上升（尤其虚拟机）：vCPU 调度延迟导致中断丢失，本质是宿主机 CPU 资源争抢或绑定失当，属硬件资源层瓶颈，需结合 dmesg | grep -i "missed" 验证。
比对链路协商状态与历史基线
运行 ethtool eth0，检查三项关键输出：
- Link detected: yes —— 若偶发变为 no，说明物理连接松动或光功率临界；
- Speed: 10000Mb/s & Duplex: Full —— 若降速为 1000Mb/s 或变为 Half，大概率是光衰超标或对端协商异常；
- FEC: enabled (cl91) —— 若某时段 FEC 自动 disabled 或变为 off，指向光模块兼容性退化或固件 bug。
更重要的是横向对比：同一机房、同型号服务器、同批次光模块的多台机器，若仅某台出现上述指标异常，即可排除共性配置或网络侧问题，聚焦单机硬件更换。
捕获内核底层硬件告警日志
硬件故障往往先在 dmesg 留痕，再反映到统计计数器上。运行：
dmesg -T | grep -i "eth\|nic\|firmware\|dma\|timeout\|pcie" | tail -60
重点关注带时间戳的硬性报错：
- "DMA timed out" → 网卡 DMA 异常，常见于 PCIe 插槽松动或主板供电不稳；
- "firmware hang" 或 "tx timeout, resetting" → 网卡固件死锁，需升级固件或更换；
- "PCIe bus error" → 物理层通信故障，优先重插网卡、清洁金手指，必要时换槽位测试。
用趋势监控替代人工盯屏
单次采样毫无意义。丢包类硬件问题是渐进式退化，必须观察变化趋势：
- 用 watch -n 30 'ethtool -S eth0 | grep -E "(rx_over_errors|rx_crc_errors)"' 每 30 秒抓一次快照；
- 配合简单脚本记录历史值（例如写入 CSV），绘制 24 小时曲线；
- 若发现 rx_crc_errors 曲线呈阶梯式缓升 + rx_over_errors 同步抬升 + dmesg 出现 firmware 相关 warning，基本可判定为光模块或网卡硬件寿命终结，建议 48 小时内安排热备替换。
