请教：如何根据dug 信息 定位段错误的位置？

s.t_seeyou

经常会出现，系统挂掉的现象，大多是因为段错误，是因为指针不正确而造成的，有时可以一下子找到，有时花很长时间也没办法，可能是没有找到方法，请大家指点一下，
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 17 [#1]
Modules linked in: rt73
CPU: 0
PC is at uplink_bw_limit+0xec/0x23c [rt73]
LR is at uplink_bw_limit+0x68/0x23c [rt73]
pc : [<bf040630>]    lr : [<bf0405ac>]    Not tainted
sp : c02a9d5c  ip : 00000000  fp : c02a9d78
r10: 00000000  r9 : 00000001  r8 : bf058ae8
r7 : c391e400  r6 : bf058b70  r5 : c3df7a40  r4 : c39b2ec0
r3 : 00000000  r2 : aaaaaaab  r1 : 00000000  r0 : 555f8180
Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  Segment kernel
Control: C000717F  Table: 23EB0000  DAC: 00000017
Process swapper (pid: 0, stack limit = 0xc02a8194)
Stack: (0xc02a9d5c to 0xc02aa000)
9d40:                                                                c3df7a40
9d60: c3df7a40 c4a81000 bf052550 c02a9d98 c02a9d7c bf01979c bf040554 c3df7a40
9d80: c391e400 00000000 c3dd0ba0 c02a9da8 c02a9d9c bf000f1c bf01976c c02a9dc8
9da0: c02a9dac c0204d68 bf000f1c c391e400 c3df7a40 00000000 c391e400 c02a9de4
9dc0: c02a9dcc c01f6cb8 c0204c8c c3df7a40 c3dd00a0 c3e0be20 c02a9e1c c02a9de8
9de0: bf03e8ec c01f6bcc c391e400 c02a9e1c c02a9dfc c02a9e24 00000022 00000073
9e00: fffffffe bf058ae8 00000025 0000000c c02a9ea4 c02a9e20 bf03fb54 bf03e6d0
9e20: c3e0be20 25430c00 00010073 7325430c 06040100 04000000 49420e0c 332d434f
9e40: 30322d54 00003232 00000000 00000000 00000000 00000000 00000000 00000000
9e60: 00000000 00000000 00000000 00000000 00000000 00000000 c0020000 bf058b40
9e80: 00000100 bf040108 c0324b44 c02a9ed0 c02ab2dc 00000000 c02a9eb8 c02a9ea8
9ea0: bf03fc94 bf03f9d4 bf058ae8 c02a9ecc c02a9ebc bf04011c bf03fc84 c02a8000
9ec0: c02a9f04 c02a9ed0 c0042010 bf040118 bf058b80 bf058b80 c3e0af40 00000001
9ee0: c03248c8 c02a8000 0000000a c03248a0 41129200 2001eee0 c02a9f28 c02a9f08
9f00: c003da28 c0041ea8 c02a9f50 fefff000 00000001 c0343330 2001ef10 c02a9f38
9f20: c02a9f2c c003dbb4 c003d9dc c02a9f4c c02a9f3c c0024cd0 c003db80 ffffffff
9f40: c02a9fa4 c02a9f50 c0023904 c0024c70 00000000 c3914000 00010000 60000013
9f60: c00254ac c02a8000 c02ab2e4 c0343330 2001ef10 41129200 2001eee0 c02a9fa4
9f80: c02a9fa8 c02a9f98 c00254e8 c00254f4 60000013 ffffffff c02a9fc0 c02a9fa8
9fa0: c0025554 c00254bc c0007175 c031c878 c03270dc c02a9fd0 c02a9fc4 c0023024
9fc0: c002550c c02a9ff4 c02a9fd4 c0008978 c0023010 c0008514 c031ee68 c0007175
9fe0: c031eddc c02ab010 00000000 c02a9ff8 20008094 c0008810 00000000 00000000
Backtrace:
[<bf040544>] (uplink_bw_limit+0x0/0x23c [rt73]) from [<bf01979c>] (RTMPSendPackets+0x40/0x370 [rt73])
r7 = BF052550  r6 = C4A81000  r5 = C3DF7A40  r4 = C3DF7A40
[<bf01975c>] (RTMPSendPackets+0x0/0x370 [rt73]) from [<bf000f1c>] (usb_rtusb_sendpkt+0x10/0x14 [rt73])
r7 = C3DD0BA0  r6 = 00000000  r5 = C391E400  r4 = C3DF7A40
[<bf000f0c>] (usb_rtusb_sendpkt+0x0/0x14 [rt73]) from [<c0204d68>] (qdisc_restart+0xec/0x1dc)
[<c0204c7c>] (qdisc_restart+0x0/0x1dc) from [<c01f6cb8>] (dev_queue_xmit+0xfc/0x224)
r7 = C391E400  r6 = 00000000  r5 = C3DF7A40  r4 = C391E400
[<c01f6bbc>] (dev_queue_xmit+0x0/0x224) from [<bf03e8ec>] (rmtmng_send_msg+0x22c/0x288 [rt73])
r6 = C3E0BE20  r5 = C3DD00A0  r4 = C3DF7A40
[<bf03e6c0>] (rmtmng_send_msg+0x0/0x288 [rt73]) from [<bf03fb54>] (rmtMngCPETwoMacRegReqSend+0x190/0x1a8 [rt73])
[<bf03f9c4>] (rmtMngCPETwoMacRegReqSend+0x0/0x1a8 [rt73]) from [<bf03fc94>] (rmtmng_reg_request_send+0x20/0x40 [rt73])
[<bf03fc74>] (rmtmng_reg_request_send+0x0/0x40 [rt73]) from [<bf04011c>] (rmtmng_reg_timeout+0x14/0x30 [rt73])
r4 = BF058AE8
[<bf040108>] (rmtmng_reg_timeout+0x0/0x30 [rt73]) from [<c0042010>] (run_timer_softirq+0x178/0x1f4)
r4 = C02A8000
[<c0041e98>] (run_timer_softirq+0x0/0x1f4) from [<c003da28>] (__do_softirq+0x5c/0xd0)
[<c003d9cc>] (__do_softirq+0x0/0xd0) from [<c003dbb4>] (irq_exit+0x44/0x4c)
r8 = 2001EF10  r7 = C0343330  r6 = 00000001  r5 = FEFFF000
r4 = C02A9F50
[<c003db70>] (irq_exit+0x0/0x4c) from [<c0024cd0>] (asm_do_IRQ+0x70/0x84)
[<c0024c60>] (asm_do_IRQ+0x0/0x84) from [<c0023904>] (__irq_svc+0x24/0x60)
r4 = FFFFFFFF
[<c00254ac>] (default_idle+0x0/0x50) from [<c0025554>] (cpu_idle+0x58/0x84)
[<c00254fc>] (cpu_idle+0x0/0x84) from [<c0023024>] (__init_end+0x24/0x2c)
r6 = C03270DC  r5 = C031C878  r4 = C0007175
[<c0023000>] (__init_end+0x0/0x2c) from [<c0008978>] (start_kernel+0x178/0x1bc)
[<c0008800>] (start_kernel+0x0/0x1bc) from [<20008094>] (0x20008094)
Code: e5933000 e3130001 1a000017 e595302c (e5d33000)
<0>Kernel panic - not syncing: Aiee, killing interrupt handler!

emmoblin

你是2.4吧？
2.6的coredump信息可以自动解析符号的。

如果只有地址的话，就需要cat /proc/kerallsym 导出符号表，一点一点缩小地址范围了。

s.t_seeyou

2.6的，我用arm-linux-objdump虽然能定位置, 反汇编，看了更傻眼了，只好printk了，挨，汇编啊