愛する友人と大学
rhelバージョン7.2を使用する仮想マシンがあります。3.10.0-327.el7.x86_64
/var/log/messages
(で)次のメッセージを確認しました。
e1000 0000:02:01.0 eth0: Detected Tx Unit Hang#012 Tx Queue <0>#012 TDH <45>#012 TDT
dmesgでは、私たちは知っています
[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
上記の問題の解決策を検索し、次の修正に関する記事を見ました。
以下を設定し/etc/sysctl.conf
たら、端末を再起動してください。
pcie_aspm=offet ( https://serverfault.com/questions/193114/linux-e1000e-intel-networking-driver-problems-galore-where-do-i-start )
または
ethtool -K eth0 tso off gso off
または
ネットワークアダプタが変更されましたVMNETX3.
など....
だから私たちは正しい解決策について混乱しています。
問題を解決する正しい方法が何であるかを提案してください。
答え1
これは以前のカーネルで既知の問題です(バグジラ 1288237)。修正は最新のkernslaにバックポートされ、次のセキュリティ推奨事項に従って追跡されます。
この問題は、次のアップストリームコミットで発生したと推定されます。 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b4ded8327fea82b53fcec39e0845011246d020f4
3.10.0-514.el7より前のカーネルでは、一部のユーザーは、ethtoolを介して影響を受けるインターフェイスでScatter-Gatherオフロードエンジンを無効にすると、この動作はもはや発生しないことが報告されています。
# ethtool -K <interface> sg off
詳細については、Red Hatのナレッジベースドキュメントをご覧ください。https://access.redhat.com/solutions/2070703
通常、RHELが提供する信頼性の高いABIおよびAPIインターフェースのため、古いソフトウェアを実行しても利点はほとんどなく、実行中のメジャーバージョン(RHEL 7、RHEL&など)の最新のパッチバージョンにアップデートする必要があります。