Подскажите как его хоть собирать.
Собираю из стандартного пользователя пакет 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