8.2 ядро постоянно в панике

[vampyr]

А шлейфы, и сами харды ты уверен в них... Просто к чему я клоню. Твой диагноз не понятен, тут методы исключения остаются. Чесно говоря как в том ролики про мента "здесь наши полномочия всё..." ну просто не было у меня за 8 лет практики такого жосткого пада. При том, что я работаю в аут-сорсинге где не один сервер и не один объект с разной конфигурацией приходилось обслуживать. Ну не разу я не видел такого жосткого пада... Исключай и всех подозревай. А какую конкретно роль сервер выполняет, что именно он делать должен и делал раньше? Какие исходные данные какая нагрузка?

Шлейфы меняны на хардах, харды куплены в феврале... А че им будет-то? Они либо битыми блоками покрываются, либо пашут... Не знаю вариантов с паником по хардам, кроме битых блоков на свопе. Бб нет... Нагрузка разная. Этот, в основном, вебхостинг и ип телефония. Телефония - так... Почти не грузит сейчас, все внешние отрублены. Веб нагрузка разная, то туча народа, то пара соединений... Была на серваке еще функция впн централки, объединяющей все мои хосты в кучку, но она сейчас отрублена. Кстати как все выгрузил стоит и не перегружается... Уже 2-е сутки. Тут еще прикол, теперь начал ругаться еще один мой сервак, самый древний. ))) Который в 2005-м был еще запущен. Во че пишет:

Код: Выделить всё

Apr 19 09:01:57 msk-akb-25 kernel: xl0: unknown XCVR type: 15
Apr 19 09:02:00 msk-akb-25 last message repeated 3 times
Apr 19 09:03:23 msk-akb-25 kernel: and never completed!
Apr 19 09:03:23 msk-akb-25 kernel: xl0: transmission error: ff
Apr 19 09:03:23 msk-akb-25 kernel: xl0: command never completed!
Apr 19 09:03:23 msk-akb-25 kernel: xl0: transmission error: ff
Apr 19 09:03:23 msk-akb-25 kernel: xl0: command never completed!

На нем ось 5.4-RELEASE. Я, конечно, могу предположить что кто-то ненавидит меня за что-то и последовательно достает мои серваки. )))) Потому как такую ошибку я на том серваке вижу тоже впервые. И, как ни странно, все связано с сетевыми картами внешнего интерфейса или нетграфом. Это если "всех подозревай" Третий сервак из моих за последние 3 дня. Прикольно, да? С учетом того что 2 из них с аптаймами в годы. ))))

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[snorlov]

Казачок где-то имеется засланный...

[fox]

Казачок где-то имеется засланный...

Ага лучший хак, это когда кто-то свой зади - с тылу пристраивается :-)

Фире вел не пробовали оптимально настроить перекрыть всевозможные дыры? На фрагментции больших файлов ещё чего небыдь там...

[vampyr]

Фире вел не пробовали оптимально настроить перекрыть всевозможные дыры? На фрагментции больших файлов ещё чего небыдь там...

Пока самое удачное решение - все как было, кроме нетграфа. Выгружен практически весь нетграф и заглушен мпд. Стоит. 3-е суток. ))))

[Проходил мимо]

Паника очевидно из-за бесконечного зацикливания этих двух функций

Код: Выделить всё

tcp_output (tp=0xc69eb768) at ../../../netinet/tcp_output.c:1267
tcp_mtudisc (inp=0xc6f4e898, errno=0) at tcp_offload.h:282

Соответственно какая-то проблема с MTU и вашим туннелем. Что там у вас pppoe или ipsec?

- фильтруются icmp пакеты
- вот похожая штука http://www.opennet.ru/openforum/vsluhfo ... /6682.html
- 16 апреля 2012 был патч похожий на вашу проблему
- http://www.freebsd.org/cgi/cvsweb.cgi/s ... p_output.c
- http://www.freebsd.org/cgi/cvsweb.cgi/s ... cp_input.c
- http://www.freebsd.org/cgi/cvsweb.cgi/s ... tcp_subr.c
- http://www.freebsd.org/cgi/cvsweb.cgi/s ... /tcp_var.h

When we receive an ICMP unreach need fragmentation datagram, we take
proposed MTU value from it and update the TCP host cache. Then
tcp_mss_update() is called on the corresponding tcpcb. It finds the
just allocated entry in the TCP host cache and updates MSS on the
tcpcb. And then we do a fast retransmit of what we have in the tcp
send buffer.

This sequence gets broken if the TCP host cache is exausted. In this
case allocation fails, and later called tcp_mss_update() finds nothing
in cache. The fast retransmit is done with not reduced MSS and is
immidiately replied by remote host with new ICMP datagrams and the
cycle repeats. This ping-pong can go up to wirespeed.

To fix this:
- tcp_mss_update() gets new parameter - mtuoffer, that is like
offer, but needs to have min_protoh subtracted.
- tcp_mtudisc() as notification method renamed to tcp_mtudisc_notify().
- tcp_mtudisc() now accepts not a useless error argument, but proposed
MTU value, that is passed to tcp_mss_update() as mtuoffer.

Reported by: az
Reported by: Andrey Zonov <andrey zonov.org>
Reviewed by: andre (previous version of patch)

[vampyr]

Паника очевидно из-за бесконечного зацикливания этих двух функций

Код: Выделить всё

tcp_output (tp=0xc69eb768) at ../../../netinet/tcp_output.c:1267
tcp_mtudisc (inp=0xc6f4e898, errno=0) at tcp_offload.h:282

Соответственно какая-то проблема с MTU и вашим туннелем. Что там у вас pppoe или ipsec?
Reported by: Andrey Zonov <andrey zonov.org>

pptp там у меня было. На самом деле ляпов в тсп у них туча, насколько понял в процессе изучения. ))) Зонов ответил на мой вывешенный баг, подсунув патч за 18-е марта. )))) Как я копал, это - частный случай и одна из сторон проблемы. Судя по дате файлов в вашем посте, лучше я попробую подсунуть ядру их, посмотрим что будет. )))