e1000e Réinitialiser l'adaptateur inopinément / Blocage du matériel détecté

J'ai un serveur Dell 1U avec un processeur L5420 à 2,50 GHz à processeur Intel Xeon (R), 8 cœurs exécutant la version 3.13.0-32-generic du noyau du serveur Ubuntu sur x86_64. Il possède deux cartes réseau 1000baseT. Je l'ai configuré pour transférer les paquets de eth0 à eth1.

J'ai remarqué que dans mon fichier kern.log, il restait en suspens. Cela arrive souvent. Cela se produit toutes les quelques secondes, puis peut-être que tout ira bien pendant quelques minutes, puis toutes les quelques secondes.

Voici le vidage du fichier journal:

 [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

Voici les informations de ethtool:

Paramètres:

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

Informations sur le conducteur:

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

Qu'est-ce qui peut causer cela? Est-ce juste un bogue dans le logiciel ou un problème matériel? J'ai vu beaucoup d'autres personnes ayant des problèmes similaires mais pas de solution réelle, ce qui m'amène également à penser qu'il s'agit d'un problème logiciel.

Peut-être que quelqu'un peut m'éclairer un peu?

Ok, donc après avoir posé cette question hier soir, j’ai continué à faire des recherches, la seule solution réelle que j’ai trouvée semble avoir réglé le problème.

Désactivation de TSO, GSO et GRO à l'aide d'ethtool:

ethtool -K eth0 gso off gro off tso off

Selon un post trouvé ici: http://ehc.ac/p/e1000/bugs/378/

D'après ce que je comprends, cela peut ou peut entraîner une réduction des performances.

J'ai également remarqué qu'une autre solution consistait à désactiver la gestion de l'alimentation active.

pcie_aspm=off

Selon ce message sur serverfault: Linux e1000e (pilote de réseau Intel) à gogo, par où commencer?

Je n'ai pas encore essayé cette solution. Je vais essayer et voir si cela fait une différence et publier mes conclusions.

MODIFIER:

Ok, alors j'ai essayé de désactiver la gestion de l'alimentation active, pcie_aspm = off et cela n'a eu aucun effet. J'ai continué à remarquer des erreurs dans mon fichier journal.

Cela peut encore fonctionner pour certains utilisateurs, car certains d'entre eux ont des problèmes avec différents noyaux: s'endormir lorsque la gestion de l'alimentation est activée.

La désactivation de Enhanced C1 (C1E) dans le BIOS a corrigé le problème.

Vous ne savez pas si l'état d'alimentation plus faible de C1E perturbe le pilote ou s'il y a un oops dans le pilote lorsque le processeur est dans cet état.

Quoi qu'il en soit, le problème est résolu.

J'ai eu le problème (provoquant la même erreur de noyau que vous et les erreurs SSH de l'espace utilisateur comme " Corrupted MAC on input").

Solution

Ce qui a fonctionné pour moi a été de désactiver le déchargement de la somme de contrôle TCP:

# ethtool -K eth0 tx off rx off

Intégration propre et à long terme de ceci avec 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

source , inspiration .

Le contexte

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

Essayez de mettre à jour votre pilote. Je ne sais pas où il se trouve pour Ubuntu ni quelle version recommandée, mais pour CentOS ou EL 6, il s’agit de:

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