e1000e Ripristinare la scheda inaspettatamente / Rilevato blocco hardware rilevato


36

Ho un server Dell 1U con CPU Intel (R) Xeon (R) L5420 a 2,50 GHz, 8 core con Ubuntu Server Kernel versione 3.13.0-32-generico su x86_64. Ha due schede di rete 1000baseT. L'ho impostato per inoltrare i pacchetti da eth0 a eth1.

Ho notato che nel mio file kern.log continua a rimanere sospeso e poi a riposare. Questo succede spesso. Questo succede ogni pochi secondi, quindi forse andrà bene per alcuni minuti e poi di nuovo ogni pochi secondi.

Ecco il dump del file di registro:

 [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

Ecco le informazioni da ethtool:

Impostazioni:

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

Informazioni sul driver:

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

Che cosa potrebbe causare questo? È solo un bug nel software o un vero problema hardware? Ho visto molti altri problemi simili ma nessuna soluzione reale e questo mi porta anche a credere che sia un problema di software?

Forse qualcuno può far luce su questo per me?


Risposte:


26

Ok, quindi dopo aver postato questa domanda la scorsa notte, ho continuato a fare qualche ricerca, l'unica vera soluzione che ho trovato sembra aver risolto il problema.

Disabilitazione di TSO, GSO e GRO utilizzando ethtool:

ethtool -K eth0 gso off gro off tso off

Secondo un post trovato qui: http://ehc.ac/p/e1000/bugs/378/

Da quello che ho capito questo può o può causare una riduzione delle prestazioni.

Ho anche notato che un'altra soluzione era disabilitare la gestione dell'energia attiva

pcie_aspm=off

Secondo questo post su serverfault: Linux e1000e (driver di rete Intel) a bizzeffe, da dove comincio?

Non ho ancora provato questa soluzione. Lo proverò e vedrò se questo fa la differenza e rispedirò le mie scoperte.

MODIFICARE:

Ok, quindi ho provato a disattivare Active-State Power Management, pcie_aspm = off e questo non ha avuto alcun effetto. Ho continuato a notare errori nel mio file di registro.

Questo potrebbe funzionare ancora per alcuni, poiché alcune delle schede di rete Intel hanno problemi con kernel diversi di addormentarsi quando è abilitata la gestione dell'alimentazione.


2
Grazie! Ho provato la correzione di ethtool e ho risolto il mio problema. (bloccato anche in una sceneggiatura di init)
Peter,

Ciao, sai se l'esecuzione ethtool -K eth0 gso off gro off tso offlascerà cadere la connessione, anche per un breve periodo?
godzillante,

In effetti, disabilitare le opzioni con ethtool ha aiutato, disabilitare le opzioni di gestione dell'alimentazione no
Oleg Gryb,

2
'Secondo un post trovato qui: ehc.ac/p/e1000/bugs/378 ' sopra ora passa a un dominio dominio, il contenuto originale può essere trovato qui: web.archive.org/web/20160205153351/http://ehc. ac: 80 / p / e1000 /…
Mike McCabe,

6

La disabilitazione di Enhanced C1 (C1E) nel BIOS l'ha risolto per me.

Non sono sicuro che lo stato di alimentazione inferiore di C1E stia rovinando il driver o che ci sia un errore nel driver quando il processore si trova in questo stato.

Comunque, problema risolto.


Questa era esattamente la soluzione che ha funzionato per me. Esecuzione di Ubuntu 16.04 LTS su una scheda madre ASRock H170M-ITX / DL. Grazie SteveG. =)
Code

tieni presente che ciò potrebbe aumentare notevolmente il consumo energetico dei server!
Flatron,

0

Ho avuto il problema (innescando lo stesso errore del kernel come te e gli utenti SSH come " Corrupted MAC on input").

Soluzione

Ciò che ha funzionato per me è stato disabilitare l'offload del checksum TCP:

# ethtool -K eth0 tx off rx off

Integrazione pulita e a lungo termine di questo con 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

fonte , ispirazione .

Contesto

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

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.