Паника ядра, похоже, не связана с изменениями

Question

Я внес изменения в sched.c в ядре Linux 2.4 (домашнее задание), и теперь система впадает в панику ядра.Странная вещь:кажется, что он проходит МНОГО проверок загрузки и инициализации и паникует только в самом конце, показывая следующую трассировку стека:

update_process_times
do_timer
timer_interrupt
handle_IRQ_event
do_IRQ
call_do_IRQ
do)wp_page
handle_mm_fault
do_page_fault
do_sigaction
sys_rt_sigaction
do_page_fault
error_code

И ошибка:"В обработчике прерываний - нет синхронизации"

Я знаю, что это трудно сказать без кода, но может ли кто-нибудь сделать обоснованное предположение, чтобы указать мне правильное направление?

Answer 1

Я могу дать вам свою личную мантру при отладке проблем ядра:«это всегда твоя вина».

Я часто сталкиваюсь с проблемами, связанными с перезаписью памяти за пределами места, где я работаю — например, если я передаю аппаратному обеспечению неверный адрес для DMA.Возможно, вы каким-то образом портите замок;в данном случае это кажется возможным, если вы видите тайм-аут:забытый заблокированный замок приводит к тайм-ауту из-за зависания.

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

Имейте в виду, что что-то в ядре часто идет не так, как надо, задолго до того, как произойдет сбой, поэтому виноват может быть неверный бит в любом месте вашего кода, даже если кажется, что это не должно иметь эффекта.Если вы можете, я рекомендую постепенно добавлять или удалять ваш код и проверять наличие проблемы, чтобы увидеть, сможете ли вы ее изолировать.