Вылеты (segmentation fault) после перехода на ядро 2.6.25.x

Совсем недавно собрал систему (х86 32bit)(со stage1, без малейших проблем или осложнений). При сборке использовалось ядро 2.6.24.3 (Vanilla). Система была собрана с целью попробовать Mosix (по описаниям - неплохая вещь для организации кластера). Mosix поставляется в виде патча для ядра и набора уже собранных бинарников для управления кластером. Когда на этой системе пробовал Mosix для ядер 2.6.24.x все было нормально. После того, как поставил новую версию - для ядер 2.6.25.x - появились проблемы. Пытаюсь запустить задачу (любую) в режиме миграции процесса на другой узел - и получаю вылет по segmentation fault. Попробовал отладчиком - получил такой ответ: SIGSEGV в __kernel_vsyscall().
Полез смотреть в ядро - начиная с 2.6.25.x __kernel_vsyscall() в явном виде нигде нет. В System.map от ядра 2.6.24.3 __kernel_vsyscall() в самом верху (0x400). А в 2.6.25.4, насколько я понял, __kernel_vsyscall теперь связан с VDSO, хотя я не вполне понимаю, что это такое и как оно работает... Но в System.map такой функции больше нет. На ее месте VDSO_что-то. По-моему, sigreturn. В этой связи есть вопрос - можно ли что-то сделать для того, чтобы обойти имеющиеся грабли? Может, в связи с изменениями, в glibc теперь что-то не так стало работать? Хотя... Все остальное вроде бы не глючит. Но и у Mosix-а пакет лежит как релиз, по идее должно работать...

проект openmosix не

проект openmosix не развивается и закрыт

openmosix!=mosix

А я и не писал про openmosix, я писал про mosix.
Этот проект коммерческий, поэтому они управляющее ПО поставляют в уже собранном виде, без исходников, и только для 32-битных систем.
Были бы исходники, так я и сам бы смог разобраться, откуда грабли. А так - непонятно нифига... То ли релиз у них такой хреновый? Может, полностью систему пересобрать, но поможет ли это? Впустую неохота, долго.

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".