Отладка ядра для зависания процесса?

Question

Я пытаюсь отладить драйвер устройства, который, по-видимому, вызывает другую задачу . Детерминировано, что какая задача или в какое время будет висеть .

В основном у меня появилось сообщение об ошибке из ядра, в котором говорилось, что «задача имеет заблокирована более 120 секунд», а также некоторые трассировки стека. нависшая задача варьируется от Sendmail до МКФСА к pdflush (ядра нити». И верхней функции трассировки стеки отличаться от„getnstimeofday“ на„bio_submit“на„mark_locks_held“.

Я с трудом так как очень сложно найти проблему . Трассировка стека, предоставляемая ядром, не очень полезна . В соответствии с этими трассировками стека некоторые из этих зависающих процессов даже не пытаются захватить блокировку (например, в функция getnstimeofday ), и я понятия не имею, почему они висят.

Так что мне интересно, есть ли у кого-нибудь идея о том, как отладить такую ​​проблему . Будет ли полезно использовать kgdb здесь, может быть, давая мне именно то, что указывает, что процесс зависает, и какой замок он ждет?

Любые предложения приветствуются.

Answer 1

Если в ядре нет указателей на ядро, трассировки стека не будут надежными, и это вас смущает. Ядро прибегает к сканированию всего стека для значений, которые могут быть указателями на код ядра (т. Е. Потенциальные обратные адреса). Это означает, что предыдущие вызовы функций, которые уже были возвращены, могут быть напечатаны.

Если у вас код, который выглядит следующим образом:

void A(void) { 
    printk("foo\n"); 
} 

void B(void) { 
    int x; 
    A(); 
} 

void crash(void) { 
    char buf[32]; 
    *(int*)0 = 0; 
} 

void trouble(void) { 
    int x; 
    B(); 
    crash(); 
} 

Ваш стек дампа может появиться что-то вроде:

printk 
A 
crash 
foo 
trouble 
... 

А как отлаживать вашу проблему, у меня есть два предложения:

1. Зная, что некоторые из результатов отладки плохие, используйте свои знания кода, чтобы выяснить, реальный call стек. Это может помочь найти общие функции в нескольких дампах стека.

2. Перекомпилируйте ядро ​​для использования указателей на рамки.

Ядро по-прежнему печатает каждое значение, которое выглядит как обратный адрес, но будет обозначать ненадежные адреса с помощью «?». Таким образом, ваш дамп вашего стека может выглядеть следующим образом:

? printk 
? A 
crash 
? foo 
trouble