Kernel panic

Какая это архитектура (просто интересно)?

Как увидеть лог

http://www.kernel.org/doc/Documentation/kdump/kdump.txt например.

Как так получается, что обычный юзер может положить систему на лопатки?

Для такого можно привести несколько вариантов, кот-е являются «фичами».

http://www.kernel.org/doc/Documentation/kdump/kdump.txt например.

Проще же подключиться через ttyS0 и смотреть лог с другого компа.

1) www.linux.org.ru/wiki/en/Как_получить_содержимое_буфера_ядра_с_зависшей_системы может помочь

Если он есть.

http://gimages.tk/images/U7gMs.jpg

Было бы здорово, если бы кто-то сделал на этой картинке OCR или, хотя бы, уменьшил.

Пикрилэйтед: http://ompldr.org/vZXY4bw

Как получить лог тебе уже сказали. Но мне кажется что это мало что тебе даст. Я бы копал в сторону:
1. Обновить или откатить на пред. версию программулину/либу которая это делает.
2. Посмотреть есть ли где-то какие-то хитрый флаги компиляции (оптимизации и т. п.)
3. Перепроверил бы, правильно ли выставлена ахитектура при компиляции.
4. Перепроверил бы зависимости, все ли там хорошо и выполняются ли пункты 1-3

запуск разделяемой библиотеки как обычного исполняемого файла с очень длинным аргументом

5. Возможно переполнение буффера или другой баг в этой библиотеке. Если ты программер и библиотека твоя - отладить код.

Вобщем формулировка проблемы очень расплывчата, так что вот тебе расплывчатые рекомендации.

версия ядра?

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

ядро … патченное руками заинтересованной организации.

Ну а в чём тогда вопрос? Скорее всего не руками, а тыпонел.

Данная ссыль, как и предыдущие бесполезны, так как архитектура не стандартная, и до дебиана эта поделка довольно далека.

В статье написано про считываение при помощи последовательного порта, как это сделать?

2.6.14

Боже мой. 3.х на дворе.

Параметр ядра console=ttyS0 не помогает?

Мне нужно докопаться до её сути.

Так докопайся! Пусть прога ведет лог (только с постоянным sync'ом), там, где он оборвется, проблема. Еще вариант - использовать strace, через него тоже станет понятно где проблема. Как забрать лог с завиcшей системы уже ссылку давали. Я когда-то syslog-ng настравивал для передачи логов по сети (в детстве, когда админил, на своем терминальчике на 9-й консоли у меня всегда выводился актуальный лог сервера).

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

В статье написано про считываение при помощи последовательного порта, как это сделать?

1. По какому мануалу делаешь?
2. Что ты уже сделал, и на чем застопорился?

Мануал по чтению дампов с com порта то дайте, а то гугл неохотно информацией делится.

Процесс обычного пользователя (не важно программа или библиотека) не должны вызывать панику ядра. Но в ядре постоянно находят ошибки/уязвимости, так что ваша библиотка похоже нашла ещё одну новую (или известную) ошибку в коде ядра. Почему работает с текстовой консоли, но не работает через ssh сказать сложно. Так, можно было бы попробовать запустить через strace (в putty) и посмотреть на каких вызовах всё падает, посмотреть, не передаётся ли в ядро NUL-указатели или ещё что, но не знаю, успеет ли strace вывести это на консоль до паники ядра.

Так не понятно что советовать, так как не известно есть ли у вас исходники этой библиотеки и ядра, чтобы можно было добавлять отладочную печать или исходников нет?

com порт это «serial console». В гугле полно ответов как она включается, вопрос только в том, если ли у вас поддержка этого в ядре.

1. Serial console

Мануал по чтению дампов с com порта то дайте, а то гугл неохотно информацией делится.

Вот на русском. Тебе по идее интересна только глава «GRUB через последовательный порт»
http://ru.gentoo-wiki.com/wiki/HOWTO_Подключение_консоли_через_последовательн...
Но там есть некоторые неточности. Поэтому лучше на английском:
http://www.vanemery.com/Linux/Serial/serial-console.html

2. Выше тебе давали ссылку на альтернативный способ получения дампа. Повторю:
www.linux.org.ru/wiki/en/Как_получить_содержимое_буфера_ядра_с_зависшей_системы

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

Сделай хоть что-то из предложенного, отписывайся по результатам.

Эмм, сделал. Так вот, лог загрузки ядра вижу, могу даже залогиниться на целевой машине. Вижу все что в >>/dev/ttyS1 суется. Но вот после вызова KerPanic удаленная машина уже ничего не видит, все самое интересное вылазит на целевой машине через VGA и только. На удаленной машине стоит винда, putty. Как все-таки увидеть именно лог kerPanic?

Если через последовательный порт не получается - не знаю. Может другие подскажут.

Тогда рекомендую обратиться к п. 3. - добавить лог в программу и задержки в «опасных» местах.

P. S. Опасные места я бы находил вручную. Но вот линк в копилку: http://www.xakep.ru/magazine/xa/131/038/1.asp

Попробуйте оставить в параметрах ядра в настройках загрузчика только «console=ttyS1,38400», а «console=tty» убрать.

Низя, в системе стоит какой-то своеобразный загрузчик, который не позволяет редактировать свой конфигурационный файл, никому, ДАЖУ руту.

никому, ДАЖУ руту.

immutable флаг, что-ли на файл конфигурации поставлен?

А как у вас сейчас сделана консоль на COM-порту? Только в inittab прописано и всё?

А в виртуалке воспроизводится?

Нет не только, в boot.conf (это то что вместо grub.conf) уже была прописана серийная консоль

Если я не путаю, когда указано несколько консолий, то panic сообщения ядро всегда пишет только на одну консоль (последнюю), так что без правки boot.conf не обойтись. Хотя не факт, что ваше ядро не пропатчено в этих местах.