The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Раздел полезных советов: Борьба с kernel panic в Linux-ядре ..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Раздел полезных советов: Борьба с kernel panic в Linux-ядре ..."  +/
Сообщение от auto_tips on 13-Сен-10, 14:41 
Начиная с версии 2.6.35 в Linux-ядре появилась полезная функций "ramoops", позволяющая в случае краха сохранять информационный дамп состояния ядра в памяти для последующего анализа. Вкомпилировать данную функцию в ядро или загружать модулем "ramoops" - без разницы.

Единственная хитрость - сначала нужно зарезервировать память в ядре.
Сделать это можно указав ядру параметр memmap=256K@0xfc0000
(резервируем 256К перед ядром).

Если ramoops в ядре, то добавляем параметры

   ramoops.mem_address=0xfc0000 и
   ramoops.mem_size=0x40000

параметр ramoops.dump_oops=1 является умолчанием, так что его можно не указывать.

Для модуля "ramoops" эти параметры нужно указать при загрузке.

Теперь чтобы ядро не осталось в мертвом виде, не забываем сделать

   echo 10 >/proc/sys/kernel/panic

и (если нужно, а иногда полезно)

   echo 1 >/proc/sys/kernel/panic_on_oops

Теперь проверяем при помощи crash-а через Alt-SysRq-C.

После перезагрузки, текст crash-дампа будет лежать в памяти, начиная с адреса 0xfc0000.

Достать его оттуда можно при помощи

   dd if=/dev/mem bs=256k skip=63 count=1 >>crash.txt

либо при помощи простенькой программы, которая открывает /dev/mem и с указанного смещения читает данные.

Для сохранения дампа на диск следует использовать похожую функцию mtdoops.

URL:
Обсуждается: https://www.opennet.ru/tips/info/2436.shtml

Высказать мнение | Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по ответам | RSS]

1. "Борьба с kernel panic в Linux-ядре 2.6.35 и выше . "  +/
Сообщение от BartMan on 13-Сен-10, 14:41 
А пороли он туда не будет таво?
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

2. "Борьба с kernel panic в Linux-ядре 2.6.35 и выше . "  +/
Сообщение от Аноним (??) on 13-Сен-10, 14:56 
>А пороли он туда не будет таво?

к /dev/mem только root имеет доступ

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

3. "Борьба с kernel panic в Linux-ядре 2.6.35 и выше . "  +/
Сообщение от Aquarius (ok) on 13-Сен-10, 22:37 
подразумевается, что после перезагрузки root'ом может быть уже root, в общем-то, другой системы
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

4. "Борьба с kernel panic в Linux-ядре 2.6.35 и выше . "  +/
Сообщение от stranger (??) on 13-Сен-10, 22:54 
dd: reading `/dev/mem': Operation not permitted
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

5. "Борьба с kernel panic в Linux-ядре 2.6.35 и выше . "  +/
Сообщение от pavlinux (ok) on 13-Сен-10, 22:58 
# CONFIG_STRICT_DEVMEM is not set

Ась?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

6. "Борьба с kernel panic в Linux-ядре 2.6.35 и выше . "  +/
Сообщение от pavlinux (ok) on 13-Сен-10, 23:05 
Более интересно

> После перезагрузки, текст crash-дампа будет
> лежать в памяти, начиная с адреса 0xfc0000.

Как он туда попадёт, *после перезагрузки* ?! :)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

7. "Борьба с kernel panic в Linux-ядре 2.6.35 и выше . "  +/
Сообщение от pavlinux (ok) on 14-Сен-10, 02:21 
> Единственная хитрость - сначала нужно зарезервировать память в ядре.
> Сделать это можно указав ядру параметр memmap=256K@0xfc0000 (резервируем 256К перед ядром).

1.  memmap=256K$0xfc0000 ($ надо писать, для резервирования)

     http://lxr.linux.no/#linux+v2.6.35/Documentation/kernel-para...

> Если ramoops в ядре, то добавляем параметры
> ramoops.mem_address=0xfc0000 и  ramoops.mem_size=0x40000

2. То с вероятностью 99.999% схватите

ramoops: request mem region failed

3. cat /proc/iomem , говорит что по адресу 0xfc0000

00fc0000-00ffffff : System RAM


Где он сцука хранит??? Если я питание выключаю!!!!!!!!!!

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

8. "Борьба с kernel panic в Linux-ядре 2.6.35 и выше . "  +/
Сообщение от stranger (??) on 14-Сен-10, 09:38 
Ramoops, like mtdoops, can log oops/panic information but in RAM. It can
be used with *persistent RAM* for systems without flash support. In
addition, for this systems, with this driver, it's no more needed
add to the kernel the mtd subsystem with advantage in footprint.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

9. "Борьба с kernel panic в Linux-ядре 2.6.35 и выше . "  +/
Сообщение от Аноним (??) on 14-Сен-10, 10:21 
Рассчитано на мягкий ребут, вызванный крахом ядра. Память не очищается, соответственно старые данные остаются на том же месте, где и оставлены. После ребута посмотрите /dev/mem, много интересного из "прошлой жизни" найти можно.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

10. "Борьба с kernel panic в Linux-ядре 2.6.35 и выше . "  +/
Сообщение от pavlinux (ok) on 14-Сен-10, 14:42 
Вот что рассказал автор:


>>> Tell me please, where are stored ramoopses, if I turn off the power? :)
>>
>> When you load the module (or with kernel command line) you have to say
>> to the kernel the address to remap, i.e. where you want to store the
>> oops.
>
>  It's work if only i make a "soft-reboot", without regeneration of RAM ?
>

The physical address can be normal RAM, NVRAM, and so on. Sure, if you
use normal RAM, the bootloader/bios shouldn't write the memory area
selected to store the oops at the next reboot. In the embedded world
it's a common feature, see CONFIG_PRAM of u-boot for example.

Regards, Marco


Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

11. "Борьба с kernel panic в Linux-ядре 2.6.35 и выше . "  +/
Сообщение от User294 (ok) on 23-Сен-10, 03:13 
Никак. Дамп там *останется* с "прошлого" раза. При мягкой перезагрузке содержимое памяти никто не чистит (насколько это правда-зависит от биоса/загрузчика в принципе). Так что кернелу ничто не помешает при следующей загрузке взять из памяти то что туда сложила покрашившаяся инкарнация ядра до выполнения мягкого ребута. Собссно для того и резервируется(иначе нет никаких гарантий что ядру не приспичит записать чего-то именно в эту же область оперативы, а так его явно тыкают носом в то что низзя этот кус памяти трогать). Просто и старо как мир. IIRC, были даже досовые вирусы которые пытались (с переменным успехом) переживать мягкую (теплую) перезагрузку (ту которая скипает мемтест) юзая похожие фокусы.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

12. "Борьба с kernel panic в Linux-ядре 2.6.35 и выше . "  +/
Сообщение от pavlinux (ok) on 23-Сен-10, 06:07 
>Никак. Дамп там *останется* с "прошлого" раза.

Спасибо, что читаете более поздние сообщения
и отвечаете на более ранние. :)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру