On 12/07/2026 14:56, Viktor Donner wrote:
Hello,
I am reporting an issue involving the e1000e driver, Intel I219-LM,
network offload, and Intel AMT/ME remote-management state.
Environment:
- Host: Proxmox VE 9.2.4
- Kernel: 7.0.14-4-pve
- NIC: Intel I219-LM
- Driver: e1000e
- Driver version: 7.0.14-4-pve
- Firmware version: 0.4-4
- PCI address: 0000:00:1f.6
- Link: 1000 Mb/s, full duplex
- Host bridge: Linux bridge vmbr0
- Guest traffic: VirtIO VM network interface
Observed behavior:
When running a speed test inside a VM, at approximately 600+ Mbit/s
download traffic, the Proxmox host becomes completely unreachable over
the network:
- no ICMP response
- no SSH access
- no Proxmox web interface
- the physical/vPro console initially remains available
- a normal reboot may hang, requiring an AMT hardware reset/power cycle
The NIC still appears administratively UP and LOWER_UP, and the bridge
configuration and IP address remain present.
Hi Viktor,
I'm not very familiar with Proxmox, so just to make sure I understand
the setup - 7.0.14-4-pve is the host kernel, and the e1000e drives the
I219-LM device on the host, whereas the VM is running VirtIO which is
bridged over vmbr0 to the host?
And eventually after the speed test has been running for some time - the
host NIC hangs with all the above symptoms?
Relevant boot messages while MeshCommander / AMT remote management was
active:
e1000e 0000:00:1f.6 (uninitialized): Reset blocked by ME
e1000e 0000:00:1f.6: PHY reset is blocked due to SOL/IDER session.
> > After completely closing MeshCommander and rebooting, these messages
disappeared. TSO/GSO/GRO were enabled again, and repeated speed tests
did not reproduce the host lockup.
So the issue only occurs if MeshCommander is active at the same time
that the speed test is running in the VM, and TSO/GSO are enabled?
Please advise:
1. Is this a known e1000e/I219-LM issue?
We get various reports of I219-LM hangs related to TSO/GSO from time to
time (GRO specifically is not supported by I219). Not sure whether I
have seen one mentioning the specific scenario you are running.
2. Is blocking PHY reset during SOL/IDER expected to prevent recovery
from a TX/RX hang?
This depends on the cause of the hang. If it is the part of the data
path that is specific to the host - then it should not prevent recovery,
but if it is somewhere in the PHY - it might.
3. Are there recommended driver parameters or mitigations other than
disabling TSO/GSO/GRO?
4. What additional traces or register dumps would be useful?
A dmesg dump from the host at the time of the failure may help. Were the
above two messages the only ones from e1000e? Normally, if there is a Tx
hang in the data path of the e1000e driver - it will show in the log
with a dump of some registers.
Hardware:
- Motherboard: Gigabyte Q370M D3H GSM PLUS rev. 1.0
- Primary NIC: Intel I219-LM
- Secondary NIC: Intel I211 using the igb driver, currently not cabled
Regards,
Viktor D
[email protected]
