Назад | Перейти на главную страницу

e1000e Неожиданный сброс адаптера / обнаружение зависания аппаратного блока

У меня есть сервер Dell 1U с процессором Intel (R) Xeon (R) L5420 @ 2,50 ГГц, 8 ядер под управлением Ubuntu Server Kernel Version 3.13.0-32-generic на x86_64. Он имеет двойные сетевые карты 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

Что может быть причиной этого? Это просто ошибка в программном обеспечении или проблема с оборудованием? Я видел много других, у которых были похожие проблемы, но без реального решения, и это также заставляет меня думать, что это проблема программного обеспечения?

Может, кто-нибудь сможет пролить свет на это для меня?

Хорошо, поэтому после публикации этого вопроса вчера вечером я продолжил некоторое исследование, единственное реальное решение, с которым я столкнулся, похоже, решило проблему.

Отключение TSO, GSO и ​​GRO с помощью ethtool:

ethtool -K eth0 gso off gro off tso off

Согласно сообщению, найденному здесь: http://ehc.ac/p/e1000/bugs/378/

Насколько я понимаю, это приведет или может вызвать снижение производительности.

Я также заметил, что другим решением было отключить управление питанием в активном состоянии.

pcie_aspm=off

Согласно этому сообщению на serverfault: Linux e1000e (сетевой драйвер Intel) проблем много, с чего начать?

Я еще не пробовал это решение. Я попробую и посмотрю, имеет ли это значение, и отправлю свои выводы.

РЕДАКТИРОВАТЬ:

Итак, я попытался отключить управление питанием в активном состоянии, pcie_aspm = off, и это не дало никакого эффекта. Я продолжал замечать ошибки в моем файле журнала.

Это может по-прежнему работать для некоторых, поскольку некоторые из сетевых адаптеров Intel имеют проблемы с засыпанием разных ядер при включенном управлении питанием.

Отключение Enhanced C1 (C1E) в BIOS исправило это для меня.

Не уверен, что низкое энергопотребление C1E мешает драйверу, или что в драйвере есть ошибка, когда процессор находится в этом состоянии.

В любом случае проблема решена.

Отключение только TCP Segmentation Offload (TSO) помогает мне.

ethtool -K eth0 tso off

Примечание: Оно делает не По-видимому, необходимо также отключить общую разгрузку приема (GRO) и общую разгрузку сегментации (GSO), как это рекомендовано различными источниками. Насколько я понял, они реализованы исключительно программно и должны быть безопасными. Не жертвуйте большей производительностью, чем необходимо.

У меня возникла проблема (вызывается та же ошибка ядра, что и у вас, и ошибки SSH в пользовательском пространстве, например "Corrupted MAC on input").

Решение

У меня сработало отключение разгрузки контрольной суммы TCP:

# ethtool -K eth0 tx off rx off

Чистая и долгосрочная интеграция этого с debian-ish / и т.д. / сеть / интерфейсы:

#!/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

источник, вдохновение.

Контекст

  • Дебиан Джесси
  • Ядро 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