¿Cuál es el significado del valor 'tx_timeouts' de ethtool?

Utilizando ethtool (Versión 6) da, por ejemplo, la siguiente salida:

$ ethtool -S eth0
NIC statistics:
     early_rx: 0
     tx_buf_mapped: 0
     tx_timeouts: 142
     rx_lost_in_ring: 0

¿Cuál es el significado del valor para tx_timeouts? ¿Qué cuenta el número 142?

Desde Controladores de dispositivos Linux de O'reilly Sección 'Tiempos de espera de transmisión':

La mayoría de los controladores que tratan con hardware real tienen que estar preparados para eso   Hardware para no responder de vez en cuando. Las interfaces pueden olvidar lo que   Lo están haciendo, o el sistema puede perder una interrupción. Este tipo de   El problema es común con algunos dispositivos diseñados para ejecutarse en personal   ordenadores.

Muchos controladores manejan este problema configurando temporizadores; si la operacion   no se ha completado en el momento en que expira el temporizador, algo está mal.   El sistema de red, como sucede, es esencialmente un sistema complicado.   Montaje de máquinas estatales controladas por una masa de temporizadores. Como tal,   El código de red está en una buena posición para detectar la transmisión.   los tiempos de espera de forma automática.

Por lo tanto, los controladores de red no deben preocuparse por detectar tales problemas   sí mismos. En su lugar, solo necesitan establecer un tiempo de espera, que va   en el campo watchdog_timeo de la estructura net_device. Este periodo,   que está en jiffies, debe ser lo suficientemente largo como para dar cuenta de lo normal   retrasos en la transmisión (como las colisiones causadas por la congestión en el   medios de red).

Si la hora actual del sistema supera la hora de trans_start del dispositivo en   menos el período de tiempo de espera, la capa de red eventualmente llamará   El método tx_timeout del conductor. El trabajo de ese método es hacer lo que sea.   necesario para solucionar el problema y garantizar la correcta finalización de   Cualquier transmisión que ya estuviera en progreso. Es importante, en   En particular, que el conductor no pierda la pista de cualquier búfer de socket que   Se le ha confiado el código de red.

Así que parece que la estructura tx_timeout está ahí para asegurarse de que el sistema no se bloquee cuando algo falla en el hardware. No tengo idea de por qué el suyo no es 0, pero podría tener algo que ver con el controlador NIC.

tx_timeout es, estrictamente hablando, la cantidad de veces que se ha llamado a la rutina del controlador del dispositivo para manejar los tiempos de espera.

Se produce un tiempo de espera de transmisión cada vez que el hardware de transmisión no responde. Esto ocurre en la vida real porque, por ejemplo, se pierde una interrupción, o porque su NIC tiene forgotten lo que estaba haciendo De ninguna manera es una ocurrencia rara, especialmente en las PC.

Los controladores de dispositivos están diseñados para hacer frente a estas incidencias mediante un temporizador: esto marca el tiempo dentro del cual debe ocurrir la transmisión; Si no lo hace, el control se transfiere a la tx_timeout rutina que tomará las acciones apropiadas para resolver el problema y completar el trabajo de transmisión. También marcará la ocurrencia del tiempo de espera en las estadísticas del controlador y lo restaurará a un estado sano y prístino, de modo que se pueda llevar a cabo tanto la finalización del trabajo actual como la reanudación del procesamiento de la cola.

El número de eventos que ha marcado es pequeño, y de ninguna manera es preocupante. Si el problema persiste, es posible que desee investigar la presencia de mensajes de error adicionales en dmesg y los diversos archivos de registro. En su forma actual, este simple número no es suficiente para un diagnóstico adecuado.