В настоящее время я сталкиваюсь с какими-то уродливыми OPS-ядрами с перезагрузкой. Я использую индивидуальный дизайн на основе MPC5200. Я получаю сообщения OOPS, как это:
VM: Either in interrupt or mm = NULL. mm=0xc0196520 in interrupt: 1
VM: Access of bad area @0x6e615c75
Oops: kernel access of bad area, sig: 11
NIP: C00302E4 XER: 20000000 LR: C00F15D4 SP: C6207B30 REGS: c6207a80 TRAP: 0300 Not tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 6E615C75, DSISR: 20000000
TASK = c6206000[4778] 'SimpleServer2' Last syscall: 102
last math c6206000 last altivec 00000000
GPR00: 7C74696B C6207B30 C6206000 6E615C5D 00000000 00000000 C01BFE68 00000001
GPR08: F0000500 C7CD1600 FFFFFFE3 C7CD1600 00000001 10152540 10100000 10100000
GPR16: C01B0000 00000000 C6207E48 000016D0 00001032 06207BF0 00000000 C0005CC0
GPR24: C0006DCC C6207EA0 C01B0000 C0190000 C0190000 C01D0000 C56A2220 00000001
Call backtrace:
C0018034 C00F1608 C00F6738 C0017D08 C0006EFC C0005CC0 C6207EA0
C011040C C012FEC4 C00EDC7C C00EF078 C00EF518 C0005A7C 10089C18
1001DFAC 10015660 10000608 10003E68 1000804C 10085A0C 100BC020
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
<0>Rebooting in 1 seconds..
Эти трассировки OOPS происходят во время высокой нагрузки сети.
Основная проблема, с которой я столкнулся, заключается в том, что функция do_page_fault вызывается механизмом исключений mmu, и поэтому контекст стека в gdb не является надежным. После отладки и добавления распечаток я понял, что процессор, кажется, находится в контексте прерывания. И поэтому эта ошибка не может быть исправлена.
Насколько я понимаю, трассировка OOPS адрес, который вызывает oops, сохраняется в регистре DAR: DAR: 6E615C75.
Как я могу получить информацию с этого адреса? Я пытался разобрать адрес в GDB, но он не сопоставлен ни с одной функцией.
Если кто-то интересуется форматом OOPS, он генерируется устаревшим ядром ядра 2.4.25, но я думаю, что механизм должен быть таким же, как в ядре 2.6.