The OpenNET Project / Index page

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

Борьба с kernel panic в Linux-ядре 2.6.35 и выше
Начиная с версии 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.

Дополнение: Для работы в ядре необходимо выключить опцию CONFIG_STRICT_DEVMEM 
 
13.09.2010 , Автор: Аноним
Ключи: linux, kernel, oops, dump, crash, panic, debug / Лицензия: CC-BY
Раздел:    Корень / Администратору / Система / Просмотр состояния и мониторинг системы

Обсуждение [ Линейный режим | Показать все | RSS ]
  • 1.1, BartMan (?), 14:41, 13/09/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А пороли он туда не будет таво?
     
     
  • 2.2, Аноним (-), 14:56, 13/09/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >А пороли он туда не будет таво?

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

     
     
  • 3.3, Aquarius (ok), 22:37, 13/09/2010 [^] [^^] [^^^] [ответить]  
  • +/
    подразумевается, что после перезагрузки root'ом может быть уже root, в общем-то, другой системы
     

  • 1.4, stranger (??), 22:54, 13/09/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    dd: reading '/dev/mem': Operation not permitted
     
     
  • 2.5, pavlinux (ok), 22:58, 13/09/2010 [^] [^^] [^^^] [ответить]  
  • +/
    # CONFIG_STRICT_DEVMEM is not set

    Ась?

     

  • 1.6, pavlinux (ok), 23:05, 13/09/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Более интересно

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

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

     
     
  • 2.11, User294 (ok), 03:13, 23/09/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Никак. Дамп там *останется* с "прошлого" раза. При мягкой перезагрузке содержимое памяти никто не чистит (насколько это правда-зависит от биоса/загрузчика в принципе). Так что кернелу ничто не помешает при следующей загрузке взять из памяти то что туда сложила покрашившаяся инкарнация ядра до выполнения мягкого ребута. Собссно для того и резервируется(иначе нет никаких гарантий что ядру не приспичит записать чего-то именно в эту же область оперативы, а так его явно тыкают носом в то что низзя этот кус памяти трогать). Просто и старо как мир. IIRC, были даже досовые вирусы которые пытались (с переменным успехом) переживать мягкую (теплую) перезагрузку (ту которая скипает мемтест) юзая похожие фокусы.
     
     
  • 3.12, pavlinux (ok), 06:07, 23/09/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Никак. Дамп там *останется* с "прошлого" раза.

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

     

  • 1.7, pavlinux (ok), 02:21, 14/09/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Единственная хитрость - сначала нужно зарезервировать память в ядре.
    > Сделать это можно указав ядру параметр memmap=256K@0xfc0000 (резервируем 256К перед ядром).

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

         http://lxr.linux.no/#linux+v2.6.35/Documentation/kernel-parameters.txt#L1418

    > Если 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


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

     
     
  • 2.9, Аноним (-), 10:21, 14/09/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Рассчитано на мягкий ребут, вызванный крахом ядра. Память не очищается, соответственно старые данные остаются на том же месте, где и оставлены. После ребута посмотрите /dev/mem, много интересного из "прошлой жизни" найти можно.

     
     
  • 3.10, pavlinux (ok), 14:42, 14/09/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Вот что рассказал автор:

    [code]
    >>> 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
    [/code]

     

  • 1.8, stranger (??), 09:38, 14/09/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    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.
     


     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

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