Re: [Intel-wired-lan] e1000e: Report link down after "Detected Hardware Unit Hang" ?

["Ruinskiy, Dima" <dima.ruinskiy@intel.com>]

On 15/06/2026 23:36, Helge Deller wrote:
> On 6/15/26 18:41, Andrew Lunn wrote:
>> On Sun, Jun 14, 2026 at 11:48:08PM +0200, Helge Deller wrote:
>>> I'm regularily facing the known "eno1: Detected Hardware Unit Hang:"
>>> with my on-board intel e1000e NIC hardware.
>>> Since none of he various tips on the internet helped, I had the idea
>>> to setup a master/slave bond networking to fail over to another NIC when
>>> the Intel chip hangs.
>>>
>>> Sadly this doesn't work as intended, because the link of the intel NIC
>>> isn't reported "down", so the failover never happens, unless I manually
>>> start "ifconfig eno1 down".
>>>
>>> My question: Shouldn't the intel NIC ideally report Link Down if we know
>>> it hangs? That way a fail-over should at least happen, right?
>>>
>>> Below is a completely untested patch.
>>> Does it make sense that I try to test and/or develop such a patch, or
>>> are there things I miss?
>>
>> If the interface is dead, then setting the carrier down makes a lot of
>> sense. 
> 
> That's what I think as well. Thanks for confirming.
> 
>> One question i have is, what do you need to do to recover the
>> hardware? Will it correctly set the carrier up when you do the
>> recovery?
> 
> The only way I could recover was to plug the network cable and re-insert 
> it.
> I have not tested bringing the NIC down.
> But in both cases the driver will need to re-detect the media & link
> 
>> Also, just looking at your proposed change, it is not clear to me why
>> such an assignment will result in carrier down. It would be good to
>> explain it in the commit message.
> 
> Sure. The patch I attached was completely untested and just based on
> the analysis of the flow and how to make the Link possibly report to be 
> down.
> Maybe someone knowledgeable of the driver has a better suggestion how to
> report the link down situation in a clean way?
> 
> Helge
This does not seem like the right direction to me.

The "Detected Hardware Unit Hang" print does not indicate that the 
interface is dead, but that the transmitter is stalled.

This can be due to an unusually high load, or a HW fault / race 
condition with another component, etc.

When a hang is detected, the transmitter is stopped with 
netif_stop_queue() and eventually ndo_tx_timeout triggers a full reset 
to the device, which in many cases recovers it from the hang.

If the hang is persistent, we try to understand the cause and debug it. 
Permanently marking the device as 'down' because it hung once is not 
going to be the optimal solution.