Содержимое регистров точно также полезно, хотя и используется не так часто. Вместе с дизассемблированным кодом функции содержимое регистров может помочь восстановить точную последовательность событий, которая привела к проблеме. Если значение в некотором регистре не соответствует ожидаемому, то это может пролить некоторый свет на корень проблемы. В данном случае можно проверить, какие регистры содержат значение NULL
(все разряды нулевые) и определить, какая из переменных функции содержит не то значение. В ситуациях, похожих на данную, скорее всего причина — конкуренция за ресурс (race) и скорее всего между таймером и другой частью сетевого адаптера. Отладка состояний конкуренции за ресурсы — всегда серьезная задача.
Только что рассмотренное сообщение oops
имеет так называемый декодированный вид, потому что адреса памяти транслированы в имена функций, которые им соответствуют. Не декодированный вид предыдущего сообщения выглядит следующим образом.
NIP: C013A7F0 LR: C013A7F0 SP: C0685E00 REGS: c0905d10 TRAP: 0700
Not tainted
MSR: 00089037 EE: 1 PR: 0 FP: 0 ME 1 IR/DR: 11
TASK = c0712530 [0] 'swapper' Last syscall: 120
GPR00: C013A7C0 C0295E00 C0231530 0000002F 00000001 C0380CB8 C0291B80 C02D0000
GPR08: 000012AD 00000000 00000000 C0292AA0 4020A088 00000000 00000000 00000000
GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
GPR24: 00000000 00000005 00000000 00001032 C3F7C000 00000032 FFFFFFFF C3F7C1C0
Call trace: [c013ab30] [c0020744] [c001b864] [c0007e80] [c00061c4]
[c0007b84] [c0007bf8] [c0003ae8]
Адреса обратной трассировки должны быть переведены в символические имена функций. Это можно сделать с помощью команды ksymoops
при наличии файла System.map
, который сгенерирован во время компиляции данного ядра. Если используются загружаемые модули ядра, то необходима также информация о модулях. Утилита ksymoops
пытается самостоятельно определить всю необходимую информацию, поэтому обычно ее можно просто вызывать следующим образом.
ksymoops saved_oops.txt
Программа выводит декодированную информацию сообщения oops
. Если информация, которая используется по умолчанию, недоступна, или есть необходимость указать альтернативное положение соответствующих информационных файлов, то на такой случай программа принимает различные параметры. Страницы руководства по данной программе, которые необходимо прочитать перед использованием, содержат всю необходимую информацию.
Программа ksymoops
включена в большинство поставок операционной системы Linux.
К счастью, больше нет необходимости использовать программу ksymoops
. Это очень полезно, потому что, хотя, у разработчиков обычно нет проблем с ее использованием, пользователи часто указывают неправильный файл System.map
, или неправильно декодируют сообщение oops
.
В разрабатываемой серии ядра 2.5 была введено новая возможность kallsyms
, которая включается с помощью конфигурационного параметра CONFIG_KALLSYMS
. Эта функция включает в исполняемый образ ядра информацию для отображения адресов памяти в соответствующие имена функций ядра, что дает возможность ядру самостоятельно декодировать информацию обратной трассировки. Следовательно, декодирование сообщений oops больше не требует файла System.map
, или утилиты kallsyms
. Как недостаток такого подхода следует отметить некоторое увеличение объема памяти, используемой ядром, так как таблица перевода адресов памяти в имена функций загружается в постоянно отображаемую память ядра. На такое увеличение объемов используемой памяти стоит пойти, по крайней мере, на этапе разработки ядра.
Конфигурационные параметры отладки ядра
Существует несколько конфигурационных параметров, которые помогают в отладке и тестировании кода ядра и которые включаются во время компиляции. Эти параметры доступны в пункте Kernel hackingменю редактора конфигурации ядра. Все эти параметры зависят от параметра CONFIG_DEBUG_KERNEL
. Для разработки кода ядра следует включать только те параметры, которые необходимы.
Некоторые из этих параметров достаточно полезны, такие как отладка работы со слябовым распределителем памяти (slab layer debugging), отладка работы с верхней памятью (high memory debugging), отладка работы с отображаемым на память вводом-выводом (I/O mapping debugging), отладка работы со спин-блокировками (spin-lock debugging) и проверка переполнения стека (stack overflow checking). Однако, один из самых полезных параметров — это проверка перехода в состояние ожидания при захваченной спин-блокировке ( sleep-inside-spinlock checking ), которая на самом деле выполняет значительно больше работы.
Читать дальше