Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 34 replies
  • Subscribers 2 subscribers
  • Views 19944 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

e1000 resetting

Mast_01
i'm having *QUITE* a bit of an issue with a "new" UTM 9.203 install
the NIC is RESETTING wreaking havoc in comms.
kernel message: 
2014:06:26-15:17:31 utm kernel: [94499.808337] e1000e 0000:00:19.0 eth2: Detected Hardware Unit Hang:

2014:06:26-15:17:31 utm kernel: [94499.808337]   TDH                  

2014:06:26-15:17:31 utm kernel: [94499.808337]   TDT                  

2014:06:26-15:17:31 utm kernel: [94499.808337]   next_to_use          

2014:06:26-15:17:31 utm kernel: [94499.808337]   next_to_clean        

2014:06:26-15:17:31 utm kernel: [94499.808337] buffer_info[next_to_clean]:

2014:06:26-15:17:31 utm kernel: [94499.808337]   time_stamp           

2014:06:26-15:17:31 utm kernel: [94499.808337]   next_to_watch        

2014:06:26-15:17:31 utm kernel: [94499.808337]   jiffies              

2014:06:26-15:17:31 utm kernel: [94499.808337]   next_to_watch.status 

2014:06:26-15:17:31 utm kernel: [94499.808337] MAC Status             

2014:06:26-15:17:31 utm kernel: [94499.808337] PHY Status             

2014:06:26-15:17:31 utm kernel: [94499.808337] PHY 1000BASE-T Status  

2014:06:26-15:17:31 utm kernel: [94499.808337] PHY Extended Status    

2014:06:26-15:17:31 utm kernel: [94499.808337] PCI Status             

2014:06:26-15:17:33 utm kernel: [94501.808357] e1000e 0000:00:19.0 eth2: Detected Hardware Unit Hang:

2014:06:26-15:17:33 utm kernel: [94501.808357]   TDH                  

2014:06:26-15:17:33 utm kernel: [94501.808357]   TDT                  

2014:06:26-15:17:33 utm kernel: [94501.808357]   next_to_use          

2014:06:26-15:17:33 utm kernel: [94501.808357]   next_to_clean        

2014:06:26-15:17:33 utm kernel: [94501.808357] buffer_info[next_to_clean]:

2014:06:26-15:17:33 utm kernel: [94501.808357]   time_stamp           

2014:06:26-15:17:33 utm kernel: [94501.808357]   next_to_watch        

2014:06:26-15:17:33 utm kernel: [94501.808357]   jiffies              

2014:06:26-15:17:33 utm kernel: [94501.808357]   next_to_watch.status 

2014:06:26-15:17:33 utm kernel: [94501.808357] MAC Status             

2014:06:26-15:17:33 utm kernel: [94501.808357] PHY Status             

2014:06:26-15:17:33 utm kernel: [94501.808357] PHY 1000BASE-T Status  

2014:06:26-15:17:33 utm kernel: [94501.808357] PHY Extended Status    

2014:06:26-15:17:33 utm kernel: [94501.808357] PCI Status             

2014:06:26-15:17:35 utm kernel: [94503.808389] e1000e 0000:00:19.0 eth2: Detected Hardware Unit Hang:

2014:06:26-15:17:35 utm kernel: [94503.808389]   TDH                  

2014:06:26-15:17:35 utm kernel: [94503.808389]   TDT                  

2014:06:26-15:17:35 utm kernel: [94503.808389]   next_to_use          

2014:06:26-15:17:35 utm kernel: [94503.808389]   next_to_clean        

2014:06:26-15:17:35 utm kernel: [94503.808389] buffer_info[next_to_clean]:

2014:06:26-15:17:35 utm kernel: [94503.808389]   time_stamp           

2014:06:26-15:17:35 utm kernel: [94503.808389]   next_to_watch        

2014:06:26-15:17:35 utm kernel: [94503.808389]   jiffies              

2014:06:26-15:17:35 utm kernel: [94503.808389]   next_to_watch.status 

2014:06:26-15:17:35 utm kernel: [94503.808389] MAC Status             

2014:06:26-15:17:35 utm kernel: [94503.808389] PHY Status             

2014:06:26-15:17:35 utm kernel: [94503.808389] PHY 1000BASE-T Status  

2014:06:26-15:17:35 utm kernel: [94503.808389] PHY Extended Status    

2014:06:26-15:17:35 utm kernel: [94503.808389] PCI Status             

2014:06:26-15:17:37 utm kernel: [94505.808037] e1000e 0000:00:19.0 eth2: Reset adapter unexpectedly

2014:06:26-15:17:40 utm kernel: [94509.332884] e1000e: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None


i've googled and this seems to be a problem with a lot of linux installations.

so far themost useful: kernel modules - Linux e1000e (Intel networking driver) problems galore, where do I start? - Server Fault
says about running kernel with ASPM disabled, how do i do this?, or am i better off opening a support ticket(which brings me to the issues that this is running on a trial lic on software until the HW SG arrives...)


This thread was automatically locked due to age.
  • 0 in reply to tlamming
    Does every firewall out there crash this way with this chipset? Of course not.. You dont think, with them knowing the work arounds, that they could somehow implement those UNTIL they get better drivers from intel? You honestly think that their hands are that tied? 

    What about every other linux server with this chipset, are they also all crashing?

    This is not a system crash but a nic stall.  You can find this with a google serach.  it is on debian, ubuntu, red hat, etc etc etc.  Yes Sophos hands are tied until Intel fixes this on a wide scale basis.  

     This isn't a Sophos problem but an Intel one.  

    From Intel's driver readme: downloadmirror.intel.com/9180/eng/README.txt

    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.

    Example output of the script:

     # bash fixeep-82573-dspd.sh eth0
     eth0: is a "82573E Gigabit Ethernet Controller"
     This fixup is applicable to your hardware
     executing command: ethtool -E eth0 magic 0x109a8086 offset 0x1e value 0xdf
     Change made. You *MUST* reboot your machine before changes take effect!
    The script can be downloaded at http://e1000.sourceforge.net/files/fixeep-82573-dspd.sh

    Owner:  Emmanuel Technology Consulting

    http://etc-md.com

    Former Sophos SG(Astaro) advocate/researcher/Silver Partner

    PfSense w/Suricata, ntopng, 

    Other addons to follow

  • 0 in reply to William Warren
    This is not a system crash but a nic stall.  You can find this with a google serach.  it is on debian, ubuntu, red hat, etc etc etc.  Yes Sophos hands are tied until Intel fixes this on a wide scale basis.  

     This isn't a Sophos problem but an Intel one.  

    From Intel's driver readme: downloadmirror.intel.com/9180/eng/README.txt

    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.

    Example output of the script:

     # bash fixeep-82573-dspd.sh eth0
     eth0: is a "82573E Gigabit Ethernet Controller"
     This fixup is applicable to your hardware
     executing command: ethtool -E eth0 magic 0x109a8086 offset 0x1e value 0xdf
     Change made. You *MUST* reboot your machine before changes take effect!
    The script can be downloaded at http://e1000.sourceforge.net/files/fixeep-82573-dspd.sh

    I realize its a problem with intel, I just dont see why they cant detect the hardware and disable the power management software on the firewall that evokes the issue. Its just annoying turning it off after every update manually..

    Have you tried the update? Seems like this is the fix right here, unless I'm missing something. Couldnt I just run this script?
  • 0 in reply to tlamming
    I realize its a problem with intel, I just dont see why they cant detect the hardware and disable the power management software on the firewall that evokes the issue. Its just annoying turning it off after every update manually..

    Have you tried the update? Seems like this is the fix right here, unless I'm missing something. Couldnt I just run this script?


    this isn't a firewall problem but a hardware problem from the manufacturer so not there's nothing Sophos can do.  The only officially supported hardware by Sophos is their appliances and they do NOT use the affected Intel chipsets but a different chipset so the SG appliances are unaffected by this issue.

    Owner:  Emmanuel Technology Consulting

    http://etc-md.com

    Former Sophos SG(Astaro) advocate/researcher/Silver Partner

    PfSense w/Suricata, ntopng, 

    Other addons to follow

  • 0
    Thread locked by request.  Nothing more of value can be done to resolve the issue within the forum.
    __________________
    ACE v8/SCA v9.3

    ...still have a v5 install disk in a box somewhere.

    http://xkcd.com
    http://www.tedgoff.com/mb
    http://www.projectcartoon.com/cartoon/1
Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?

Unfiltered HTML