Intel I216 NIC 'Hardware Unit Hang' occurred, possibly caused by enormous logfile via SSH. Device was not reset by system automatically.

inoded

New Member
Oct 19, 2026
1
0
1
Western Europe
Hi all,

I'm trying to find the cause and determine appropriate follow-up, after a 'hardware unit hang' this weekend, of my Intel I217-LM onboard network device running Proxmox VE.

I'm not a professional, and just running a home server, please let me know if I didn't provide all the required information.

This issue is a mystery to me, so I wanted to share it, and also ask for some guidance on how to proceed (instead of randomly disabling all kinds of settings and hoping for the best). Internet search shows similar issues with Intel I217, I218 NICs, but I'm not sure how related they are.

Technical details and versions:
Proxmox VE + Linux: pve-manager/9.2.11/f6997e698c7933ea (running kernel: 7.0.14-12-pve)
Linux in VM that produced Docker logs: Ubuntu Server 26.04 LTS, kernel 7.0.0-38
System hardware: ThinkServer TS140, Intel Xeon E3-1245 v3, 32 GB DDR3+ECC, Intel I217-LM (rev4) on motherboard connected with ethernet cable, also 2 Broadcom BCM5721 (rev21) network cards on PCI present but not connected

Event:
I am running Proxmox VE with 3 VMs and 1 LXC. I was working on one of the VMs via an SSH session, and was investigating why a service (Joplin server) in a Docker container wouldn't run. I ran the command `docker logs` expecting a short log, but it kept flooding my screen. Eventually I got the messages:
Code:
2026-09-26T17:19:08: PM2 log: App [app:1] exited with code [1] via signal [SIGINT]
ssh_dispatch_run_fatal: Connection to 192.168.178.101 port 22: message authentication code incorrect

The first line seems to be from the `docker logs` command - I see it says SIGINT but I don't remember pressing Ctrl-C or if I was just waiting out the flooding.

After this, all VMs, the LXC and the Proxmox VE host itself were unreachable (both web interface and SSH). It also did not respond to pings.

Investigation:
Eventually I hooked up a VGA monitor and a keyboard to the server. The console was responsive and I was able to log in. The systemd journal showed the following message, starting around the time my connection broke:
Code:
Oct 16 21:13:08 xbst kernel: e1000e 0000:00:19.0 e_mobo: Detected Hardware Unit Hang:
                               TDH                  <b>
                               TDT                  <32>
                               next_to_use          <32>
                               next_to_clean        <a>
                             buffer_info[next_to_clean]:
                               time_stamp           <154044065>
                               next_to_watch        <b>
                               jiffies              <154044800>
                               next_to_watch.status <0>
                             MAC Status             <80083>
                             PHY Status             <796d>
                             PHY 1000BASE-T Status  <3800>
                             PHY Extended Status    <3000>
                             PCI Status             <10>
This message is the first one of many - it repeats every 2 seconds exactly. After this one, the values stay the same except for:
- jiffies: which seem to change every message
- PHY 1000BASE-T Status: which is "3800" every time but once is "3803"
The journalctl dump, filtered with only messages containing 'e1000e', is attached to this post. I also checked for any other messages before this (i.e. between 21:00 and 21:13, the start of the errors); but there are only 3 messages from CRON at 21:05 so I didn't include those.

Interestingly, the device still reported UP, carrier 1, full duplex, link detected, and 1000Mb/s.

Temporary fix:
I was able to re-start the network device alone, without rebooting the entire server, by doing
ip link set e_mobo down and ip link set e_mobo up
Everything is working again since this.

Additional investigation:
(1) I looked into the network device settings, and network device statistics, but I am not an expert on this at all.
Code:
tx_errors:                0
tx_timeout_count:         0
tx_restart_queue:       256
rx_missed_errors:      8586
tx_flow_control_xoff: 68482
tx_dropped:               0
tx_dma_failed:            0

TCP segmentation offload: on
Generic segmentation offload: on
Generic receive offload: on
RX/TX flow control: on
EEE: enabled - active

driver: e1000e
version: 7.0.14-12-pve
firmware-version: 0.13-4
expansion-rom-version: 
bus-info: 0000:00:19.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes

(2) I was suspecting the inadvertent displaying of the enormous Docker log file via SSH, but only because it happened at exactly the same time and the server is really not that busy. I inspected the log file (JSON) in the Docker container. `ls` and `du` show it to be 878 MiB / 920 MB; `wc -l` shows it to be 5.7 million lines. No log-rotation was configured, and the container was constantly producing error messages.

Mitigation:
  1. Disabled the network device setting EEE (read this somewhere and doesn't seem to affect the performance).
  2. (Work in progress) I'm creating a Bash script on the crontab every x minutes, that checks the dmesg tail for this error; if it is there, then it will reset the network device in the way described above and notify me once it can reach the internet again.
  3. (ongoing process to investage and mitigate)
My questions:
  1. Should I create a bug report with Proxmox? And/or elsewhere?
  2. Is the Docker log a viable cause? I haven't tried to reproduce the problem yet, I could do this.
  3. Is it likely that this is caused by the Proxmox virtual network interface <-> hardware network interface, and wouldn't have happened without virtualisation?
  4. Is there a reason the system doesn't reset the network device itself?
 

Attachments