LINUX.ORG.RU
ФорумAdmin

kernel panik при использовании HTB с ядром старше 3.2.83

 ,


0

1

Решил написать на форуме т.к. уже более полугода не могу найти причину падения роутеров.

Предыстория. Как работает. Есть 10 софт роутеров со схожим железом Mb Supermikro CPU Xeon E3-1270 v2 Net Intel 82598EB

Система gentoo Из программ bird(ospf), sshd, cron в общем все HTB для приоретизации трафика (по ip, протоколам) ядро 3.2.10-3.2.83

В таком составе не сбоит (uptime до 200 суток) Трафик до 5Gbps

Теперь что не работает: 1. Стоит обновить ядро как роутер начинает падать в непредсказуемые моменты времени причем падают не все роутеры, вне зависимости от нагрузки на роутер, даже при почти нулевом трафике (4 утра трафик менее 50 Mbit). Пробовал поменять железки местами (т.е. с места где падает А и где не падает Б, при этом все равно kernel panik в месте А из чего сделал вывод что падения зависят от трафика проходящего через роутер, но сам трафик вычислить не удалось) проверял с ядрами 3.8.10, 3.10.17, 3.14.14, 3.14.48, 3.17.7, 3.18.11, 4.0.5, 4.0.9, 4.1.15, 4.4.6, 4.4.26 (при этом система одна и та-же) от драйверов сетевой не зависит только от версии ядра. Потоки сетевой карты по ядрам распределены но на падения никак не повлияло. (падает при распределении потоков по ядрам и без распределения)

2. Если обновить ядро и отключить HTB то роутер не падает ни на одном из выше перечисленных ядер.

В дампе ошибки разные общее одно (NETDEV WATCHDOG: enp1s0f1 (ixgbe): transmit queue x timed out)

пример дампа [24569.847132] WARNING: CPU: 2 PID: 0 at net/sched/sch_generic.c:306 dev_watchdog+0x223/0x230() [24569.847134] NETDEV WATCHDOG: enp1s0f1 (ixgbe): transmit queue 7 timed out [24569.847134] Modules linked in: xt_recent nf_log_ipv4 nf_log_common xt_LOG xt_limit sch_sfq sch_htb act_mirred cls_u32 sch_ingress xt_u32 xt_nat xt_multiport xt_con [24569.847157] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.4.26-gentoo #1 [24569.847158] Hardware name: Supermicro X9SCI/X9SCA/X9SCI/X9SCA, BIOS 2.2 02/20/2015

Собственно вопрос к знатокам работы HTB в ядре что нужно исправить или донастроить чтобы на новых ядрах при использовании HTB ядро не крашилось?

В данный момент перевел роутеры на ядро 3.2.83 работают стабильно, но хотелось бы обновить ядро и сохранить HTB.

Похоже на то, что что-то сломали в ядре после 3.2.83. Я бы поискал по багзиле ядра.

trancefer ★★
()

Я уверен, что в htb нет проблем.

А что с настройками offload ? ethtool -k ethX ?

Я бы начал с отключения lro,gro,tso,sg. Шейперы к ним плохо относятся!

vel ★★★★★
()
Последнее исправление: vel (всего исправлений: 1)
Ответ на: комментарий от vel

Пробовал все варианты включения и отключения lro,gro,tso,sg начиная с ядра 4.4.x с включенным gro некорректно стали работать фильтры для QinQ трафика, поэтому отключил на всех серверах

micaelma
() автор топика
Ответ на: комментарий от Black_Shadow

Похоже но немного не то По ссылке используют SFP+ порты в сетевых картах и проблемы с включенным FlowControl В моем случае FlowControl отключен и сетевые карты CX4

Хотя на одном сервере заменил сетевую карту на 02:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01) 02:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)

Ситуацию это не изменило. Стабильно только с выключенным шейпером или на ядре 3.2.x

micaelma
() автор топика
Ответ на: комментарий от micaelma

А oops всегда начинается с «NETDEV WATCHDOG: enp1s0f1 (ixgbe): transmit queue x timed out» или это следствие других проблем ?

В ядрах выше 3.10 получить тест oops через ramoops или более сложно, но универсально через kdump/kexec.

Ветка 3.2 старая и что там сейчас отличается - хз. Тем более, что ветки 3.0 до 3.4 были с революционными изменениями...

А сколько классов в htb на этом девайсе ? не мульён ? Там ввели пару параметров (htb_hysteresis и htb_rate_est) чтобы понизить нагрузку на CPU при расчете длинных классов.

vel ★★★★★
()
Ответ на: комментарий от vel

Да oops всегда начинается с «NETDEV WATCHDOG: enp1s0f1 (ixgbe): transmit queue x timed out» название сетевой меняется в зависимости от сервера

HTB классов 5-2000. Специально менял количество классов для проверки. Связи с количеством и падениями не заметил.

падало и с 5 классами и с 500 и с 2000

Смотрел историю коммитов в ядре 4.8 для файла https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/net/... там не так много изменений, но моих знаний не хватает чтобы понять где исправлять у меня.

О htb_hysteresis и htb_rate_est видел упоминания в коммитах, но понятной документации по ним не нашел. (a Documentation # grep -r htb_hysteresis a Documentation # pwd /usr/src/linux/Documentation )

Из исходников что они меняют не понятно. :(

micaelma
() автор топика
Ответ на: комментарий от micaelma

Дополнение Есть некоторые отличия как ведет себя сервер перед падением на разных ядрах. Например на ядрах 3.14.x проявлялся эффект исчезновения свободной памяти (доступной для приложений) причем понять кто использует память не удалось.

На ядрах 4.4.x сильно сократилось время между падениями в среднем. В среднем с 3-7 дней до 2 раза в сутки.

Причем проблема точно зависит от проходящего трафика. Есть сервер полностью идентичный с ядром 4.4.6 который не падает .

micaelma
() автор топика
Ответ на: комментарий от micaelma

хм. Последняя фраза совсем все усложняет.

А вот на счет отсутствия памяти - это как раз могло быть первоисточником проблемы. С другой стороны - такую адскую утечку памяти уже давно заметили бы... Ядерную память можно мониторить через /proc/slabinfo

А ядро ванильное или с какими-то патчами? Дополнительные модули есть?

vel ★★★★★
()
Последнее исправление: vel (всего исправлений: 1)

А насколько стабильно и часто воспроизводится проблема? А то можно было бы заюзать git bisect и найти коммит, который всё ломает.

Deleted
()
Ответ на: комментарий от micaelma

На ядрах 4.4.x сильно сократилось время между падениями в среднем. В среднем с 3-7 дней до 2 раза в сутки.

Причем проблема точно зависит от проходящего трафика. Есть сервер полностью идентичный с ядром 4.4.6 который не падает .

Да, это всё усложняет.

А какие там объёмы трафика идут? Может есть возможность куда-нибудь миррорить и складывать все пакеты, чтобы попробовать потом воспроизвести?

Deleted
()
Ответ на: комментарий от Deleted

Обоъемы доволно большие, сам думал по поводу мирор но asl admin # uptime 17:27:27 up 8 days, 19:10, 5 users, load average: 0,30, 0,26, 0,21 asl admin # ifconfig enp1s0f0 enp1s0f0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000 inet6 fe80::230:48ff:fedf:afee prefixlen 64 scopeid 0x20<link> ether 00:30:48:df:af:ee txqueuelen 10000 (Ethernet) RX packets 45480691731 bytes 53522099125680 (48.6 TiB) RX errors 0 dropped 6652 overruns 0 frame 0 TX packets 30898836150 bytes 13968329265862 (12.7 TiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

micaelma
() автор топика
Ответ на: комментарий от micaelma

asl admin # uptime

17:27:27 up 8 days, 19:10, 5 users, load average: 0,30, 0,26, 0,21

asl admin # ifconfig enp1s0f0

enp1s0f0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000

inet6 fe80::230:48ff:fedf:afee prefixlen 64 scopeid 0x20<link>

ether 00:30:48:df:af:ee txqueuelen 10000 (Ethernet)

RX packets 45480691731 bytes 53522099125680 (48.6 TiB)

RX errors 0 dropped 6652 overruns 0 frame 0

TX packets 30898836150 bytes 13968329265862 (12.7 TiB)

TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

micaelma
() автор топика
Ответ на: комментарий от Deleted

Ваш комент подсказал идею Проанализировав частоту падений 6 серверов заметил закономерность. Чаще падают сервера у которых меньше оперативной памяти и больше трафика. т.е. чем больше трафик и меньше памяти тем чаще падения.

Но в том то и дело серер может проработать неделю а потом два раза за сутки отказать. (перезагружаю по ipmi watchdog)

насчет git bisect я правильно понял нужно пересобирать ядро и пробовать на каждом коммите помеченным как плохой и хороший деля все коммиты пополам и так пока не найдется плохой? С такой нестабильной ситуацией доволно долго будет, если ничего другого не найду буду делать git bisect и наблюдать Не хотелось бы т.к. каждый коммит проверка минимум 3 суток (обчно падает за двое)

micaelma
() автор топика
Ответ на: комментарий от micaelma

гм. Да ты вовсю используешь jumbo frame.

Какой драйвер ixgbe используется - ванильный или с sourceforge.net ?

vel ★★★★★
()
Ответ на: комментарий от vel

Пробовал оба Сейчас ванильный modinfo ixgbe

filename: /lib/modules/3.2.83/kernel/drivers/net/ethernet/intel/ixgbe/ixgbe.ko

version: 3.6.7-k

license: GPL

description: Intel(R) 10 Gigabit PCI Express Network Driver

micaelma
() автор топика
Ответ на: комментарий от vel

Спасибо за ссылку По первому пункту работал ничего не нашел (все было чисто никто память не потреблял)

По третьему буду пробовать. соберу ядро с CONFIG_DEBUG_KMEMLEAK на одном из серверов посмотрю на логи

micaelma
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.