🚨 Linux Error Guide: 'NIC Link is Down' Adapter Resets and Carrier Loss

Exact Error Message

When a network interface flaps or a driver recovers a wedged adapter, the kernel logs a recognizable burst of messages. You will typically see something like this in dmesg or the kernel journal:

[12345.678] e1000e 0000:00:1f.6 eno1: NIC Link is Down
[12350.112] e1000e 0000:00:1f.6 eno1: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
[12999.001] ixgbe 0000:03:00.0 enp3s0: Reset adapter
[13000.221] ixgbe 0000:03:00.0 enp3s0: Detected Tx Unit Hang
[13000.222]   Tx Queue             <0>
[13000.222]   TDH, TDT             <a1>, <c4>
[13000.223]   next_to_use          <c4>
[13000.223]   next_to_clean        <a1>

NetworkManager and systemd will often record the same event from userspace:

Jun 24 09:14:50 host NetworkManager[812]: <info> [..] device (eno1): carrier: link disconnected (calling deferred action)
Jun 24 09:14:52 host kernel: eno1: Link is Down

The driver name (e1000e, ixgbe, igb, tg3, r8169, etc.) and the interface name (eno1, enp3s0) vary by hardware, but the pattern of NIC Link is Down / Link is Up pairs, Reset adapter, and Detected Tx Unit Hang is consistent.

What the Error Means

These messages describe the physical and driver state of an Ethernet adapter.

NIC Link is Down / Link is Up reflects the carrier state: whether the PHY (physical layer chip) detects a valid link partner on the other end of the cable. When the carrier is lost, the kernel marks the interface NO-CARRIER and stops queuing packets. A clean Link is Up 1000 Mbps Full Duplex line tells you the negotiated speed and duplex once link is re-established.

Reset adapter and Detected Tx Unit Hang are more serious. They mean the driver’s transmit ring has stalled: the hardware’s transmit descriptor head (TDH) is not advancing toward the tail (TDT) that the driver wrote. The watchdog fires, the driver assumes the chip is wedged, and it performs a full adapter reset to recover. Each reset bounces the link, which is why you frequently see Link is Down/Link is Up surrounding a Reset adapter.

A single flap during a switch reboot is harmless. Repeated flaps, or Tx Unit Hang resets under load, indicate a real hardware, driver, or configuration fault that will cause packet loss and connection drops.

Common Causes

• Bad or marginal cabling / connectors — a damaged Cat5e/Cat6 cable, a loose RJ45, or a dirty/seated-wrong SFP+ module causes intermittent carrier loss.
• Autonegotiation or speed/duplex mismatch — one side forced to a fixed speed/duplex while the other autonegotiates produces a half/full duplex mismatch, late collisions, and CRC errors.
• Faulty or incompatible SFP/SFP+ optics or DAC cables — unsupported transceivers can link-flap or refuse to come up at all.
• Driver / firmware bugs — older e1000e, ixgbe, and r8169 versions are known for spurious Tx Unit Hang resets.
• Aggressive power management — EEE (Energy Efficient Ethernet, 802.3az) and PCIe ASPM can drop link during idle, especially on consumer NICs.
• Tx ring buffer exhaustion / DMA stalls — under heavy load or with offloads misbehaving, the transmit ring backs up and the watchdog triggers.
• Switch-side issues — STP port transitions, flapping switch ports, or a failing switch ASIC.

How to Reproduce the Error

You usually do not reproduce this on purpose, but you can confirm the carrier mechanism and observe the log entries deliberately. Administratively bouncing the link generates the same Link is Down/Link is Up pair:

ip link set eno1 down
ip link set eno1 up

Physically unplugging and replugging the cable (or pulling the SFP) is the cleanest way to confirm carrier detection. To stress the transmit path and surface a marginal Tx Unit Hang, sustained throughput with a tool like iperf3 over the suspect interface will reveal resets within minutes if the fault is load-related. Always watch the log while you test:

dmesg -Tw | grep -i 'link is\|reset\|hang'

Diagnostic Commands

All of the following are read-only and safe to run on a production host.

Watch the kernel ring buffer for the relevant events with human-readable timestamps:

dmesg -T | grep -i 'link is\|reset\|hang'
journalctl -k -g 'Link is'

Check the interface state and statistics:

ip link show eno1
ip -s link show eno1

2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT
    RX:  bytes packets errors dropped  missed   mcast
   88123456  120943      14       0      14       0
    TX:  bytes packets errors dropped carrier collsns
   45221190   98211       9       0       9       0

Inspect the live carrier and operstate directly from sysfs. Note the distinction: carrier is the raw PHY link bit (1 = link present), while operstate is the kernel’s higher-level view (up, down, dormant):

cat /sys/class/net/eno1/carrier
cat /sys/class/net/eno1/operstate

1
up

Confirm negotiated speed and duplex, and whether autoneg is on:

ethtool eno1

Settings for eno1:
        Supported link modes:   1000baseT/Full
        Auto-negotiation: on
        Speed: 100Mb/s
        Duplex: Half
        Link detected: yes

A 100Mb/s Half result on a gigabit link is a red flag for a duplex mismatch. Pull driver-level error counters, which are the most useful signal for resets and hangs:

ethtool -S eno1

     rx_errors: 0
     tx_errors: 9
     tx_timeout_count: 3
     tx_restart_queue: 41
     rx_crc_errors: 1872
     rx_missed_errors: 14
     rx_no_buffer_count: 27
     rx_fifo_errors: 14
     tx_aborted_errors: 9

Rising tx_timeout_count confirms the watchdog is firing; high rx_crc_errors points at cabling or duplex mismatch; rx_no_buffer_count / rx_missed_errors suggest ring buffer pressure. Finally, check the ring sizes and the driver/firmware version:

ethtool -g eno1
ethtool -i eno1

Ring parameters for eno1:
Pre-set maximums:
RX:             4096
TX:             4096
Current hardware settings:
RX:             256
TX:             256

driver: e1000e
version: 3.2.6-k
firmware-version: 0.13-4

Step-by-Step Resolution

1. Rule out the physical layer first. Replace the patch cable with a known-good one, reseat both ends, and swap the switch port. For fiber, reseat or replace the SFP/SFP+ module and clean the connectors. A large or growing rx_crc_errors count almost always means a Layer 1 problem.

2. Fix any duplex/speed mismatch. If ethtool shows 100Mb/s Half where you expect gigabit full duplex, ensure both the NIC and the switch port use the same setting. The safest fix is autonegotiation on both ends. As an example of forcing a known-good config (apply only when the switch matches):

ethtool -s eno1 autoneg on speed 1000 duplex full

3. Address Tx Unit Hangs and ring pressure. If tx_timeout_count is climbing and rx_no_buffer_count is high, increasing the ring buffers can absorb bursts. With pre-set maximums of 4096 and current values of 256, you might raise them (this briefly resets the link):

ethtool -G eno1 rx 1024 tx 1024

4. Disable aggressive power management. EEE and ASPM are common culprits for idle-time flaps on e1000e and r8169. As examples:

ethtool --set-eee eno1 eee off
# r8169 frequently needs ASPM disabled via kernel param: pcie_aspm=off

5. Update driver and firmware. Many Tx Unit Hang resets are fixed in newer kernels and NIC firmware. Compare ethtool -i output against vendor errata and update if you are running an old version string.

6. Make any working fix persistent. Wire your ethtool settings into a NetworkManager dispatcher script, a systemd unit, or udev rules so they survive reboots and link events.

Prevention and Best Practices

• Prefer autonegotiation everywhere. Modern gigabit and faster links require it; manual forcing is the leading cause of duplex mismatches.
• Use certified cabling and vendor-approved optics. Cheap DACs and unbranded SFPs are a frequent source of flaps.
• Monitor counters proactively. Scrape ethtool -S for tx_timeout_count, rx_crc_errors, and carrier changes, and alert on rising trends before users notice drops.
• Keep kernels and NIC firmware current on a tested cadence to pick up driver fixes for Tx Unit Hang and reset bugs.
• Disable EEE/ASPM on hosts that must keep links rock-solid, such as routers, firewalls, and storage nodes.
• Bond interfaces (LACP or active-backup) so a single flapping NIC does not drop connectivity.

For more hardening and triage workflows, see the Linux admins category on the site.

Related Errors

• e1000e ... Detected Hardware Unit Hang — a closely related receive/transmit hang variant.
• bnxt_en ... NIC Link is Down and mlx5_core ... Link down — same carrier-loss class on Broadcom and Mellanox cards.
• r8169 ... rtl_rx_close cond... timed out — Realtek-specific reset/timeout chatter.
• device eno1 entered promiscuous mode followed by flaps — often a bridge or capture tool interacting with link state.

Frequently Asked Questions

Q: What is the difference between carrier and operstate in sysfs? A: carrier is the raw PHY signal: 1 means the hardware sees a link partner, 0 means no cable/signal. operstate is the kernel’s operational verdict (up, down, dormant) which also accounts for the interface being administratively up and protocols being ready. You can have carrier 1 but operstate down if the interface is administratively down.

Q: Why does Reset adapter always seem to bounce my link? A: Recovering a wedged adapter requires reinitializing the MAC and PHY, which momentarily drops carrier. That is why a Reset adapter is almost always sandwiched between Link is Down and Link is Up lines. The reset itself is the symptom, not the root cause.

Q: How do I know if I have a duplex mismatch? A: Run ethtool <iface>. If one side reports Half duplex on a link that should be full duplex, and you see rising rx_crc_errors, late collisions, or tx_aborted_errors in ethtool -S, you have a mismatch. Set both ends to autonegotiate.

Q: Can power management really cause link flaps? A: Yes. Energy Efficient Ethernet (802.3az) and PCIe ASPM put the link or controller into low-power states during idle, and buggy implementations fail to wake cleanly, producing periodic NIC Link is Down/Up events. Disabling EEE (ethtool --set-eee ... eee off) and ASPM is a common fix on e1000e and r8169 hardware.

Q: Is increasing the ring buffer with ethtool -G safe in production? A: It is a low-risk change, but it briefly resets the interface and drops the link, so schedule it. Only raise rings if you see rx_no_buffer_count, rx_missed_errors, or tx_restart_queue climbing under load; oversized rings can add latency without fixing a true hardware fault.