Mips Linux: регистрация паники ядра в разделе mtd

Вы можете включить модуль mtdoops в ядре и записывать трассировки паники ядра в раздел mtd. Я не думаю, что мы можем написать трассировку паники через NFS. Тем не менее, вы можете захотеть узнать о ramoops.

Ниже приведены шаги по настройке ядра для записи операций ядра на флэш-память mtd. Захват трассировки стека после паники ядра имеет неоценимое значение для отладки проблем ядра, особенно тех, которые возникают в полевых условиях. Во время инициализации модуля mtdoops раздел mtd превращается в кольцевой буфер и предварительно стирается.

1. Флаг ядра CONFIG_MTD_OOPS настраивает ядро ​​на запись трассировки стека oops в раздел MTD. Эта информация о разделе MTD dev может быть жестко запрограммирована внутри модуля mtdoops или может быть указана динамически. Этот компонент может быть собран как часть ядра или как отдельный модуль. Перед сборкой ядра вам необходимо убедиться, что ваше mtd-устройство зарегистрировало обработчик panic_write. Помните, что обычного обработчика записи mtd будет недостаточно, так как нам придется писать в память mtd после паники ядра. Запустите этот патч, если устройство mtd не иметь собственный обработчик паники.

   При сборке как части ядра CONFIG_MTD_OOPS=y модуль mtdoops необходимо исправить с помощью информации о разделе флэш-памяти (mtddev).

--- ./drivers/mtd/mtdoops.c.orig 2014-11-17 12:06:59.000000000 +0000
+++ ./drivers/mtd/mtdoops.c 2014-11-17 12:07:36.000000000 +0000
@@ -44,7 +44,7 @@
MODULE_PARM_DESC(record_size,
"record size for MTD OOPS pages in bytes (default 4096)");

-static char mtddev[80];
+static char mtddev[80]="/dev/oops";
module_param_string(mtddev, mtddev, 80, 0400);
MODULE_PARM_DESC(mtddev,
"name or index number of the MTD device to use");

При сборке в виде модуля CONFIG_MTD_OOPS=m информация о разделе флеш-памяти предоставляется динамически во время установки модуля (insmod).

insmod mtdoops.ko mtddev=/dev/oops

В дополнение к включению флагов MTP OOPS, настройте CONFIG_MAGIC_SYSRQ, чтобы вызвать панику и протестировать эту функцию.

2. Теперь нам нужно создать раздел MTD (/dev/Oops) для хранения трассировок паники. MTD можно разбить на разделы, изменив структуру памяти и информацию о разделах, определенную в исходных текстах ядра в arch///.c. Кроме того, вы должны знать, что информация о разделе, передаваемая как часть командной строки ядра, переопределяет изменения board.c.

{
.name = "loader",
.size = 0x000E0000,
.offset = MTDPART_OFS_APPEND
},
{
.name = "kernel",
.size = 0x002A0000,
.offset = MTDPART_OFS_APPEND
},
{
.name = "oops",
.size = 0x000E0000,
.offset = MTDPART_OFS_APPEND
},
{
.name = "all",
.size = MTDPART_SIZ_FULL,
.offset = 0x00000000
},

3. Соберите ядро, и mtdoops.ko будет собран как часть корневой файловой системы. Установите файловую систему и убедитесь, что раздел создан.

cat /proc/mtd
dev: size erasesize name
mtd0: 000e0000 00020000 "loader"
mtd1: 002a0000 00020000 "kernel"
mtd3: 000e0000 00020000 "Oops"
mtd5: 08000000 00020000 "all"

4. Теперь вызовите панику с помощью ключей Magic SysRq и просмотрите журналы паники ядра в разделе Oops.

Большое спасибо за подробные шаги. Вроде все нормально, кроме имени устройства. Когда я даю имя устройства как «/dev/oops», mtdoops не привязывается ни к какому устройству в загрузочном сообщении. После некоторого уровня отладки я обнаружил, что имя устройства должно быть просто «oops» или «номер раздела», т.е. (если ваш раздел oops — mtd9, просто укажите «9» в качестве номера раздела). После замены он начал работать. Я могу просматривать журналы с помощью sp-oops-extract.