e1000e Nieoczekiwanie zresetowano adapter / Wykryto zawieszenie jednostki sprzętowej

36

Mam serwer Dell 1U z procesorem Intel (R) Xeon (R) L5420 @ 2,50 GHz, 8 rdzeni z jądrem serwera Ubuntu Server w wersji 3.13.0-32-generic na x86_64. Ma podwójne karty sieciowe 1000baseT. Mam skonfigurowane do przekazywania pakietów z eth0 do eth1.

Zauważyłem, że w moim pliku kern.log nadal się zawiesza, a następnie odpoczywa. To się często zdarza. Dzieje się to co kilka sekund, a potem może będzie dobrze przez kilka minut, a następnie co kilka sekund.

Oto zrzut pliku dziennika:

 [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

Oto informacje z ethtool:

Ustawienia:

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

Informacje o kierowcy:

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

Co może być tego przyczyną? Czy to tylko błąd w oprogramowaniu czy faktyczny problem ze sprzętem? Widziałem wiele innych podobnych problemów, ale nie ma prawdziwego rozwiązania, co prowadzi mnie również do wniosku, że jest to problem z oprogramowaniem?

Może ktoś może rzucić na to trochę światła?

Kyle Coots
źródło
Wygląda na to, że problem jest znany: bugzilla.kernel.org/show_bug.cgi?id=47331
victorpablosceruelo

Odpowiedzi:

26

Ok, więc po tym, jak opublikowałem to pytanie zeszłej nocy, kontynuowałem badania, jedyne prawdziwe rozwiązanie, które znalazłem, rozwiązało problem.

Wyłączanie OSP, GSO i GRO za pomocą ethtool:

ethtool -K eth0 gso off gro off tso off

Zgodnie z postem znalezionym tutaj: http://ehc.ac/p/e1000/bugs/378/

Z tego, co rozumiem, spowoduje lub może spowodować spadek wydajności.

Zauważyłem również, że innym rozwiązaniem było wyłączenie Active-State Power Management

pcie_aspm=off

Zgodnie z tym postem na temat błędu serwera : Linux e1000e (sterownik sieci Intel) ma mnóstwo problemów, od czego zacząć?

Jeszcze nie wypróbowałem tego rozwiązania. Spróbuję i zobaczę, czy to coś zmieni, i prześlę z powrotem moje ustalenia.

EDYTOWAĆ:

Ok, więc próbowałem wyłączyć Active-State Power Management, pcie_aspm = off i to nie miało żadnego efektu. Nadal zauważam błędy w moim pliku dziennika.

Może to nadal działać w przypadku niektórych, ponieważ niektóre karty sieciowe Intel mają problemy z różnymi jądrami zasypiania, gdy zarządzanie energią jest włączone.

Kyle Coots
źródło
2
Dzięki! Próbowałem naprawić ettool i to rozwiązało mój problem. (również utknąłem w skrypcie inicjującym)
Peter
Cześć, czy wiesz, czy uruchomienie ethtool -K eth0 gso off gro off tso offspowoduje zerwanie połączenia, nawet na krótki czas?
godzillante
Rzeczywiście, pomogło wyłączenie opcji za pomocą ethtool, wyłączenie opcji zarządzania energią nie
Oleg Gryb
2
„Zgodnie z postem znalezionym tutaj: ehc.ac/p/e1000/bugs/378 ” powyżej trafia teraz do domenyquatter, oryginalną treść można znaleźć tutaj: web.archive.org/web/20160205153351/http://ehc. ac: 80 / p / e1000 /…
Mike McCabe
6

Wyłączenie Enhanced C1 (C1E) w BIOSie naprawiło to dla mnie.

Nie jestem pewien, czy stan niskiego poboru mocy C1E nie zadziała ze sterownikiem lub czy sterownik przestaje działać, gdy procesor jest w tym stanie.

W każdym razie problem rozwiązany.

SteveG
źródło
To była właśnie poprawka, która zadziałała dla mnie. Uruchamianie Ubuntu 16.04 LTS na płycie głównej ASRock H170M-ITX / DL. Dzięki SteveG. =)
ogony
pamiętaj, że może to znacznie zwiększyć zużycie energii przez serwery!
Flatron,
0

Miałem problem (wyzwalanie tego samego błędu jądra co ty i błędów SSH przestrzeni użytkownika, takich jak „ Corrupted MAC on input”).

Rozwiązanie

Dla mnie zadziałało wyłączenie odciążania sumy kontrolnej TCP:

# ethtool -K eth0 tx off rx off

Czysta i długoterminowa integracja tego z 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

źródło , inspiracja .

Kontekst

  • Debian Jessie
  • Jądro 4.7.0-0.bpo.1-amd64
  • lspci 00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I218-V (rev 04)
Jocelyn delalande
źródło