Как отлаживать ошибки страниц в ядре Linux - PullRequest
2 голосов
/ 12 мая 2011

В настоящее время я сталкиваюсь с какими-то уродливыми 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.

Ответы [ 2 ]

3 голосов
/ 12 мая 2011

По определению, если вы столкнулись с ошибкой по этому адресу в контексте прерывания, в этом нет ничего полезного (т. Е. Нет смысла пытаться выяснить данные, на которые указывает неверный указатель). Вам нужно разобрать код, ведущий к NIP (C00302E4), и посмотреть, откуда он получил этот адрес и что он пытался сделать.

2 голосов
/ 17 мая 2011

Обратите внимание, что значение в DAR выглядит подозрительно как фрагмент строки ASCII.На самом деле, это выглядит как смещение 24 от значения в GPR03, 0x6E615C5D == "na\]".

Я подозреваю, что у вас есть строка, переполняющая указатель struct, и ошибочная инструкция разыменовывает элементта структура, которая находится по смещению 24.

...