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, 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, 22:58, 13/09/2010 [^] [ответить] [смотреть все]
  • +/
    # CONFIG_STRICT_DEVMEM is not set

    Ась?

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

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

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

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

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

     
  • 1.7, pavlinux, 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 [^] [ответить] [смотреть все]  
  • +/
    Рассчитано на мягкий ребут, вызванный крахом ядра Память не очищается, соответс... весь текст скрыт [показать]
     
     
  • 3.10, pavlinux, 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:      
    Заголовок:
    Текст:



      Закладки на сайте
      Проследить за страницей
    Created 1996-2017 by Maxim Chirkov  
    ДобавитьРекламаВебмастеруГИД  
    Hosting by Ihor