NETDEV WATCHDOG: transmit queue timed out 导致网卡卡死的修复流程

先看dmesg报错括号内驱动名（如tg3），再用ethtool -i接口名|grep driver和lsmod|grep驱动名确认一致；若ethtool报“No such device”或lsmod无输出，即为驱动层异常。

怎么快速确认是哪个网卡和驱动在出问题

报错里带括号的驱动名（比如 NETDEV WATCHDOG: eth0 (tg3): transmit queue 0 timed out）就是关键线索。别急着重启，先用两行命令锁死目标：

• dmesg -T | grep -i "watchdog.*timed out" —— 看最近一次报错绑定的是哪个接口和驱动
• ethtool -i eth0 | grep driver —— 验证驱动名是否一致（把 eth0 换成你实际的接口名）
• lsmod | grep tg3 —— 确认模块已加载（tg3 替换为你的驱动名）

如果 ethtool 报 “No such device”，说明接口已被内核禁用；如果 lsmod 没输出，说明驱动可能已崩溃卸载——这两种情况都指向驱动层异常，不是配置或网络问题。

临时恢复：不重启系统，让网卡“活过来”

这是最常用也最有效的应急操作，但必须确保你有带外访问（iDRAC/iLO）或本地终端，否则 ip link set eth0 down 后 ssh 会断连且无法恢复。

• 先关闭接口：ip link set eth0 down
• 卸载驱动：rmmod tg3（注意：某些驱动如 mlx5_core 依赖 mlx5_ib 等子模块，得按 lsmod | grep mlx5 输出顺序反向卸载）
• 重载驱动：modprobe tg3
• 启用接口：ip link set eth0 up
• 验证是否恢复：ethtool eth0 | grep "Link detected" 应返回 yes，且 cat /proc/interrupts | grep eth0 中中断计数随流量增长

若 rmmod 报 Module tg3 is in use，用 lsof -nPi | grep eth0 查占用进程；强制卸载（rmmod -f）风险高，可能引发 panic，不推荐。

永久修复：盯紧固件、驱动参数、硬件三处硬伤

临时重载只是绕过问题，真正稳定要从底层收敛。90% 的反复触发都源于这三点：

• 固件过旧：Broadcom tg3、Intel e1000e 在高吞吐下易卡死 TX 状态机。去官网下载最新 .bin 固件 + 安装对应 firmware 包（如 bnx2-firmware 或 intel-microcode），别信 distro 自带的“够用”版本
• 驱动参数失配：比如 r8169 驱动对老 Realtek 芯片兼容性差，常需换回厂商提供的 r8168；又如 ethtool -K eth0 tso off 关闭 TCP 分段卸载，可缓解部分 DMA 映射失败场景
• 硬件隐性故障：曾有案例是网口电路中一个 0402 封装电阻虚焊，热胀冷缩后间歇开路，dmesg 反复刷 watchdog 错误，但 ethtool 和 ping 全部正常——这种必须拆机查板，万用表测阻值+热风枪补焊

内核启动参数如 acpi=off noapic 是“试错型兜底”，仅适用于老旧服务器 bios/ACPI 实现有缺陷的场景，现代系统加了反而可能引发其他中断异常，别当成标准解法。

为什么不能只靠 sysctl 或网络服务重启

这个错误不是网络栈配置问题，而是内核发现驱动 ndo_tx_timeout 回调未被及时触发，于是主动停用队列并归零 tx_queue_len。所以：

• systemctl restart networking 或 NetworkManager 无效——它只重载用户态配置，驱动状态早已僵死
• sysctl -w net.ipv4.tcp_ecn=0 或关 ipv6 也没用——这些影响的是协议栈行为，不解决 TX 描述符耗尽、DMA 失败或中断丢失等驱动层死锁
• 错误日志出自 net/sched/sch_generic.c 的 dev_watchdog() 函数，本质是内核对驱动“不作为”的惩罚机制，不是告警，是判决

真正难排查的，是那些看起来一切正常却突然卡死的案例：ping 通、tcpdump 能抓到包、ethtool 显示 link up，但所有出向流量停滞——这时候请直奔驱动源码和硬件，别在用户态打转。