2013-03-28 3 views
0

У меня есть драйвер ввода-вывода: виртуальное устройство ethernet. После некоторого периода работы ОС зависает, поэтому похоже, что у меня есть тупик в моем драйвере.

я сделал следующие шаги:
- соединяет два Макбуксы через FireWire
- настроить среду отладки
- инициализирует NMI (с помощью кнопки питания)
- подключение к цели с помощью GDB
- захватить адрес my kext
- создавать и загружать символы (это последний пункт во всех документах, которые я прочитал)
Пока все хорошо. В случае паники ядра этого было бы достаточно. Но в моем случае нет явной паники и я живу в потоке, который обрабатывает NMI.

Теперь вопрос: как я могу переключиться на поток моего kext?
Команда showalltasks дает мне список всех задач, единственная задача, в которой мой kext может работать, - это kernel_task, поэтому я пытаюсь изучить эту задачу с помощью showtaskthreads и showtaskstacks, но не могу найти ничего похожего на мой код. Я что-то упускаю?

Буду признателен за любые предложения или ссылки на документы.Отладка kext с gdb: deadlock

ответ

0

Ну, я отвечаю на свой вопрос.
Чтобы просмотреть поток, используя код моего kext Мне нужно переключиться на процесс, используя мой kext. В моем случае это будет, вероятно, браузер (так как мой kext - это NKE).

Но на самом деле это не очень помогло мне. Но старый метод печати помог мне найти тупик. Поэтому мой совет следующий: для паники ядра - используйте отладчик, для тупика - используйте печать, найдите место, где блокировка и анализ кода.

0

Я не отвечаю на ваш вопрос напрямую - но можно ли ударить ваш код kext точкой останова? Общим методом отладки ядра является nmi машина, приложить отладчик, поставить точку останова в код интереса, возобновить выполнение (continue), а затем сделать все, что необходимо для достижения точки останова.

+0

Спасибо за совет, но это не поможет: после тупика я не могу продолжить исполнение, прежде чем ... ну, как правило, он работает нормально около часа или двух, так что это не так – cody

Смежные вопросы