0

Dear friends and college

we have VM machines with rhel 7.2 version - 3.10.0-327.el7.x86_64

we noticed about the following messages ( from /var/log/messages )

 e1000 0000:02:01.0 eth0: Detected Tx Unit Hang#012  Tx Queue             <0>#012  TDH                  <45>#012  TDT

and from dmesg we get that

[21519947.519425] e1000 0000:02:01.0 eth0: Detected Tx Unit Hang
  Tx Queue             <0>
  TDH                  <45>
  TDT                  <45>
  next_to_use          <26>
  next_to_clean        <45>
buffer_info[next_to_clean]
  time_stamp           <6032d5901>
  next_to_watch        <47>
  jiffies              <6032d75ab>
  next_to_watch.status <0>
[21519949.521583] e1000 0000:02:01.0 eth0: Detected Tx Unit Hang
  Tx Queue             <0>
  TDH                  <45>
  TDT                  <45>
  next_to_use          <26>
  next_to_clean        <45>
buffer_info[next_to_clean]
  time_stamp           <6032d5901>
  next_to_watch        <47>
  jiffies              <6032d7d7e>
  next_to_watch.status <0>
[21519949.811366] e1000 0000:02:01.0 eth0: Reset adapter
[21519949.855081] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None

we try to search the solution for the problem above and we see post about the following fixing

set following in /etc/sysctl.conf, and reboot machine

pcie_aspm=offet ( https://serverfault.com/questions/193114/linux-e1000e-intel-networking-driver-problems-galore-where-do-i-start )

or

ethtool -K eth0 tso off gso off

or

changed the network adapters tor VMNETX3.

and so on ....

so we are confuse about the right solution

please advice what is the right approach for our problem ?

Improve this question

1 Answer 1

Reset to default
2

This is a known issue with older kernels (Bugzilla 1288237). The fix has been backported into newer kernsla and is tracked under the following security advisories:

This problem is believed to have been introduced by the following upstream commit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b4ded8327fea82b53fcec39e0845011246d020f4

With kernels older than 3.10.0-514.el7, some users report that the behavior stops occurring when the Scatter-Gather offload engine on the affected interface was disabled via ethtool:

# ethtool -K <interface> sg off

For more information check out the Knowledgebase article from Red Hat: https://access.redhat.com/solutions/2070703

In general, due to the stable ABI and API interfaces provided by RHEL there is seldom any benefit in running out of date software and one should update to the latest patch release for the major version being run (e.g. RHEL 7, RHEL &).

Improve this answer
3
  • about RHSA-2020:1016 , is it possible to download this errata by yumdownloader ( from redhat subscriber-manager ) ?
    – user436442
    Nov 10, 2020 at 0:08
  • I see it from - unix.stackexchange.com/questions/526659/…
    – user436442
    Nov 10, 2020 at 0:21
  • 1
    @jessica, As of RHEL7 and beyond you no longer even need yumdownloader. The plugin downloadonly was added to the main yum package. Thus, you should be able to run: yum update --downloadonly --downloaddir=/tmp --advisory=RHSA-2020:1016 to retrieve the relevant package. Just make sure that plugins are enabled (they are by default) so that yum can also use the subscription-manager plugin.
    – Brian Redbeard
    Nov 10, 2020 at 0:23

You must log in to answer this question.