应直接用ip -s link show dev网卡名查看rx/tx errors聚合值，但无法区分错误类型；需结合ethtool -s查底层寄存器细分字段（如rx_crc_errors、rx_missed_errors），并确认link状态与驱动支持，/proc/net/dev和netstat -i的errs列不可信。
直接用 ip -s link show dev 看聚合错误数，但别指望它分类型
ip -s link show dev <code>eth0 输出里 rx_errors 和 tx_errors 是总和，不是分类明细。它只告诉你“错了多少”，不告诉你“哪类错”。比如 rx_errors 里混着 rx_crc_errors、rx_frame_errors、rx_length_errors 等十几种底层错误，全被压成一个数字。想看分类，必须换命令。
查具体错误类型必须用 ethtool -S，且得先确认网卡型号和驱动状态
ethtool -S <code>eth0 才是真正暴露硬件寄存器级错误分类的命令。但它依赖驱动支持，不同芯片（Intel igb、Broadcom bnxt、Mellanox mlx5）输出字段名差异很大：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 先运行
ethtool <code>eth0确认Link detected: yes和Speed:正常，否则-S可能返回空或无效值 - 再执行
ethtool -S <code>eth0| grep -i "crc\|frame\|miss\|drop\|over" 过滤关键字段 - 常见有效字段：
rx_crc_errors（线缆/端口问题）、rx_missed_errors（ring buffer 溢出）、rx_over_errors（FIFO 溢出）、tx_aborted_errors（PHY 异常） - 某些虚拟网卡（如 veth、macvlan）不支持
-S，会报No register dump available
为什么 /proc/net/dev 和 netstat -i 的 errs 列不能信
/proc/net/dev 第三列叫 errs，但它只是 rx_errors 的镜像，而且部分驱动（尤其是老芯片或虚拟网卡）根本不更新这一列，可能长期为 0 即使实际错包猛涨。netstat -i 的 errs 更糟：它把 RX 和 TX 错误合并在一列，根本分不清方向，也看不到 dropped 或 overruns 这些关键子项。真要排障，ip -s link 的 rx_errors 和 ethtool -S 的细分字段才是唯一可信来源。
实时监控需自己算差值，ip -s 本身不提供速率
ip -s link show 所有数值都是累计值，重启网卡或系统后归零。所谓“实时”只是快照，不是流速：
- 用
watch -n 1 'ip -s link show dev <code>eth0| grep -A 2 "RX\|TX"' 只能肉眼盯变化，不精确 - 脚本化监控必须两次读取 + 差值计算：提取
rx_crc_errors字段（来自ethtool -S）或rx_errors（来自ip -s），再除以时间间隔 - 注意
ethtool -S输出不是每秒刷新，它是静态寄存器快照，两次调用间隔太短（如 100ms）可能看不出变化
rx_crc_errors 上升时，得立刻判断是网线松动、交换机端口老化，还是光模块衰减——这些靠命令本身给不出答案，只能靠经验交叉验证。
