[Abram]

Всем доброго времени суток.

 

Никто не сталкивался с подобным? http://dl.dropbox.com/u/12495607/IMG_20110520_120128.jpg

 

x86_64, 2.6.38, accel-ppp, тупой ingress policer.

[nuclearcat]

TSO/GSO отключены надеюсь?

У меня шейперы много где работают, в т.ч. ingress, но такого не встречал.

[Abram]

TSO/GSO отключены надеюсь?

У меня шейперы много где работают, в т.ч. ingress, но такого не встречал.

Ух ты!

В rc.local вписано кровью:

ethtool -K eth0 gro off
ethtool -K eth1 gro off

Больше ничего не менялось.

# ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: off
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: off

 

А чем TSO/GSO плох? У меня вроде проблем не вызывали. Попробую отключить. Спасибо за подсказку.

Изменено 20 мая, 2011 пользователем Abram

[Abram]

Да, забыл добавить: это igb. Драйвер интела, 3.0.22.

# cat /etc/modprobe.d/igb.conf 
options igb RSS=4,4
options igb QueuePairs=0,0

[Abram]

Пару минут назад опять упал. Я уже не там, так что увижу причину падения только в понедельник.

Изменено 20 мая, 2011 пользователем Abram

[nuclearcat]

GSO тоже выключить

Очень интересный эффект они дают, собирают в skb пакеты по 40кб, которые шейпер не очень хорошо переваривает

[Abram]

GSO тоже выключить

Очень интересный эффект они дают, собирают в skb пакеты по 40кб, которые шейпер не очень хорошо переваривает

Упало с отключенными GSO, TSO и GRO.

Может ради интереса вообще все offload-ы отключить?

Видимо, таки придется сходить опять на работу и посмотреть на kernel panic - интерес перевешивает лень. :)

[Abram]

Странно. Упало вообще по-другому: http://dl.dropbox.com/u/12495607/IMG_20110521_173622.jpg .

Удалил Intel-овский igb, пока я был в серверной - опять упало, и опять по-другому: http://dl.dropbox.com/u/12495607/IMG_20110522_111832.jpg .

Запустил на всякий случай тест памяти.

 

Еще есть идеи?

Возможен ли глюк сетевой? У меня еще одна есть, могу поменять.

Изменено 22 мая, 2011 пользователем Abram

[Abram]

Тест памяти говорит, что все оке.

Только что поменял сетевуху, запустил, только вышел из серверной - опять упал.

http://dl.dropbox.com/u/12495607/IMG_20110522_122826.jpg

Это уже с Intel-овским igb драйвером и новой сетевухой. Еще подозрения: bonding. Для эксперимента отключил один порт - то же самое.

Завтра буду пробовать вообще его убрать.

Изменено 22 мая, 2011 пользователем Abram

[photon]

Если все так печально, почему тогда не рассматривается вариант собрать ядро другой версии или поставить FreeBSD?

[Abram]

Если все так печально, почему тогда не рассматривается вариант собрать ядро другой версии или поставить FreeBSD?

Уже рассматриваю вариант поставить 2.6.39.

А FreeBSD стоит сбоку. Сыплет время от времени ошибку 651, да и местным BSD-танцам с бубном я не обучен и как-то учиться не хочу :).

[photon]

местным BSD-танцам с бубном я не обучен и как-то учиться не хочу :)

А чего там учиться? Шейпер настраивается под Фряхой проще, чем под Линуксом. Главное с железом угадать, чтобы не напороться на неработающий драйвер сетевухи или чего-нибудь еще.

[Ivan Rostovikov]

У меня тоже 2.6.38 падало...

Поставил стоковое из дебиан. Стоит как вкопанное.

[Abram]

местным BSD-танцам с бубном я не обучен и как-то учиться не хочу :)

А чего там учиться? Шейпер настраивается под Фряхой проще, чем под Линуксом. Главное с железом угадать, чтобы не напороться на неработающий драйвер сетевухи или чего-нибудь еще.

Шейпер - дело десятое. А вот крутить эти все параметры в loader.conf... Брр. Не могу.

У меня тоже 2.6.38 падало...

Поставил стоковое из дебиан. Стоит как вкопанное.

Попробую .39 и что-нибудь постарее. Спасибо.

[nuclearcat]

Если 39 будет сыпаться, можем накатать багрепорт в netdev maillist, мож пофиксят.

[Abram]

Если 39 будет сыпаться, можем накатать багрепорт в netdev maillist, мож пофиксят.

В моем любимом дистрибутиве 2.6.39 уже в тестинге, набор патчей - минимальный. Так что завтра поставлю, посмотрим, что получится.

[nuclearcat]

Хм, разработчики вообще очень недолюбливают aufs2, по крайней мере пару лет назад.

Хотя на сетевую часть не должно повлиять, там ничего сетевого нет.

[Abram]

nuclearcat,

Соберу тогда без патчей.

[hawkmoon]

На .38 ведре помогает стабилизировать работу параметр slub_nomerge=1 в загрузку.

У меня все также - 2.6.38.6, x86_64, бондинг и интеловые сетевухи. Правда не igb, а e1000.

[Abram]

На .38 ведре помогает стабилизировать работу параметр slub_nomerge=1 в загрузку.

У меня все также - 2.6.38.6, x86_64, бондинг и интеловые сетевухи. Правда не igb, а e1000.

nuclearcat уже отправил багрепорт. Похоже, это sfq.

Посмотри http://marc.info/?l=linux-netdev&m=130614491524959&w=2 - похоже?

Изменено 24 мая, 2011 пользователем Abram

[SiXeD]

Никто не сталкивался с подобным? http://dl.dropbox.com/u/12495607/IMG_20110520_120128.jpg

x86_64, 2.6.38, accel-ppp, тупой ingress policer.

также на 2.6.31-gentoo-r6 x86_64 Intel® Core i7 CPU 920 @ 2.67GHz

начал выдавать такие ошибки после выгорания интегрированных сетевых карт

[DemYaN]

На .38 ведре помогает стабилизировать работу параметр slub_nomerge=1 в загрузку.

У меня все также - 2.6.38.6, x86_64, бондинг и интеловые сетевухи. Правда не igb, а e1000.

в 2.6.38 еще был баг(32772) с глубиной стека в net/ipv4/inetpeer.c, фикс-патч попал в 2.6.39 и проблема была устранена

[Abram]

Никто не сталкивался с подобным? http://dl.dropbox.com/u/12495607/IMG_20110520_120128.jpg

x86_64, 2.6.38, accel-ppp, тупой ingress policer.

также на 2.6.31-gentoo-r6 x86_64 Intel® Core™ i7 CPU 920 @ 2.67GHz

начал выдавать такие ошибки после выгорания интегрированных сетевых карт

Вряд ли это то же самое.

 

На .38 ведре помогает стабилизировать работу параметр slub_nomerge=1 в загрузку.

У меня все также - 2.6.38.6, x86_64, бондинг и интеловые сетевухи. Правда не igb, а e1000.

в 2.6.38 еще был баг(32772) с глубиной стека в net/ipv4/inetpeer.c, фикс-патч попал в 2.6.39 и проблема была устранена

Проверили на 2.6.39, падает. Отправили баг-репорт.

[sirmax]

у меня падал шейпер на 37-м и стабилизировалось на

Linux sirmax 2.6.38.2-sirmax1 #1 SMP PREEMPT Sat Apr 9 16:26:46 EEST 2011 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ AuthenticAMD GNU/Linux

Ванильное, без патчей

 

Шейпер простейший, ifb+sfq, причем падал от траффика. В тесте по вай-фаю все в норме, в том же влане первый ще тест по кабелю - и паника.

[Abram]

Увы, разобраться, что к чему, так и не получилось. Откатился на 2.6.35, все работает. Сервер уже в продакшене (нужно было срочно поставить), дальше разбираться возможности нет.

Точно стало известно:

 

* sfq тут ни при чем. Как и вообще что-либо другое в шейпере - отключил шейпер полностью, все равно упало.

* igb ни при чем. Падает как с родным, так и с интеловским драйвером.

* slub_nomerge тоже ни при чем.

* Баг 32772 на мое ядро не влиял. Хотя вполне возможно, что истина где-то рядом - валится вроде бы в том же районе.

* Железо у меня тоже нормальное, на совсем другой машине точно так же валится.

* tso/gso/gro ни при чем (хотя gro все равно лучше отключить ;) ).

 

Что я не проверял - это модуль pptp. В .38/.39 использовал ядерный. Хотя вроде xeb говорил, что в ядре он стабильный.

 

Вот такая вот фигня.

Изменено 26 мая, 2011 пользователем Abram