как вы диагностируете ядро ​​упс? - PullRequest
Новая
       35

как вы диагностируете ядро ​​упс?

18 голосов
/ 25 ноября 2008

Учитывая, что ядро ​​linux упс, как вы решаете проблему? В выводе я вижу трассировку стека, которая, кажется, дает некоторые подсказки. Есть ли инструменты, которые помогут найти проблему? Какие основные процедуры вы используете, чтобы отследить его? 


Unable to handle kernel paging request for data at address 0x33343a31
Faulting instruction address: 0xc50659ec
Oops: Kernel access of bad area, sig: 11 [#1]
tpsslr3
Modules linked in: datalog(P) manet(P) vnet wlan_wep wlan_scan_sta ath_rate_sample ath_pci wlan ath_hal(P)
NIP: c50659ec LR: c5065f04 CTR: c00192e8
REGS: c2aff920 TRAP: 0300   Tainted: P          (2.6.25.16-dirty)
MSR: 00009032   CR: 22082444  XER: 20000000
DAR: 33343a31, DSISR: 20000000
TASK = c2e6e3f0[1486] 'datalogd' THREAD: c2afe000
GPR00: c5065f04 c2aff9d0 c2e6e3f0 00000000 00000001 00000001 00000000 0000b3f9
GPR08: 3a33340a c5069624 c5068d14 33343a31 82082482 1001f2b4 c1228000 c1230000
GPR16: c60f0000 000004a8 c59abbe6 0000002f c1228360 c340d6b0 c5070000 00000001
GPR24: c2aff9e0 c5070000 00000000 00000000 00000003 c2cc2780 c2affae8 0000000f
NIP [c50659ec] mesh_packet_in+0x3d8/0xdac [manet]
LR [c5065f04] mesh_packet_in+0x8f0/0xdac [manet]
Call Trace:
[c2aff9d0] [c5065f04] mesh_packet_in+0x8f0/0xdac [manet] (unreliable)
[c2affad0] [c5061ff8] IF_netif_rx+0xa0/0xb0 [manet]
[c2affae0] [c01925e4] netif_receive_skb+0x34/0x3c4
[c2affb10] [c60b5f74] netif_receive_skb_debug+0x2c/0x3c [wlan]
[c2affb20] [c60bc7a4] ieee80211_deliver_data+0x1b4/0x380 [wlan]
[c2affb60] [c60bd420] ieee80211_input+0xab0/0x1bec [wlan]
[c2affbf0] [c6105b04] ath_rx_poll+0x884/0xab8 [ath_pci]
[c2affc90] [c018ec20] net_rx_action+0xd8/0x1ac
[c2affcb0] [c00260b4] __do_softirq+0x7c/0xf4
[c2affce0] [c0005754] do_softirq+0x58/0x5c
[c2affcf0] [c0025eb4] irq_exit+0x48/0x58
[c2affd00] [c000627c] do_IRQ+0xa4/0xc4
[c2affd10] [c00106f8] ret_from_except+0x0/0x14
--- Exception: 501 at __delay+0x78/0x98
    LR = cfi_amdstd_write_buffers+0x618/0x7ac
[c2affdd0] [c0163670] cfi_amdstd_write_buffers+0x504/0x7ac (unreliable)
[c2affe50] [c015a2d0] concat_write+0xe4/0x140
[c2affe80] [c0158ff4] part_write+0xd0/0xf0
[c2affe90] [c015bdf0] mtd_write+0x170/0x2a8
[c2affef0] [c0073898] vfs_write+0xcc/0x16c
[c2afff10] [c0073f2c] sys_write+0x4c/0x90
[c2afff40] [c0010060] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xfd98a50
    LR = 0x10003840
Instruction dump:
419d02a0 98010009 800100a4 2f800003 419e0508 2f170000 419a0098 3d20c507
a0e1002e 81699624 39299624 7f8b4800  419e007c a0610016 7d264b78
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 1 seconds..

Ответы [ 3 ]

20 голосов
/ 25 ноября 2008

Упс дает кучу информации, полезной при диагностике сбоя. Он начинается с адреса сбоя, причины («доступ к плохой зоне») и содержимого регистров. Трассировка звонка отвечает на вопрос «как мы сюда попали». Первый пункт в списке произошел совсем недавно. Работая в обратном направлении, произошло прерывание (do_IRQ), потому что WiFi-адаптер Atheros получил пакет (ath_rx_poll). Процедура передала его в общий код WiFi (ieee80211_input), который, в свою очередь, передал его в сетевой стек (netif_receive_skb).

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

gdb /usr/src/linux/vmlinux

и затем разберите соответствующую функцию, которая может быть mesh_packet_in(). Возможно, потому что ошибочная инструкция (0xc50659ec) выглядит за пределами mesh_packet_in() (0xc5065f04). Вы также можете попробовать команду gdb 

(gdb) info line 0xc50659ec

чтобы выяснить, какая функция содержит этот адрес.

5 голосов
/ 25 ноября 2008

Сначала вы должны попытаться найти источник сбойного кода. В конкретном случае анализ утверждает, что сбой произошел в mesh_packet_in драйвера manet со смещением 0x8f0. Он также сообщает, что инструкции на этом этапе являются 419d02a0 98010009 ... Поэтому проверьте модуль с помощью «objdump -d», чтобы убедиться в правильности сообщенной функции / смещения. Затем проверьте источник, что он делает; Вы можете использовать список регистров, чтобы еще раз подтвердить, что вы смотрите на правильную инструкцию.

Когда вы знаете, что утверждение C неверно, вам нужно прочитать исходный код, чтобы узнать, откуда поступали фиктивные данные.

1 голос
/ 25 ноября 2008

http://oss.sgi.com/projects/kdb/

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

...