Intel(R)Xeon(R)CPU L5420 @ 2.50GHz、x86_64でUbuntu Server Kernelバージョン3.13.0-32-genericを実行する8コアを搭載したDell 1Uサーバーがあります。デュアル1000baseTネットワークカードを備えています。 eth0からeth1にパケットを転送するように設定しています。
私のkern.logファイルで、ファイルがハングし続け、休んでいることに気づきました。これは頻繁に発生しています。これは数秒ごとに発生し、それから数分は問題なく、数秒ごとに戻ります。
ログファイルのダンプは次のとおりです。
[118943.768245] e1000e 0000:00:19.0 eth0: Detected Hardware Unit Hang:
[118943.768245] TDH <45>
[118943.768245] TDT <50>
[118943.768245] next_to_use <50>
[118943.768245] next_to_clean <43>
[118943.768245] buffer_info[next_to_clean]:
[118943.768245] time_stamp <101c48d04>
[118943.768245] next_to_watch <45>
[118943.768245] jiffies <101c4970f>
[118943.768245] next_to_watch.status <0>
[118943.768245] MAC Status <80283>
[118943.768245] PHY Status <792d>
[118943.768245] PHY 1000BASE-T Status <7800>
[118943.768245] PHY Extended Status <3000>
[118943.768245] PCI Status <10>
[118944.780015] e1000e 0000:00:19.0 eth0: Reset adapter unexpectedly
これはethtoolからの情報です:
設定:
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: off (auto)
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
ドライバー情報:
ethtool -i eth0
driver: e1000e
version: 2.3.2-k
firmware-version: 1.4-0
bus-info: 0000:00:19.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no
何が原因でしょうか?これはソフトウェアのバグですか、それとも実際のハードウェアの問題ですか?他にも多くの同様の問題があることを確認しましたが、実際の解決策はありません。これにより、ソフトウェアの問題であると私は信じるようになりますか?
たぶん誰かがこれについて私にいくつかの光を当てることができますか?
わかりましたので、昨夜この質問を投稿した後、私はいくつかの調査を続けました。私が遭遇した唯一の実際の解決策が問題を処理したようです。
Ethtoolを使用してTSO、GSO、GROを無効にする:
ethtool -K eth0 gso off gro off tso off
ここにある投稿によると: http://ehc.ac/p/e1000/bugs/378/
私が理解していることから、これはパフォーマンスの低下を引き起こすか、引き起こす可能性があります。
私はまた、別の解決策がアクティブ状態の電源管理を無効にすることであることに気づきました
pcie_aspm=off
Serverfaultに関するこの投稿によると: Linux e1000e(Intelネットワーキングドライバー)の問題が山積しています。どこから始めればよいですか?
この解決策はまだ試していません。私はそれを試して、それが違いを生むかどうかを確認し、私の発見をポストバックします。
編集:
わかりましたので、Active-State Power Management、pcie_aspm = offをオフにしてみましたが、効果はありませんでした。ログファイルのエラーに引き続き気付きました。
一部のIntel nicには、電源管理が有効になっているときに異なるカーネルでスリープ状態になるという問題があるため、これはまだ機能する場合があります。
BIOSでEnhanced C1(C1E)を無効にすると解決しました。
C1Eの低電力状態がドライバーを混乱させているかどうか、またはプロセッサーがこの状態のときにドライバーに異常があるかどうかは不明です。
とにかく、問題は解決しました。
ドライバを更新してみてください。 Ubuntuの場合はどこか、どのバージョンが推奨されているかはわかりませんが、CentOSまたはEL 6の場合は次のようになります。
私は問題を抱えていました(あなたと同じカーネルエラーと「_Corrupted MAC on input
_」のようなユーザー空間のSSHエラーを引き起こしています)。
私のために働いたのは、TCPチェックサムオフロードを無効にすることでした:
_# ethtool -K eth0 tx off rx off
_
これとdebian-ish/ etc/network/interfacesとのクリーンで長期的な統合:
_#!/bin/bash
#
# Disables TCP offloading on all ifaces
#
# Inspired by: @Michelunik https://serverfault.com/a/422554/62953
RUN=true
case "${IF_NO_TOE,,}" in
no|off|false|disable|disabled)
RUN=false
;;
esac
# Other offloading options that could be disabled (not TCP related):
# sg tso ufo gso gro lro rxvlan txvlan rxhash
# see man ethtool
if [ "$MODE" = start -a "$RUN" = true ]; then
TOE_OPTIONS="rx tx"
for TOE_OPTION in $TOE_OPTIONS; do
/sbin/ethtool --offload "$IFACE" "$TOE_OPTION" off &>/dev/null || true
done
fi
_
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I218-V (rev 04)