дамп ядра для Linux 2.6

Ну если magic sysrq в ядре включено и клавиатура не совсем умерла - то можно что-то попытаться увидеть... А так дебажить (да ещё модули)...я бы kdb смотрел (хотя у меня была по крайней мере одна ситуация когда и kdb вис тоже) gdb можно смотреть в статике а не в динамике насколько я знаю...

Других выходов честно говоря не вижу

> Ну если magic sysrq в ядре включено и клавиатура не совсем умерла - то можно что-то попытаться увидеть...

или же оно выключено, или же система умерла вконец. впрочем, и рабочая система ноль внимания на sysreq so видимо просто выключено.

> А так дебажить (да ещё модули)...я бы kdb смотрел (хотя у меня была по крайней мере одна ситуация когда и kdb вис тоже)

AFAIU для него нужно патчить и пересобирать ядро :-/ чего делать очень не хочется в силу 3х сил.

> gdb можно смотреть в статике а не в динамике насколько я знаю...

да, gdb + kernel dump конечно же выдает лишь статичкскую информацию типа бектрейса и пр. но я и не настаиваю на полноценном динамическом отладчике, мне хотя бы полный бектрейс получить чтобы понять, в каком же собственно месте то все грохнулось. а так я даже этого не вижу :(

// wbr

А Вы под X-ами или в консоли это ловите?

Не знаю может это изврат - но попробуйте в fb побольше разрешение выставить ну и монитор побольше... :-)

> А Вы под X-ами или в консоли это ловите?

аппаратная консоль в режиме эмуляции VMware

> Не знаю может это изврат - но попробуйте в fb побольше разрешение выставить ну и монитор побольше... :-)

там бектрейс в длину на полторы-две сотни строк :)

// wbr

тогда сделайте перенаправление , параметр загрузки ядра console=ttyS1 , на ttyS1 повесить что-нибудь (minicom) способное записывать полученные сообщения в файл.

По поводу tty тоже были мысли - но не уверен что это сработает... Если попробуйте - сообщите - интересно прокатит это или нет

можно запустить образ под qemu и приконектиться с помощью gdb,
тут и пошаговая отладка и просмотр переменных и все что душе угодно,
не знаю обладает ли такой же способностью vmware.

> тогда сделайте перенаправление , параметр загрузки ядра console=ttyS1 , на ttyS1 повесить что-нибудь (minicom) способное записывать полученные сообщения в файл.

мне эта мысль в голову приходила, но под рукой небыло кабеля. впрочем, попробую. вот если бы VMware умела сцеплять виртуальные порты - цены бы ей небыло :) впрочем, воткнуть кабель не проблема. если конечно же на моей рабочей машине вообще есть разъем rs232 :-/

// wbr

> можно запустить образ под qemu и приконектиться с помощью gdb,
тут и пошаговая отладка и просмотр переменных и все что душе угодно,

не знал. может быть стоит попробовать.

> не знаю обладает ли такой же способностью vmware.

может быть, но я не в курсе. AFAIU для VMware есть накая приблудина под названием "VMware Tools" которая [опять же AFAIU] ставится в контексте виртуализируемой системы и обеспечивает связь между сервером и системой. вроде так. но все попытки найти эти самые tools пока что успехом не увенчались :-/

// wbr

должны быть ISO образы для 4 типов гостевых систем в одном из каталогов куда устанавливается VmWare - в них vmware tools

>может быть, но я не в курсе. AFAIU для VMware есть накая приблудина >под названием "VMware Tools"

надо в меню vmware порыться, говоришь поставить vmware tools,
потом в гостевой монтируешь диск и с него ставишь,
но кроме копирования из/в виртуальной машины теста, драйвера для VMWare видеокарта, я там ничего не припомню.

Да, в VMware tools предлагает немного - помимо вышеперечисленного если не ошибаюсь +full screen mode

По поводу qemu посмотрел (интересно стало) - там ограничений выше крыши. gdb это конечно хорошо - но если нет возможности отлаживать то что тебе надо - то какой в этом прок?...(это я к вопросу о применимости qemu в данном случае)

умеет ;)

А всякие там LKCD, kdump и прочие - не рассматриваются по причине патченья ядра?

> А всякие там LKCD, kdump и прочие - не рассматриваются по причине патченья ядра?

да, именно так.

блин ну не верю я что в Linux в его RHEL инкарнации все ну на столько херово с отладкой! так просто не может быть, это маразм какой-то. неужели со штатным ядром ничего нельзя сделать для получения такой казалось бы тривиальной вещи как бектрейс после паника *без* патчей и пересборки ядра :-?

// wbr

> умеет ;)

очень ценное кстати замечание, большое спасибо :) я и не знал, что VMware умеет перенаправлять виртуальные порты к примеру в файл или в пайп.

проблема решена заведением в VMware /dev/ttyS0 с перенаправлением в файл и загрузкой штатного ядра с логированием в последовательный порт. когда все валится паника по-честному гадится в фало so по крайней мере теперь я могу посмотреть, что же там написано. проблема решена, хотя и несколько через зад.

psL как в Linux ядре при его куцести разрабатывать что-то более-менее сложное без применения VMware или аналога слабо себе представляю :-/

// wbr

> проблема решена заведением в VMware /dev/ttyS0 с перенаправлением в файл

нельзя ли поподробнее - а то я тоже об этом впервые слышу - как собственно перенаправление делается?

BTW, вообще-то я отказался от эмуляторов - работать надо в родной ОС - но это моё личное мнение...(конечно не когда ОС меняются через день)

> нельзя ли поподробнее - а то я тоже об этом впервые слышу - как собственно перенаправление делается?

да в сущьности, как оказалось, все элементарно - говорите VMware в заданной машине добавить устройство "последовательный порт", она в визарде спрашивает, куда его собственно подключить - к реальному аппаратному порту, перенаправить вывод в файл [задаете путь] или же в пайпу. вот собственно и все. после выбора файла все выводимые в /dev/ttySx данные перехватываются VMware и аккуратно пишутся в указанный файл. в том числе и полный бектрейс после паника [если для вывода сообщений ядра используется последовательная консоль].

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

> BTW, вообще-то я отказался от эмуляторов - работать надо в родной ОС - но это моё личное мнение...(конечно не когда ОС меняются через день)

я не меняю OS через день, но

1) Linux в виде кролика на целевой системе в силу специфики проекта и разработки имеет особенность перегружаться по пару десятков раз в день [если день черный]. врагу не пожелаю делать это на живом железе, тем более под собой на хосте :-/ 2я железка по сравнению с виртуальной машиной заметно проигрывает.
2) IMHO (sic!) обычная WinXP на порядок удобнее и шустрее практически любого *NIX окружения, доступного в том числе в Linux :) а для собственно разработки мне обычного ssh хватает выше крыши so нет резона ставить что-то, отличное от.

// wbr

thanx за ответ про перенаправление

но всё-таки у VMware есть определённая область применимости - например при написании дров (чем я уже пару лет занимаюсь) будет довольно сложно отлаживать (если вообще возможно - например в случае высокоскоростных USB 2.0 видеоустройств - эмулятор и без этого проц подгружает прилично)

обычно для таких целей лучше предоставить отдельный комп (макет), но можно и на host'е - если денег жалко в фирме. из личного опыта (с кучей oops'ов и нескольких "реальных" умираний системы) - не было никаких серьёзных последствий (кроме отката ext3). imho траблы с эмуляторами перевешивают очень небольшую (на мой взгляд) вероятность повреждения системы (fs) поэтому я отказался от них, хотя необходимо сказать что иногда они (эмуляторы) бывают полезны...

> но всё-таки у VMware есть определённая область применимости - например при написании дров (чем я уже пару лет занимаюсь) будет довольно сложно отлаживать (если вообще возможно - например в случае высокоскоростных USB 2.0 видеоустройств - эмулятор и без этого проц подгружает прилично)

при отладке драйверов железок VMware действительно может быть скорее проблемой, чем помошником. все-таки эмуляция живого железа - это не есть гут. но когда приходится разрабатывать код, не имеющий прямого отношения к аппаратному обеспечению, тут VMware неоценимый помошник. действительно, на нулевом этапе какая собственно разница где работать для файловой системы XYZ - на живом железе или же в VMware. потому что она то как раз должна нормально работать в обоих окружениях вне зависимости от конкретного железа.

// wbr

> обычно для таких целей лучше предоставить отдельный комп (макет), но можно и на host'е - если денег жалко в фирме. из личного опыта (с кучей oops'ов и нескольких "реальных" умираний системы) - не было никаких серьёзных последствий (кроме отката ext3). imho траблы с эмуляторами перевешивают очень небольшую (на мой взгляд) вероятность повреждения системы (fs) поэтому я отказался от них, хотя необходимо сказать что иногда они (эмуляторы) бывают полезны...

проблем с действительно умершей системой после опса я пока что не наблюдал и система вполне нормально восстанавливалась после рестарта (ext3). ну бывает что со второго раза, но это скорее уже к VMware. впрочем, основная масса данных монтируется через NFS so какие уж тут проблемы.. :)

VMware IMHO заметно выигрывает с точки зрения скорости разработки. не столько в плане скорости работы хоста в виртуальном окружении, сколько в плане восстановления после сбоя. чисто субъективно RHEL4 в ней грузится замето шустрее а это начинает быть достаточно ощутимым преимуществом, когда за час вы его перегружаете десяток другой раз в тщетных поисках Больщого Бага. про получения бектрейса я уже писал :) причем что когда баг действительно Большой и система полностью умирает после 3го наведенного багом паника непонятно где, отлавливать это чудо становится проблемой.

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

// wbr