使用ethtool（版本 6）例如给出以下输出：
$ ethtool -S eth0
NIC statistics:
early_rx: 0
tx_buf_mapped: 0
tx_timeouts: 142
rx_lost_in_ring: 0
的值是什么意思tx_timeouts？142 这个数字代表什么？
答案1
从O'reilly Linux 设备驱动程序‘传输超时’部分：
大多数处理实际硬件的驱动程序都必须做好应对硬件偶尔无法响应的准备。接口可能会忘记它们正在做什么，或者系统可能会丢失中断。这类问题在某些设计用于个人计算机的设备中很常见。
许多驱动程序通过设置计时器来处理此问题；如果操作在计时器到期时仍未完成，则说明出现了问题。实际上，网络系统本质上是一个由大量计时器控制的复杂状态机组合。因此，网络代码可以很好地自动检测传输超时。
因此，网络驱动程序无需担心自己检测此类问题。相反，它们只需设置一个超时期限，该期限位于 net_device 结构的 watchdog_timeo 字段中。该期限以 jiffies 为单位，应该足够长以解决正常的传输延迟（例如，由于网络媒体拥塞而导致的冲突）。
如果当前系统时间至少超过设备的 trans_start 时间的超时期限，则网络层最终将调用驱动程序的 tx_timeout 方法。该方法的作用是采取一切必要措施来解决问题并确保正确完成已在进行的任何传输。特别重要的是，驱动程序不要丢失由网络代码委托给它的任何套接字缓冲区的跟踪。
因此，tx_timeout 结构似乎是为了确保当硬件出现问题时系统不会锁定。我不知道为什么你的不是 0，但这可能与 NIC 驱动程序有关。
答案2
tx_超时严格来说，是设备驱动程序处理超时例程被调用的次数。
每当传输硬件无法响应时，就会发生传输超时。这种情况在现实生活中会发生，例如，中断丢失，或者因为您的 NIC 正在forgotten执行操作。这绝不是罕见的情况，尤其是在个人电脑上。
设备驱动程序被设计成通过一个计时器来处理这些事件：它标记了传输应该发生的时间；如果没有发生，控制权就转移到tx_超时例程将采取适当的措施来解决问题并完成传输作业。它还将在驱动程序的统计数据中标记超时的发生，并将其恢复到健康、原始状态，以便完成当前作业并恢复队列处理。
您标记的事件数量很少，但绝对不必担心。如果问题仍然存在，您可能希望调查 dmesg 和各种日志文件中是否存在其他错误消息。就目前而言，这个简单的数字不足以进行正确的诊断。