e1000e Adapter unerwartet zurücksetzen / Hardwareeinheit hängt

Ich habe einen Dell 1U-Server mit Intel (R) Xeon (R) CPU L5420 bei 2,50 GHz und 8 Kernen, auf denen Ubuntu Server Kernel Version 3.13.0-32-generic auf x86_64 ausgeführt wird. Es verfügt über zwei 1000baseT-Netzwerkkarten. Ich habe es eingerichtet, um Pakete von eth0 nach eth1 weiterzuleiten.

Ich habe bemerkt, dass es in meiner kern.log-Datei hängen bleibt und sich dann ausruht. Das passiert oft. Dies geschieht alle paar Sekunden, dann ist es vielleicht für ein paar Minuten in Ordnung und dann wieder alle paar Sekunden.

Hier ist der Speicherauszug der Protokolldatei:

 [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

Hier ist die Info von ethtool:

Die Einstellungen:

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

Fahrerinfo:

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

Was könnte das verursachen? Ist dies nur ein Fehler in der Software oder ein tatsächliches Hardwareproblem? Ich habe viele andere mit ähnlichen Problemen gesehen, aber keine wirkliche Lösung, und dies lässt mich auch glauben, dass es sich um ein Softwareproblem handelt.

Vielleicht kann jemand etwas Licht in diese Sache bringen?

Ok, also nachdem ich diese Frage letzte Nacht gepostet habe, habe ich weiter nachgeforscht. Die einzig wahre Lösung, auf die ich gestoßen bin, scheint sich um das Problem gekümmert zu haben.

TSO, GSO und GRO mit ethtool deaktivieren:

ethtool -K eth0 gso off gro off tso off

Laut einem Beitrag hier zu finden: http://ehc.ac/p/e1000/bugs/378/

Soweit ich weiß, wird oder kann dies zu Leistungseinbußen führen.

Mir ist auch aufgefallen, dass eine andere Lösung darin bestand, die Active-State-Energieverwaltung zu deaktivieren

pcie_aspm=off

Laut diesem Beitrag über Serverfehler: Linux e1000e (Intel Netzwerktreiber) Probleme in Hülle und Fülle, wo fange ich an?

Ich habe diese Lösung noch nicht ausprobiert. Ich werde es versuchen und sehen, ob das einen Unterschied macht und meine Ergebnisse zurückschicken.

BEARBEITEN:

Ok, ich habe versucht, Active-State Power Management auszuschalten, pcie_aspm = off, und dies hatte keine Auswirkungen. Ich bemerkte weiterhin Fehler in meiner Protokolldatei.

Dies funktioniert möglicherweise immer noch, da einige der Intel-Nics Probleme mit verschiedenen Kernels haben, die einschlafen, wenn die Energieverwaltung aktiviert ist.

Durch Deaktivieren von Enhanced C1 (C1E) im BIOS wurde das Problem behoben.

Sie sind sich nicht sicher, ob der niedrigere Energiezustand von C1E mit dem Treiber in Konflikt steht oder ob der Treiber ein Hoppla enthält, wenn sich der Prozessor in diesem Zustand befindet.

Wie auch immer, das Problem ist gelöst.

Ich hatte das Problem (Auslösen des gleichen Kernelfehlers wie Sie und Userspace-SSH-Fehler wie " Corrupted MAC on input").

Lösung

Was für mich funktionierte, war das Deaktivieren des TCP-Prüfsummen-Offloadings:

# ethtool -K eth0 tx off rx off

Saubere und langfristige Integration mit 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

Quelle , Inspiration .

Kontext

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

Versuchen Sie, Ihren Treiber zu aktualisieren. Ich weiß nicht, wo es für Ubuntu ist oder welche Version empfohlen wird, aber für CentOS oder EL 6 ist es:

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