# e1000e, 2.6.26-28 kernels, possibly NIC firmware destruction

## redgsturbo

I keep getting "eth0 Detected Tx Unit Hang" dmesg errors for the e1000e driver and its dropping the connection... how do I fix this?Last edited by redgsturbo on Wed Dec 03, 2008 7:20 pm; edited 2 times in total

----------

## redgsturbo

 *redgsturbo wrote:*   

> I keep getting "eth0 Detected Tx Unit Hang" dmesg errors for the e1000e driver and its dropping the connection... how do I fix this?

 

Right.. so was running 2.6.27 hardened.  Now I tried 2.6.27 gentoo-sources with the same effect.  Switched to a no PIE gcc spec (running gcc 4.2.4-r1 hardened) recompiled kernel, problem still there.  Switched to vanilla gcc and recompiled kernel... post in a few minutes on what happens then.  In addition, now I'm hearing about some possible firmware corruption due to other crashing drivers scribbling the firmware.  This hasn't happened yet (rebooting to ubuntu still works fine) but for this reason I hesitate to run git-sources (though I believe that issue was resolved already).

----------

## redgsturbo

Kernels 2.6.26-r3 and 2.6.28-rc7-git2 exibit the same behaviour.  Anythoughts on what the F is going on?

----------

## redgsturbo

OK... so a completely fresh, completely vanilla, completely standard gentoo build is still giving me this issue.... this really sucks

----------

## ndse2112

This is possibly a known issue. 

Have a look at: http://downloadmirror.intel.com/9180/eng/README.txt

Specifically

82573(V/L/E) TX Unit Hang Messages

----------------------------------

Several adapters with the 82573 chipset display "TX unit hang" messages 

during normal operation with the e1000 driver. The issue appears both with 

TSO enabled and disabled, and is caused by a power management function that 

is enabled in the EEPROM. Early releases of the chipsets to vendors had the 

EEPROM bit that enabled the feature. After the issue was discovered newer 

adapters were released with the feature disabled in the EEPROM. 

If you encounter the problem in an adapter, and the chipset is an 82573-based

one, you can verify that your adapter needs the fix by using ethtool: 

 # ethtool -e eth0

 Offset          Values

 ------          ------

 0x0000          00 12 34 56 fe dc 30 0d 46 f7 f4 00 ff ff ff ff

 0x0010          ff ff ff ff 6b 02 8c 10 d9 15 8c 10 86 80 de 83

                                                           ^^

The value at offset 0x001e (de) has bit 0 unset. This enables the problematic 

power saving feature. In this case, the EEPROM needs to read "df" at offset 

0x001e. 

A one-time EEPROM fix is available as a shell script. This script will verify 

that the adapter is applicable to the fix and if the fix is needed or not. If 

the fix is required, it applies the change to the EEPROM and updates the 

checksum. The user must reboot the system after applying the fix if changes 

were made to the EEPROM.

----------

## redgsturbo

 *ndse2112 wrote:*   

> This is possibly a known issue. 
> 
> Have a look at: http://downloadmirror.intel.com/9180/eng/README.txt
> 
> Specifically
> ...

 

thats actually for the e1000 driver... the e1000e is a different driver

----------

## ndse2112

http://downloadmirror.intel.com/15817/eng/README.txt

Same is true for the e1000e driver...

----------

## redgsturbo

 *ndse2112 wrote:*   

> http://downloadmirror.intel.com/15817/eng/README.txt
> 
> Same is true for the e1000e driver...

 

Even so, I have an 82567LM chipset, which isn't listed in that article.  And while I do have that bit unset, the bitmap is wholey different to begin with.  At  0x001e I have 00, not de.

----------

