e1000eアダプターの予期しないリセット/ハードウェアユニットのハングの検出

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ネットワーキングドライバー）の問題はたくさんありますが、どこから始めればいいのでしょうか？

私はまだこの解決策を試していません。私はそれを試して、それが違いを生むかどうかを確認し、私の調査結果をポストバックします。

編集：

[OK]ので、アクティブ状態の電源管理pcie_aspm = offをオフにしてみましたが、これは何の効果もありませんでした。ログファイルのエラーに気づき続けました。

一部のIntel nicsには、電源管理が有効になっているときに異なるカーネルでスリープ状態になるという問題があるため、これは一部のユーザーでまだ機能する可能性があります。

BIOSでEnhanced C1（C1E）を無効にすると、修正されました。

C1Eの低電力状態がドライバーを混乱させているかどうか、またはプロセッサーがこの状態にあるときにドライバーにエラーがあるかどうかはわかりません。

とにかく、問題は解決しました。

問題が発生しました（あなたと同じカーネルエラーと、「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

ソース、インスピレーション。

コンテキスト

• Debian Jessie
• カーネル4.7.0-0.bpo.1-amd64
• lspci 00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I218-V (rev 04)

ドライバーを更新してください。Ubuntuの場所や推奨バージョンはわかりませんが、CentOSまたはEL 6の場合は次のとおりです。

http://mirror.symnds.com/distributions/elrepo/elrepo/el6/x86_64/RPMS/kmod-e1000e-3.1.0.2-1.el6.elrepo.x86_64.rpm