代码之家 › 专栏 › 技术社区 › Matthew Smith

如何诊断内核OOP?

kernel debugging linux

Matthew Smith · 技术社区 · 16 年前

如果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 回复 | 直到 8 年前

Anthony Geoghegan 8 年前

OOPS提供了一系列有用的信息来诊断崩溃。它从崩溃的地址、原因(“进入坏区”)和寄存器的内容开始。电话追踪回答了“我们是怎么到这里的”这个问题。列表中的第一项发生在最近。向后工作,发生了中断( do_IRQ )因为Atheros WiFi适配器接收到一个数据包( ath_rx_poll )例程将其传递给通用WiFi代码( ieee80211_input )然后把它传给网络堆栈( netif_receive_skb )

要找出导致问题的确切代码,可以运行

gdb /usr/src/linux/vmlinux

然后分解所讨论的函数,可能是 mesh_packet_in() . 可能,因为错误指令(0xc50659ec)看起来不在 网格包 (0xC5065 F04)。您也可以尝试gdb命令

(gdb) info line 0xc50659ec

找出哪个函数包含这个地址。

Martin v. Löwis 16 年前

您应该首先尝试查找崩溃代码的源代码。在特定情况下,分析声称碰撞发生在manet驱动程序的mesh_packet_in中,偏移量为0x8f0。同时也报告了这一点的说明是419D02A09801009…因此,使用“objdump-d”检查模块,以确认报告的功能/偏移是否正确。然后检查源代码,了解它在做什么;您可以使用寄存器列表再次确认您正在查看正确的指令。

当您知道什么是C语句出错时,您需要读取源代码以找出伪数据来自何处。

Ana Betts 16 年前

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

将它安装到您的内核中,然后当它出错时,您将被抛出到一个类似gdb的接口中,您可以使用该接口进行浏览。然而,看起来manet模块的指针错误。