forum.opennet.ru - "Раздел полезных советов: Борьба с kernel panic в Linux-ядре ..." (12)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"Раздел полезных советов: Борьба с 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: Обсуждается: http://www.opennet.me/tips/info/2436.shtml
Высказать мнение \| Ответить \| Правка \| Cообщить модератору

Оглавление

Борьба с kernel panic в Linux-ядре 2.6.35 и выше . , BartMan, 14:41 , 13-Сен-10, (1)

Борьба с kernel panic в Linux-ядре 2.6.35 и выше . , Аноним, 14:56 , 13-Сен-10, (2)

Борьба с kernel panic в Linux-ядре 2.6.35 и выше . , Aquarius, 22:37 , 13-Сен-10, (3)

Борьба с kernel panic в Linux-ядре 2.6.35 и выше . , stranger, 22:54 , 13-Сен-10, (4)

Борьба с kernel panic в Linux-ядре 2.6.35 и выше . , pavlinux, 22:58 , 13-Сен-10, (5)

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

Борьба с kernel panic в Linux-ядре 2.6.35 и выше . , User294, 03:13 , 23-Сен-10, (11)

Борьба с kernel panic в Linux-ядре 2.6.35 и выше . , pavlinux, 06:07 , 23-Сен-10, (12)

Борьба с kernel panic в Linux-ядре 2.6.35 и выше . , pavlinux, 02:21 , 14-Сен-10, (7)

Борьба с kernel panic в Linux-ядре 2.6.35 и выше . , Аноним, 10:21 , 14-Сен-10, (9)

Борьба с kernel panic в Linux-ядре 2.6.35 и выше . , pavlinux, 14:42 , 14-Сен-10, (10)

Борьба с kernel panic в Linux-ядре 2.6.35 и выше . , stranger, 09:38 , 14-Сен-10, (8)

Сообщения по теме [Сортировка по времени | 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ообщить модератору

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ообщить модератору

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ообщить модератору

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ообщить модератору

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ообщить модератору

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

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ообщить модератору


	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ообщить модератору

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ообщить модератору


	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ообщить модератору

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ообщить модератору