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

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

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

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

6 ответов

Решение

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

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

ethtool -K eth0 gso off gro off tso off

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

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

Я также заметил, что другим решением было отключить Active-State Power Management

pcie_aspm=off

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

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

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

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

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

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

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

Во всяком случае, проблема решена.

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

ethtool -K eth0 tso off

Примечание: Это не кажется, необходимо также отключить Generic Receive Offload (GRO) и Generic Сегментация Разгрузка (ГСО), как это рекомендуется различными источниками. Насколько я понял, они реализованы исключительно программно и должны быть безопасными. Не жертвуйте большей производительностью, чем необходимо.

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

Решение

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

# ethtool -K eth0 tx off rx off

Чистая и долгосрочная интеграция этого с debian-ish / etc / network / interfaces:

#!/bin/bash
#
# Disables TCP offloading on all ifaces
#
# Inspired by: @Michelunik https://faultserver.ru/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

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

контекст

  • Debian Джесси
  • Ядро 4.7.0-0.bpo.1-amd64
  • Утилита lspci 00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I218-V (rev 04)

Я только что наткнулся на этот файл readme от Intel:

https://downloadmirror.intel.com/15817/eng/readme.txt

который говорит

82573(V/L/E) Сообщения о зависании передатчика

Некоторые адаптеры с набором микросхем 82573 отображают сообщения «Устройство TX зависает» во время нормальной работы с драйвером e1000e. Проблема возникает как при включенном, так и при отключенном TSO и вызвана функцией управления питанием, включенной в EEPROM. Ранние выпуски чипсетов для производителей имели бит EEPROM, который включал эту функцию. После обнаружения проблемы были выпущены новые адаптеры с отключенной функцией в EEPROM.

Если вы столкнулись с проблемой в адаптере, а чипсет основан на 82573, вы можете убедиться, что ваш адаптер нуждается в исправлении, используя ethtool:

ethtool -e eth0

Значения смещения


0x0000 00 12 34 56 fe dc 30 0d 46 f7 f4 00 ff ff ff ff

0x0010 ff ff ff ff 6b 02 8c 10 d9 15 8c 10 86 80 de 83

Для значения по смещению 0x001e (de) бит 0 не установлен. Это активирует проблемную функцию энергосбережения. В этом случае EEPROM необходимо прочитать «df» по смещению 0x001e.

К сожалению, мои проблемные адаптеры — 82579V и I219-V в двух разных NUC, поэтому неясно, применимо ли ко мне одно и то же исправление.

Попробуйте обновить драйвер. Не знаю, где это для 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

Другие вопросы по тегам