Network transmit queue watchdog or hardware hang · Linux Fix Lab

Symptoms & scope

Network traffic stops until the driver resets or the system restarts.
The kernel reports NETDEV WATCHDOG or an e1000e hardware unit hang.

Relevant environment

Ethernet or other netdev drivers with transmit queues; the additional hardware-hang signature is specific to Intel e1000e.

Recognizable messages (synthetic examples)

kernel: NETDEV WATCHDOG: CPU: 3: transmit queue 0 timed out 5260 ms

Retain adjacent interface and driver details; wording differs by kernel, and the signal does not identify one hardware cause.

e1000e 0000:00:19.0 enp0s25: Detected Hardware Unit Hang:

Read the following ring/PHY/PCI details and any device-specific guidance before selecting a workaround.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

The transmit queue has not progressed within its watchdog window; driver, device, firmware, interrupt handling or lower-link trouble may be involved.
An inappropriate driver-specific tuning option or kernel regression can contribute, but the watchdog alone cannot select a workaround.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Replace IFACE with the interface named by the watchdog. Read driver, bus identity and reported firmware version without resetting the NIC.

ethtool -i IFACE

Interpret the result: Use the actual driver name when consulting fixes. A blank firmware-version field does not by itself mean firmware is missing; retain the PCI identity and running kernel version.

Check 2

Read the driver events around the stall; journal privileges may be required. Preserve the watchdog line, preceding link/PCI errors and any driver-specific recovery guidance.

journalctl -k -b --no-pager -n 400

Interpret the result: A watchdog is a transmit-progress failure, distinct from DNS timeout. e1000e hardware-unit-hang details are useful for a driver report; repeated resets do not prove the NIC is physically defective.

Evidence-guided next steps

Compare a supported kernel and driver

If the hang began after a kernel update, boot an already installed previous supported kernel and compare the same NIC, link and bounded workload. For a persistent fault, check the distribution’s documented driver/firmware fixes with the exact device ID and retained hang details.

Precautions: Keep both boot choices and local access. Avoid downloading an unrelated out-of-tree driver or unloading the only remote-access NIC during an active session.

Recovery / rollback: Return to the previous working kernel through the boot menu and restore the recorded driver options if a proposed update worsens access.

Did this solution help you?

Share this solution #

Undo a confirmed driver-specific tuning issue

If e1000e is bound and a saved module override sets RxIntDelay above its documented default of zero, remove only that override and compare after a controlled restart. Alternatively, use a workaround named by this exact driver/hardware’s log or official documentation, one setting at a time.

Precautions: This receive-delay caveat applies to e1000e, not every NIC. Record existing options and keep a recovery console; blanket offload or power-management disablement can hide evidence and reduce performance.

Recovery / rollback: Restore the saved single override if the comparison has no benefit or causes new trouble, and return to the kernel that preserved connectivity.