Dear,
I'm new to proxmox and was trying to setup a litte homesever to mess around with.
I bought
- 2x Dell 7070 Micro
- 1x Dell 7050 Micro
The 7050 works without any issue's but the newer 7070 both have the same issue of not showwing up in the network nor PING on the machine it self could reach anything (even in the local network itself). I already tried alot of mentioned fixes and debugs but it is still occuring and i can't seem to figure this out. With a Ethernet to USB it does work but i rather not go that route. I let AI summarize all i did below, i hope this is sufficant info.
I'm a newb in homelabbing but i hope someone could help me out. I did a fresh install now, hopefully someone could guide me in the right direction.
Much thanks in advance!
I'm new to proxmox and was trying to setup a litte homesever to mess around with.
I bought
- 2x Dell 7070 Micro
- 1x Dell 7050 Micro
The 7050 works without any issue's but the newer 7070 both have the same issue of not showwing up in the network nor PING on the machine it self could reach anything (even in the local network itself). I already tried alot of mentioned fixes and debugs but it is still occuring and i can't seem to figure this out. With a Ethernet to USB it does work but i rather not go that route. I let AI summarize all i did below, i hope this is sufficant info.
I'm a newb in homelabbing but i hope someone could help me out. I did a fresh install now, hopefully someone could guide me in the right direction.
Much thanks in advance!
Markdown (GitHub flavored):
# Intel I219-LM (e1000e) periodic link loss on Dell OptiPlex 7070 Micro — Proxmox VE 9.1.5
## Summary
Two Dell OptiPlex 7070 Micro nodes running Proxmox VE 9.1.5 (kernel 6.17.9-1-pve) experience periodic network loss after approximately 1.5–2 hours of uptime. The onboard Intel I219-LM NIC (e1000e driver) silently stops passing traffic — the link stays up at the PHY level, but the host becomes unreachable (ARP/ping fails). No errors appear in dmesg at the time of failure.
A third node (Dell OptiPlex 7050 Micro) with an Intel I219-LM but **different MAC/PHY revision** (MAC: 12 vs MAC: 13) on the same switch, same kernel, same PVE version, is completely stable (43+ hours uptime, no drops).
One affected node (PVE01) has been moved to a USB Ethernet adapter as a workaround and is now stable. The other (PVE02) still uses the onboard NIC and continues to drop.
We have exhausted all commonly suggested software mitigations. Looking for any additional ideas or confirmation that this is a known hardware/driver issue with MAC revision 13.
---
## Environment
### Affected nodes (Dell OptiPlex 7070 Micro)
| Property | PVE01 | PVE02 |
|----------|-------|-------|
| **Model** | Dell OptiPlex 7070 Micro | Dell OptiPlex 7070 Micro |
| **CPU** | Intel Core i5-8500T @ 2.10 GHz | Intel Core i5-8500T @ 2.10 GHz |
| **RAM** | 8 GB DDR4 | 8 GB DDR4 |
| **BIOS** | 1.35.0 (Sep 2025) | 1.35.0 (Sep 2025) |
| **NIC** | Intel I219-LM (Ethernet Connection (7)) | Intel I219-LM (Ethernet Connection (7)) |
| **NIC PCI** | 0000:00:1f.6 | 0000:00:1f.6 |
| **e1000e MAC rev** | 13 | 13 |
| **e1000e PHY rev** | 12 | 12 |
| **e1000e FW** | 0.5-4 | 0.5-4 |
| **Chipset** | Intel Q370 (Cannon Lake PCH) | Intel Q370 (Cannon Lake PCH) |
| **Status** | Workaround: USB NIC (stable) | **Still affected** |
### Unaffected node (Dell OptiPlex 7050 Micro)
| Property | PVE03 |
|----------|-------|
| **Model** | Dell OptiPlex 7050 Micro |
| **CPU** | Intel Core i5-7400 @ 3.00 GHz |
| **NIC** | Intel I219-LM (Ethernet Connection (5)) |
| **e1000e MAC rev** | 12 |
| **e1000e PHY rev** | 12 |
| **Status** | **Stable** — 43+ hours, no drops |
### Software
| Component | Version |
|-----------|---------|
| Proxmox VE | 9.1.5 (pve-manager 9.1.5/80cf92a6) |
| Kernel | 6.17.9-1-pve |
| e1000e driver | 6.17.9-1-pve (in-tree) |
| Switch | TP-Link TL-SG108E (unmanaged gigabit) |
---
## Symptom Description
1. Node boots normally, NIC comes up at 1000 Mbps Full Duplex
2. Network works perfectly for approximately 1.5–2 hours
3. Node becomes unreachable — no ping response, no ARP replies
4. **NIC link remains UP** at PHY level (`Link detected: yes` in ethtool)
5. **No errors in dmesg** at the time of failure — no "Link is Down", no TX hang, no hardware unit hang
6. The bridge (vmbr0) still shows the correct IP and nic0 as forwarding member
7. Only a full power cycle or `ip link set nic0 down && ip link set nic0 up` restores connectivity
This is distinct from the commonly reported "NIC Link is Down / NIC Link is Up" flapping — in our case the link never goes down at the driver level.
---
## Failure Log Example
During one failure, we captured the following from the local console:
```
# ip -br link show
lo UNKNOWN 127.0.0.1/8 ::1/128
nic0 UP
vmbr0 UP 10.25.25.42/24
# bridge link show
2: nic0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master vmbr0 state forwarding priority 32 cost 5
# ping -c 2 10.25.25.1
PING 10.25.25.1 (10.25.25.1) 56(84) bytes of data.
From 10.25.25.42 icmp_seq=1 Destination Host Unreachable
From 10.25.25.42 icmp_seq=2 Destination Host Unreachable
2 packets transmitted, 0 received, +2 errors, 100% packet loss
```
Note: NIC shows UP, bridge shows forwarding, but "Destination Host Unreachable" — this means ARP resolution fails, suggesting the NIC has stopped transmitting/receiving at the MAC level despite the PHY link being up.
---
## Current Configuration (PVE02)
### Kernel command line
```
BOOT_IMAGE=/boot/vmlinuz-6.17.9-1-pve root=/dev/mapper/pve-root ro quiet pcie_aspm=off intel_idle.max_cstate=1 intel_iommu=off
```
### /etc/network/interfaces
```
auto lo
iface lo inet loopback
iface nic0 inet manual
auto vmbr0
iface vmbr0 inet static
address 10.25.25.42/24
gateway 10.25.25.1
bridge-ports nic0
bridge-stp off
bridge-fd 0
post-up /usr/sbin/ethtool -K nic0 tso off gso off gro off tx off sg off
post-up /usr/sbin/ethtool --set-eee nic0 eee off
post-up /usr/sbin/ethtool -s nic0 wol d
```
### /etc/modprobe.d/e1000e.conf
```
options e1000e InterruptThrottleRate=3000
```
### /etc/modprobe.d/blacklist-i915.conf
```
blacklist i915
blacklist i915_compat
blacklist drm_display_helper
blacklist drm_buddy
blacklist cec
blacklist mei_hdcp
blacklist mei_pxp
```
### /etc/modprobe.d/blacklist-lpss.conf
```
blacklist intel_lpss_pci
install intel_lpss_pci /bin/true
blacklist idma64
install idma64 /bin/true
blacklist i2c_designware_platform
blacklist i2c_designware_core
```
### NIC offload status (all disabled)
```
rx-checksumming: off
tx-checksumming: off
scatter-gather: off
tcp-segmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: off
```
### EEE status
```
EEE status: disabled
Tx LPI: 17 (us)
Advertised EEE link modes: 100baseT/Full, 1000baseT/Full
Link partner advertised EEE link modes: Not reported
```
### NIC statistics at boot (all zero — no errors accumulate before failure)
```
rx_errors: 0
tx_errors: 0
collisions: 0
rx_crc_errors: 0
rx_missed_errors: 0
tx_aborted_errors: 0
tx_abort_late_coll: 0
tx_timeout_count: 0
```
---
## PCIe Topology
The NIC sits on the PCH (not behind a PCIe bridge):
```
-[0000:00]-+-00.0 Intel Corporation 8th Gen Core Processor Host Bridge/DRAM Registers
+-02.0 Intel Corporation CoffeeLake-S GT2 [UHD Graphics 630]
+-15.0 Intel Corporation Cannon Lake PCH Serial IO I2C Controller #0
+-16.0 Intel Corporation Cannon Lake PCH HECI Controller
+-16.3 Intel Corporation Cannon Lake PCH AMT - SOL
+-17.0 Intel Corporation Cannon Lake PCH SATA AHCI Controller
+-1b.0-[01]----00.0 SK hynix PC601 NVMe SSD
+-1f.0 Intel Corporation Q370 Chipset LPC/eSPI Controller
+-1f.3 Intel Corporation Cannon Lake PCH cAVS
+-1f.4 Intel Corporation Cannon Lake PCH SMBus Controller
+-1f.5 Intel Corporation Cannon Lake PCH SPI Controller
\-1f.6 Intel Corporation Ethernet Connection (7) I219-LM <-- NIC
```
### lspci -vvv for NIC
```
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (7) I219-LM (rev 10)
Subsystem: Dell Device 092e
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Interrupt: pin D routed to IRQ 122
Region 0: Memory at 91200000 (32-bit, non-prefetchable) [size=128K]
Capabilities: [c8] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Kernel driver in use: e1000e
```
---
## What We Tried (and results)
### 1. BIOS adjustments
- Disabled Intel SpeedStep
- Disabled C-States Control
- Disabled Wake on LAN
- Deep Sleep Control: Disabled
**Result:** No effect. NIC still drops after ~2 hours.
### 2. EEE (Energy Efficient Ethernet) disabled
```bash
ethtool --set-eee nic0 eee off
```
Persistent via post-up in `/etc/network/interfaces`.
**Result:** No effect on its own.
### 3. All hardware offloads disabled
```bash
ethtool -K nic0 tso off gso off gro off tx off sg off
```
TSO is the main suspect per Intel's own kernel patch for I219-LM TX hang issues.
**Result:** No effect. The failure mode is different from the TX hang (no `tx_timeout_count` increase, no "hardware unit hang" in dmesg).
### 4. Kernel parameters: C-states, ASPM, IOMMU
```
pcie_aspm=off intel_idle.max_cstate=1 intel_iommu=off
```
Also tried (no additional effect):
- `processor.max_cstate=1`
- `idle=poll` (CPU at 100% idle, no power saving at all)
- `e1000e.flags=1` (parameter does not exist in kernel driver, silently ignored)
**Result:** No effect.
### 5. InterruptThrottleRate fixed at 3000
```
options e1000e InterruptThrottleRate=3000
```
Default behavior on this hardware is ITR disabled ("turned off" in dmesg). Forced to 3000 ints/sec.
**Result:** No effect.
### 6. Forced link speed (no auto-negotiation)
```bash
ethtool -s nic0 speed 1000 duplex full autoneg off
```
**Result:** No effect.
### 7. Blacklisted i915 GPU driver
The Intel UHD 630 GPU (i915) and e1000e NIC share the same PCIe root complex. GPU driver activity can cause PCIe bus hangs that take down the NIC.
Blacklisted i915 and all related modules.
**Result:** Eliminated GPU-related PCIe hangs, but NIC still drops after ~2 hours via a different mechanism.
### 8. Blocked Intel LPSS I2C/DMA (IRQ #16 storm fix)
The Intel LPSS I2C controller (PCI 00:15.0) and idma64 DMA engine share IRQ #16. After ~2 hours, a spurious interrupt storm would cause the kernel to disable IRQ #16, freezing the system.
Key finding: `i2c_designware_platform` is a **built-in kernel module** — standard `blacklist` has no effect. Fixed by blocking the parent driver `intel_lpss_pci` via `install /bin/true`.
**Result:** Successfully eliminated the IRQ #16 storm / system freeze. But the NIC connectivity loss persists as a **separate issue** — the system stays responsive (console works), only network is dead.
### 9. NIC watchdog (current workaround)
Script that pings the gateway every 15 seconds. After 2 consecutive failures, resets nic0 (`ip link set down/up`).
**Result:** Works as a workaround — restores connectivity within ~40 seconds of failure. Not a fix.
### 10. USB Ethernet adapter (workaround for PVE01)
ASIX AX88179B USB-C to Ethernet adapter, using `cdc_ncm` driver. Bridge moved from nic0 to USB NIC interface.
**Result:** PVE01 has been completely stable since switching to USB NIC. Confirms the issue is specific to the onboard I219-LM.
