Прочитал много постов, по тому как крив "via_rhine" и что для фиксинга часто помогает опция ядра "pci=noacpi". Однако после трёх суток нормальной работы сеть опять затормозилась. Торможение заключается в падении скорости почти на порядок, при этом логи и dmesg молчат. Нашёл тут ещё такие, похожие, симптомы: http://www.opennet.ru/openforum/vsluhforumID1/84739.html Где проблему исправляют патчем к 2.6.29. Не могли бы Вы наложить этот патч? Нужно именно ядро 2.6.29 в виду его "RT".
Подскажите как его хоть собирать. Собираю из стандартного пользователя пакет kernel-image-rt-up-2.6.29-alt2.src.rpm и получаю: /bin/sh: line 1: 13791 Bus error perl kernel/timeconst.pl 250 > kernel/timeconst.h make[1]: *** [kernel/timeconst.h] Error 135 make: *** [kernel] Error 2 make: *** Waiting for unfinished jobs....
Смотрю в общем патче 2.6.29-rt-up.alt2 указанный мною патч есть. Хотя не совсем понятно назначение этого патча: http://patchwork.kernel.org/patch/14074 Что же ещё тогда попробовать? На 2.6.30 перейти не могу по причине наличия пары коммерческих драйверов, которые уже не резолвят несколько символов в 2.6.30. Да и уверенности в том, что на 2.6.30 всё будет нормально нет. Попробую наверное откатиться на 2.6.18. Может с включенным ACPI он даст нормальную частоту таймера реального времени.
http://www.bitwizard.nl/sig11/?
(In reply to comment #3) > http://www.bitwizard.nl/sig11/? Это ты к чему? Если к сборке ядра, так это или perl валится, который в настоящий момент в репозитории, или перловый скрипт ядра кривой. Я склонен считать первое. Результат независимого вызова перла для проблемного скрипта: # perl kernel/timeconst.pl Bus error Кстати, вопрос о том чтобы несчастные три перловых скрипта сборки заменить на шеловские уже поднимался и такие патчи уже есть. Можно этот случай считать аргументом за. А это ядро на текущем сизифе вообще пересобирается?
Ну так, можно пересобрать указанное ядро? Ибо в нём определённо проблемы с сетевым стеком. Ситуация подвисания сокетов упорно повторяется при различных настройках сетевых карт и на различных прерываниях. Лечится только перегрузкой сети, т.е. фактическим сбросом всех сокетов. Была мысль, что сокет тормозит из-за удержания открытым клиентского сокета всё время работы. Сделал открытие клиентского сокета, а затем закрытие по каждому запросу, тормознуло часов через пять. P.S. Проясните в конце концов статус этих ядер. Если они никак вообще не поддерживаются и даже не собираются я начну делать подвижки для перехода на 2.6.30.
вы пользуетесь xenomai? дело в том что эти ядра практически не тестированы, они работают на имеющемся оборудовании но не более того.
(In reply to comment #6) > вы пользуетесь xenomai? Желательно иметь для повышения равномерности периода сбора данных на 5КГц при прямом пулинге. В принципе, подобное обеспечивает и 2.6.30, но степень равномерности проверить возможности нет. Надо опять напрягать разработчиков железки на предмет пересборки их драйвера для 2.6.30. Поэтому и съезжать тяжело. > дело в том что эти ядра практически не тестированы, они работают на имеющемся > оборудовании но не более того. А пересобираются сейчас? :)
Кстати эта проблема проявляется и на 2.6.30-alt13. Причём другой нагрузки фактически небыло и особенно быстро это происходит при отключеном Keep-alive, в течении 5 часов. Перевешиваю на std-def. Какие предложения чего глянуть и чего попробовать?
Похоже у этой баги большая борода и она засвечена минимум с 2004 года (https://bugzilla.redhat.com/show_bug.cgi?id=129304). Бага в драйвере via_rhine, а он не менялся с 2006 года. Правится только установкой драйвера произвдителя (VIA - rhinefet), который в свою очередь давно не собирается на современных ядрах, да и обновлялся последний раз в 2007 году. Я его адаптировал для современных ядер, установил и проблемы пока не замечал. Резюме: Ситуация патовая. Нужно или фиксить via_rhine или допатчить и вложить в ядро драйвер rhinefet. Повышаю уровень до критичного. Что будем делать? Или мне выходить прямо на багзилу ядра?
Да хоть ты здесь пиши, что эта бага представляет угрозу существования человечества -- если не доходят руки, чем это поможет? Вот тебе бы помогло, если б на не тот цвет индикатора вешали критикалы и это замыливало глаз при попытке пересмотреть действительно суровые баги -- с потерей данных, скажем? Ром, если срочное -- не жди от других, делай сам или договорные отношения (и тогда всё равно тоже лучше делай сам). Сэкономишь много нервов и обычно время тоже. Если тебе чем-то поможет -- давай помогу с прохождением краткого курса сборщика ядра (всё на вики), будет работающий фикс -- в std-def смержат, думаю.
(In reply to comment #10) > Да хоть ты здесь пиши, что эта бага представляет угрозу существования > человечества -- если не доходят руки, чем это поможет? А я и не предлагаю мантейнеру лично фиксить эту багу. Я подразумеваю, что мантейнер перебросит эту багу куда положено. Или, если ему некогда, то я сам переброшу куда нужно, если покажут куда. Вопрос только в том, что если это сделаю я, то я не смогу квалифицированно отвечать на вопросы о том в каком окружении, с какими патчами, с какими особенностями собрано ядро. > Ром, если срочное -- не жди от других, делай сам или договорные отношения (и > тогда всё равно тоже лучше делай сам). Сэкономишь много нервов и обычно время > тоже. А я и не ждал, если ты не заметил. Я нашёл решение, и кроме того приложил усилия к адаптации к современным ядрам. А пофиксить модуль via_rhine я не могу, хотябы по тому, что тонкостей его работы и работы железки я не знаю, и думаю, что это мог-бы квалифицированно сделать его разработчик или мантейнер. > Если тебе чем-то поможет -- давай помогу с прохождением краткого курса сборщика > ядра (всё на вики), будет работающий фикс -- в std-def смержат, думаю. Я и так умею их собирать. Если конечно в окружение ОС не лежат тулзы, которые скрипты ядра уже не выполняют, это я про perl. Единственно в чём осталось разобраться это в предупреждении ядра о наличии элемента в дереве proc при запуске модуля, который он сейчас выдаёт. И тогда можно было-бы модуль "rhinefet" выложить в репозиторий.
(In reply to comment #11) > (In reply to comment #10) > А я и не предлагаю мантейнеру лично фиксить эту багу. Я подразумеваю, что > мантейнер перебросит эту багу куда положено. Или, если ему некогда, то я сам > переброшу куда нужно, если покажут куда. http://bugzilla.kernel.org (ты и так знаешь, думаю). > Вопрос только в том, что если это сделаю я, то я не смогу квалифицированно > отвечать на вопросы о том в каком окружении, с какими патчами, с какими > особенностями собрано ядро. Ну /boot/config от него-то привесить сможешь. > А пофиксить модуль via_rhine я не могу, хотябы по тому, что тонкостей его > работы и работы железки я не знаю, и думаю, что это мог-бы квалифицированно > сделать его разработчик или мантейнер. Только разработчик. Майнтейнер -- опять же только квалификации разработчика применительно к данному модулю. Поэтому с драйверами всё же лучше сразу в апстрим писать.
Уведомление об этой ошибке поместил сюда: http://bugzilla.kernel.org/show_bug.cgi?id=14702
Прикроем по неопределённости, пока. Если кому интересен драйвер rhinefet, то патч для его сборки можно получить здесь: http://wiki.oscada.org/Doc/ICPDAS/files?get=build_2.6.29.patch
