адаптер Сброса e1000e неожиданно / Обнаруженный Аппаратный блок Зависает
У меня есть Сервер Dell 1U с Intel(R) Xeon(R) CPU L5420 2.50 ГГц, 8 ядер рабочая Версия Ядра Сервера Ubuntu, 3.13.0-32-универсальная на 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 -K eth0 gso off gro off tso off
Согласно найденному здесь сообщению: http://ehc.ac/p/e1000/bugs/378/
Насколько я понимаю, это приведет или может привести к снижению производительности.
Я также заметил, что другим решением было отключение управления питанием в активном состоянии
pcie_aspm=off
Согласно этому посту о неисправности сервера: Проблемы с Linux e1000e (сетевой драйвер Intel), с чего мне начать?
Я еще не пробовал это решение. Я попробую и посмотрю, что из этого выйдет, и верну свои выводы.
EDIT:
Хорошо, я попробовал отключить Active State Power Management, pcie_aspm=off, и это не дало никакого эффекта. Я продолжал замечать ошибки в своем лог-файле.
Для некоторых это все еще может сработать, так как у некоторых представителей Intel nics есть проблемы с различными ядрами, которые засыпают, когда включено управление питанием.
Попробуйте обновить драйвер. Не знаю, где это для Ubuntu или какая версия рекомендуется, но для CentOS или EL 6 это:
У меня возникла проблема (вызывается та же ошибка ядра, что и у вас, и ошибки SSH в пользовательском пространстве, например « Поврежденный MAC на
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://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
источник , вдохновение .
Контекст
- Debian Jessie
- Ядро 4.7.0-0. bpo.1-amd64
- lspci
00: 19.0 Контроллер Ethernet: Intel Corporation Ethernet Connection I218-V (версия 04)
Отключение расширенного C1E (C1E) в BIOS исправило это для меня.
Не уверен, что состояние пониженной мощности C1E влияет на драйвер, или что в драйвере есть опсы, когда процессор находится в этом состоянии.
В любом случае, проблема решена.
Отключение только TCP Segmentation Offload (TSO) помогает мне.
ethtool -K eth0 tso off
Примечание: Похоже, что нет необходимости также отключать общую разгрузку приема (GRO) и общую разгрузку сегментации (GSO), как это рекомендуется различными источниками. Насколько я понял, они реализованы чисто программно и должны быть безопасными. Не жертвуйте большей производительностью, чем необходимо.