Начиная с версии 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

• Борьба с kernel panic в Linux-ядре 2.6.35 и выше . ,BartMan, 14:41 , 13-Сен-10
  • Борьба с kernel panic в Linux-ядре 2.6.35 и выше . ,Аноним, 14:56 , 13-Сен-10
    • Борьба с kernel panic в Linux-ядре 2.6.35 и выше . ,Aquarius, 22:37 , 13-Сен-10
• Борьба с kernel panic в Linux-ядре 2.6.35 и выше . ,stranger, 22:54 , 13-Сен-10
  • Борьба с kernel panic в Linux-ядре 2.6.35 и выше . ,pavlinux, 22:58 , 13-Сен-10
• Борьба с kernel panic в Linux-ядре 2.6.35 и выше . ,pavlinux, 23:05 , 13-Сен-10
  • Борьба с kernel panic в Linux-ядре 2.6.35 и выше . ,User294, 03:13 , 23-Сен-10
    • Борьба с kernel panic в Linux-ядре 2.6.35 и выше . ,pavlinux, 06:07 , 23-Сен-10
• Борьба с kernel panic в Linux-ядре 2.6.35 и выше . ,pavlinux, 02:21 , 14-Сен-10
  • Борьба с kernel panic в Linux-ядре 2.6.35 и выше . ,Аноним, 10:21 , 14-Сен-10
    • Борьба с kernel panic в Linux-ядре 2.6.35 и выше . ,pavlinux, 14:42 , 14-Сен-10
• Борьба с kernel panic в Linux-ядре 2.6.35 и выше . ,stranger, 09:38 , 14-Сен-10

А пороли он туда не будет таво?

>А пороли он туда не будет таво?

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

подразумевается, что после перезагрузки root'ом может быть уже root, в общем-то, другой системы

dd: reading `/dev/mem': Operation not permitted

# CONFIG_STRICT_DEVMEM is not set

Ась?

Более интересно

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

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

Никак. Дамп там *останется* с "прошлого" раза. При мягкой перезагрузке содержимое памяти никто не чистит (насколько это правда-зависит от биоса/загрузчика в принципе). Так что кернелу ничто не помешает при следующей загрузке взять из памяти то что туда сложила покрашившаяся инкарнация ядра до выполнения мягкого ребута. Собссно для того и резервируется(иначе нет никаких гарантий что ядру не приспичит записать чего-то именно в эту же область оперативы, а так его явно тыкают носом в то что низзя этот кус памяти трогать). Просто и старо как мир. IIRC, были даже досовые вирусы которые пытались (с переменным успехом) переживать мягкую (теплую) перезагрузку (ту которая скипает мемтест) юзая похожие фокусы.

>Никак. Дамп там *останется* с "прошлого" раза.

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

> Единственная хитрость - сначала нужно зарезервировать память в ядре.
> Сделать это можно указав ядру параметр 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

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

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

Вот что рассказал автор:

>>> 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

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.