Guest User!

You are not Sophos Staff.

[9.302-2][BUG] Adapter E1000E hangs/reset

Hi,

Still getting this issue on this version 9.3.

e1000e 0000:00:19.0 eth0: Detected Hardware Unit Hang:

e1000e 0000:00:19.0 eth0: Reset adapter unexpectedly


This issue has been present since 9.1, when there will be a fix?
  • one workaround is to use a vm...[:)]


    Well I prefer use the command "ethtool -K eth0 tso off" but have to do it in every reboot.
    What I don't understand is that on this post Sophos says that it should be fixed in this update and its not!!! [:@]
  • right..so you can either manually type that command or use a vm on your same hardware and NOT have to type that command.  You still get the same experience just do not have to work around that driver bug every time.

    Owner:  Emmanuel Technology Consulting

    http://etc-md.com

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

    PfSense w/Suricata, ntopng, 

    Other addons to follow

  • Cannot see where Sophos stated this is fixed for all Intel NICs. As long as there's no one from Sophos taking a look and care, nothing will improve. Continue to create support tickets and you may get it solved for you.  And as long as people in this UBB continue to not read what's in here (I posted a workaround above, wtf!) and only complain, the UBB can be closed alltogether.
  • Cannot see where Sophos stated this is fixed for all Intel NICs. As long as there's no one from Sophos taking a look and care, nothing will improve. Continue to create support tickets and you may get it solved for you.  And as long as people in this UBB continue to not read what's in here (I posted a workaround above, wtf!) and only complain, the UBB can be closed alltogether.


    Regarding the issue with my hardware you can read all this entire post and see that they've created a Mantis ID #32902 for this bug and a few days later posted that the mantis was closed, so I presume it was fixed as they said that were planning to release a fix on version 9.304.
  • Regarding the issue with my hardware you can read all this entire post and see that they've created a Mantis ID #32902 for this bug and a few days later posted that the mantis was closed, so I presume it was fixed as they said that were planning to release a fix on version 9.304.


    Yes they created that Mantis ID. Let me explain you what happened: They did nothing with it, just closed it some time later. Why I say that? Well, the Beta bot didn't tell us the ID has been fixed (resolved). And indeed in 9.304 your problem was not addressed. So yes, they decided not to fix it, even though we did all the work for them. [8-)].
  • Yes they created that Mantis ID. Let me explain you what happened: They did nothing with it, just closed it some time later. Why I say that? Well, the Beta bot didn't tell us the ID has been fixed (resolved). And indeed in 9.304 your problem was not addressed. So yes, they decided not to fix it, even though we did all the work for them. [8-)].


    is this particular chip used in the utm machines?  AKAIK it is not and therefore isn't a huge priority for them to address.  Vm my friends vm's..[:)]

    Owner:  Emmanuel Technology Consulting

    http://etc-md.com

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

    PfSense w/Suricata, ntopng, 

    Other addons to follow

  • Nah, using a hypervisor as workaround only creates more fuss, overhead, wastes energy, consumes time and requires additional knowledge to setup. Also it may introduce other problems, as other products aren't bug-free as well ;-). Sounds like shooting a bird with a pumpgun.

    Simply create your own udev rule, replace the vendor & device IDs with the ones of your NIC that triggers the corresponding workaround-script (/lib/udev/nic-disable-[gro|tso|aspm]) as posted above and you're set.
  • Nah, using a hypervisor as workaround only creates more fuss, overhead, wastes energy, consumes time and requires additional knowledge to setup. Also it may introduce other problems, as other products aren't bug-free as well ;-). Sounds like shooting a bird with a pumpgun.

    Simply create your own udev rule, replace the vendor & device IDs with the ones of your NIC that triggers the corresponding workaround-script (/lib/udev/nic-disable-[gro|tso|aspm]) as posted above and you're set.


    I agree with you, creating a VM on top of the hardware could be more problematic (looking at other post when everyone complains about problems on each up2date) and also can causes performance problems!!! [8-)]
  • The reason why this Mantis ID was closed is, that the workaround which is proposed by Intel is included in 9.206 as well as a new Intel driver.

    If it still occurs it might have a different reason.
  • Yes they created that Mantis ID. Let me explain you what happened: They did nothing with it, just closed it some time later. Why I say that? Well, the Beta bot didn't tell us the ID has been fixed (resolved). And indeed in 9.304 your problem was not addressed. So yes, they decided not to fix it, even though we did all the work for them. [8-)].


    btw, it was fixed in a related ID but not updated in betabot