kernel panic 分析讨论

kernelinside

background, arm, 2.6.35
如下，
pgd = c0004000
[00000000] *pgd=00000000
是不是说 pgd指针所指向的页目录表的第一个entry，
这第一个entry本来是指向pg0的地址的，但现在第一个entry指到了0x00000000了，所以出错了？

在system.map里：
80004000 A swapper_pg_dir

为什么我在system.map里没有发现pg0这个symbol呢，但x86的system.map里就有pg0.

1. Unable to handle kernel NULL pointer dereference at virtual address 00000000
   
2. pgd = c0004000
   
3. [00000000] *pgd=00000000
   
4. Internal error: Oops: 17 [#1] PREEMPT SMP
   
5. last sysfs file:
   
6. Modules linked in:
   
7. CPU: 0    Not tainted  (2.6.35.13_nl #1)
   
8. PC is at sock_no_sendpage+0x50/0x9c
   
9. LR is at sock_no_sendpage+0x3c/0x9c
   
10. pc : [<c028d44c>]    lr : [<c028d438>]    psr: 40000013
    
11. sp : dfd83d88  ip : 00000000  fp : dfd83ddc
    
12. r10: 00000000  r9 : 00000000  r8 : 00001000
    
13. r7 : dfd83d94  r6 : 00000000  r5 : df826680  r4 : 00000000
    
14. r3 : 00004040  r2 : c0416180  r1 : 00000680  r0 : df826680
    
15. Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
    
16. Control: 10c5387d  Table: 5f14c04a  DAC: 00000015
    
17. Process rpciod/0 (pid: 18, stack limit = 0xdfd822f0)
    
18. Stack: (0xdfd83d88 to 0xdfd84000)
    
19. 3d80:                   dfd82000 dfdd4030 dfd83dac 00000000 00000000 00000000
    
20. 3da0: 00000000 00000000 00000000 00004040 00000000 dfdd4000 00001000 dfdd4000
    
21. 3dc0: 00001000 00004040 ffffffa1 dfdd4000 dfd83e34 dfd83de0 c02dd208 c028d408
    
22. 3de0: 00004040 c00a9bb8 00000000 c02893d4 df826680 00001000 dfc1448c 00000000
    
23. 3e00: dfd83e1c dfd83e10 c009e818 df826680 00001000 00000000 00000000 dfdd4000
    
24. 3e20: 00001000 00004040 dfd83e64 dfd83e38 c02e4cf8 c02dd118 00004040 00000000
    
25. 3e40: 00001000 dfc1448c 00000000 df826680 00000000 0000007c dfd83ea4 dfd83e68
    
26. 3e60: c02fc0c0 c02e4c14 00004040 00000001 dfe85b04 00000000 c009e818 dfc14488
    
27. 3e80: dfc72800 dfe85a48 dfc144f8 dfc72ae0 dfd83f7c dfc14514 dfd83ecc dfd83ea8
    
28. 3ea0: c02fc3e8 c02fbf6c 00000000 dfc14488 dfc72800 dfc14488 dfe85a48 dfc144f8
    
29. 3ec0: dfd83efc dfd83ed0 c02fa2b8 c02fc3a8 2cd18c84 00000376 dfe85a48 dfc14488
    
30. 3ee0: dfc14488 c0433394 00000001 00000000 dfd83f24 dfd83f00 c02f731c c02fa1b4
    
31. 3f00: dfe85b70 c02fef94 dfe85a48 dfe85a48 dfe85a80 c0490e34 dfd83f54 dfd83f28
    
32. 3f20: c02fef94 c02f7120 00000001 c08bea00 dfd82000 00000000 dfe85a8c dfe85a90
    
33. 3f40: dfd83f7c c02ff1d0 dfd83f64 dfd83f58 c02ff1ec c02fef18 dfd83fbc dfd83f68
    
34. 3f60: c0075b00 c02ff1dc c0314d20 c0052aac dfc5b840 c08bea08 dfd83f94 00000000
    
35. 3f80: dfc5b840 c0079d4c dfd83f88 dfd83f88 c00506e8 dfc5de98 dfd83fc4 c0075974
    
36. 3fa0: c08bea00 00000000 00000000 00000000 dfd83ff4 dfd83fc0 c007982c c0075980
    
37. 3fc0: 00000000 00000000 00000000 00000000 dfd83fd0 dfd83fd0 dfc5de98 c00797a0
    
38. 3fe0: c00615f8 00000013 00000000 dfd83ff8 c00615f8 c00797ac 00000000 00000000
    
39. Backtrace:
    
40. [<c028d3fc>] (sock_no_sendpage+0x0/0x9c) from [<c02dd208>] (udp_sendpage+0xfc/0x174)
    
41. r8:dfdd4000 r7:ffffffa1 r6:00004040 r5:00001000 r4:dfdd4000
    
42. [<c02dd10c>] (udp_sendpage+0x0/0x174) from [<c02e4cf8>] (inet_sendpage+0xf0/0x118)
    
43. [<c02e4c08>] (inet_sendpage+0x0/0x118) from [<c02fc0c0>] (xs_sendpages+0x160/0x204)
    
44. [<c02fbf60>] (xs_sendpages+0x0/0x204) from [<c02fc3e8>] (xs_udp_send_request+0x4c/0x130)
    
45. [<c02fc39c>] (xs_udp_send_request+0x0/0x130) from [<c02fa2b8>] (xprt_transmit+0x110/0x200)
    
46. r7:dfc144f8 r6:dfe85a48 r5:dfc14488 r4:dfc72800
    
47. [<c02fa1a8>] (xprt_transmit+0x0/0x200) from [<c02f731c>] (call_transmit+0x208/0x27c)
    
48. [<c02f7114>] (call_transmit+0x0/0x27c) from [<c02fef94>] (__rpc_execute+0x88/0x2c4)
    
49. r6:c0490e34 r5:dfe85a80 r4:dfe85a48
    
50. [<c02fef0c>] (__rpc_execute+0x0/0x2c4) from [<c02ff1ec>] (rpc_async_schedule+0x1c/0x20)
    
51. [<c02ff1d0>] (rpc_async_schedule+0x0/0x20) from [<c0075b00>] (worker_thread+0x18c/0x224)
    
52. [<c0075974>] (worker_thread+0x0/0x224) from [<c007982c>] (kthread+0x8c/0x94)
    
53. [<c00797a0>] (kthread+0x0/0x94) from [<c00615f8>] (do_exit+0x0/0x68c)
    
54. r7:00000013 r6:c00615f8 r5:c00797a0 r4:dfc5de98
    
55. Code: e3a01d1a e59f204c e1a00005 e50b3030 (e5943000)
    
56. ---[ end trace e007c40f8ce37563 ]---

复制代码

active000

看不懂！

suiming2005

看宕机信息关键是看eip在哪里

jwwzhh

pgd = c0004000
[00000000] *pgd=00000000
它是由show_pte()函数打印出来的，只要你看明白了这个函数就明白了，不难的。

luoyan_xy

只从这两句话字面意思上看，是不是说 pgd对应的页目录表项的页表还没有建立？

Godbach

回复 1# kernelinside

典型的  NULL pointer 导致的 Oops。
你这块做了哪些改动啊？

Godbach

回复 1# kernelinside
以前记得有一个 sendfile 的 BUG，但是 2.6.35 应该已经修复了

kernelinside

回复 6# Godbach


   
没有做什么改动啊，每次panic的地方不一样，但好像都跟softirq有关系。
真头疼。

Godbach

回复 8# kernelinside

你使用的标准内核，没做任何改动，出现的这个 Oops 吗？
这个必现吗？

kernelinside

唔，打了一些patch,
现在是每次必现，
只要做反复的文件copy，类似于这样

while 1 ; do cp filea fileb done

每次crash的点不一样，但大多数发生在softirq处理过程中，这个处理过程会调用一系列的函数，发生crash的地点不同。

2.6.35 +　SMP + nfs

... ...