在tmp目录下拷贝文件，超过一定大小内核崩溃

frank529

ARM架构，128M内存，Linux2.6.25，往tmp里面拷贝文件超过13M，就会kernel panic。另一个类似的芯片，同样128M内存，2.6.30的内核，同样的文件系统，就不会出现这样的问题。不知道有没有人碰到类似的问题，TMPFS内核代码没动过，两个用的是同样的文件系统，也就是说fstab配置一样，用mount改变tmpfs的大小也没用。这问题无从下手了。

打印内容如下：

1. 
   
2. Unable to handle kernel paging request at virtual address 0955e344
   
3. pgd = c6758000
   
4. [0955e344] *pgd=00000000
   
5. Internal error: Oops: 5 [#1]
   
6. Modules linked in:
   
7. CPU: 0    Not tainted  (2.6.25 #275)
   
8. PC is at __wake_up_common+0x1c/0x88
   
9. LR is at __wake_up+0x2c/0x34
   
10. pc : [<c003a240>]    lr : [<c003a2d8>]    psr: 00000093
    
11. sp : c7dd1c90  ip : 0955e338  fp : c7dd1cb8
    
12. r10: 00000003  r9 : 00000000  r8 : 000a2000
    
13. r7 : 00001000  r6 : c0000320  r5 : 00000000  r4 : 00000013
    
14. r3 : 00000000  r2 : 00000001  r1 : 00000003  r0 : 0955e344
    
15. Flags: nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
    
16. Control: c000317f  Table: 26758000  DAC: 00000015
    
17. Process cp (pid: 808, stack limit = 0xc7dd0260)
    
18. Stack: (0xc7dd1c90 to 0xc7dd2000)
    
19. 1c80:                                     00000013 00000000 c02f0000 00001000
    
20. 1ca0: 000a2000 00000000 00000000 c7dd1cd0 c7dd1cbc c003a2d8 c003a234 c7dd1cd4
    
21. 1cc0: c02f0000 c7dd1ce8 c7dd1cd4 c00518b0 c003a2bc c02f0000 00000000 c7dd1cfc
    
22. 1ce0: c7dd1cec c006368c c0051890 000a2000 c7dd1d24 c7dd1d00 c00a0970 c0063650
    
23. 1d00: c01a8054 000a1000 00000000 c7dd0000 00001000 00000000 c7dd1db4 c7dd1d28
    
24. 1d20: c006510c c00a087c 00001000 00001000 c02f0000 c0042490 c79e51c0 fefff000
    
25. 1d40: 00000001 00000003 c7dd1dcc c7dd1d58 c00215c8 00001000 00000000 c01a8054
    
26. 1d60: c79e5128 c01a8054 c79e51c0 c6ec1b80 c7dd1ea8 c0042490 c02f0000 c7dd1ea0
    
27. 1d80: 00000001 00000000 00001000 000a1000 00000000 000a2000 00000000 00000000
    
28. 1da0: c7dd1df4 c7dd1ea0 c7dd1e54 c7dd1dbc c0065d78 c0064f98 000a1000 00000000
    
29. 1dc0: c7dd1ef0 00001000 00000000 000a2000 00000000 000a1000 00000000 00000000
    
30. 1de0: c79e51c0 c6ec1b80 c7dd1ef0 c7dd1ea8 00001000 000a1000 00000000 00001000
    
31. 1e00: 00000001 c0097ea4 c00424ec 39e7f102 2e291624 00000000 c7dd1e94 c7dd1e28
    
32. 1e20: c00664ec c0097dd0 c7dd1e34 c7dd1ea8 c79e5128 000a1000 00000000 c7dd1ef0
    
33. 1e40: c7dd1ea0 c79e5194 c7dd1e94 c7dd1e58 c0065e2c c0065880 00000001 00001000
    
34. 1e60: c79e51c0 c6ec1b80 00000001 c7dd1ea8 c7dd1ef0 c6ec1b80 c7dd1f78 c7dd1ea0
    
35. 1e80: 00000000 00000001 c7dd1f50 c7dd1e9c c008425c c0065dbc 000a1000 00000000
    
36. 1ea0: bebda23c 00001000 c00376e4 c7dd1eac 00000000 00000001 ffffffff c6ec1b80
    
37. 1ec0: 00000000 00000000 00000000 00000000 c7c47600 00000000 00000000 c0053058
    
38. 1ee0: c7c47600 c0051764 c7dd1ee8 c7dd1ee8 000a1000 00000000 000b7b01 00000000
    
39. 1f00: c7dd1f40 c7dd1f10 00001000 00000041 c0224d40 0000000a c0224b20 00000000
    
40. 1f20: 00000000 00000001 00000001 c6ec1b80 bebda23c c7dd1f78 00001000 00000000
    
41. 1f40: c7dd0000 c7dd1f74 c7dd1f54 c0084370 c00841ac 00000000 c6ec1ba0 c6ec1b80
    
42. 1f60: c7dd1f78 000a1000 c7dd1fa4 c7dd1f78 c00844b4 c00842bc 000a1000 00000000
    
43. 1f80: 00000000 00001000 bebda23c 0000000b 00000004 c0021b04 00000000 c7dd1fa8
    
44. 1fa0: c0021960 c0084478 00001000 bebda23c 0000000b bebda23c 00001000 00000000
    
45. 1fc0: 00001000 bebda23c 0000000b 0000000b 00000000 0000000b 00000001 0000000a
    
46. 1fe0: 00000000 bebda218 000091c8 000f5d94 60000010 0000000b a66ebefa fffa7ebb
    
47. Backtrace:
    
48. [<c003a224>] (__wake_up_common+0x0/0x88) from [<c003a2d8>] (__wake_up+0x2c/0x34)
    
49. [<c003a2ac>] (__wake_up+0x0/0x34) from [<c00518b0>] (__wake_up_bit+0x30/0x38)
    
50. r4:c02f0000
    
51. [<c0051880>] (__wake_up_bit+0x0/0x38) from [<c006368c>] (unlock_page+0x4c/0x58)
    
52. [<c0063640>] (unlock_page+0x0/0x58) from [<c00a0970>] (simple_write_end+0x104/0x118)
    
53. r4:000a2000
    
54. [<c00a086c>] (simple_write_end+0x0/0x118) from [<c006510c>] (generic_file_buffered_write+0x188/0x63c)
    
55. r9:00000000 r8:00001000 r7:c7dd0000 r6:00000000 r5:000a1000
    
56. r4:c01a8054
    
57. [<c0064f88>] (generic_file_buffered_write+0x4/0x63c) from [<c0065d78>] (__generic_file_aio_write_nolock+0x508/0x538)
    
58. [<c0065870>] (__generic_file_aio_write_nolock+0x0/0x538) from [<c0065e2c>] (generic_file_aio_write+0x84/0x100)
    
59. [<c0065dac>] (generic_file_aio_write+0x4/0x100) from [<c008425c>] (do_sync_write+0xc0/0x110)
    
60. [<c008419c>] (do_sync_write+0x0/0x110) from [<c0084370>] (vfs_write+0xc4/0x148)
    
61. r9:c7dd0000 r8:00000000 r7:00001000 r6:c7dd1f78 r5:bebda23c
    
62. r4:c6ec1b80
    
63. [<c00842ac>] (vfs_write+0x0/0x148) from [<c00844b4>] (sys_write+0x4c/0x74)
    
64. r7:000a1000 r6:c7dd1f78 r5:c6ec1b80 r4:c6ec1ba0
    
65. [<c0084468>] (sys_write+0x0/0x74) from [<c0021960>] (ret_fast_syscall+0x0/0x2c)
    
66. r8:c0021b04 r7:00000004 r6:0000000b r5:bebda23c r4:00001000
    
67. Code: e1a06000 e5900000 e1a0a001 e240c00c (e59c100c)
    
68. ---[ end trace aa207d18a7df7e1d ]---
    
69. 
    

复制代码

zyr-linux

先去翻Linux2.6.25到2.6.30的changlog，

再怀疑下是不是内存剩余空间不足导致的。

cdtits

请问：你是如何改出问题的？

frank529

zyr-linux 发表于 2012-07-18 10:29
先去翻Linux2.6.25到2.6.30的changlog，

再怀疑下是不是内存剩余空间不足导致的。

changelog找不到了，kernel.org上只有2.6.13以前的changelog。另外我觉得虽然2.6.25不是稳定版，但也不至于出这么大的BUG吧。内存空间是足够的，有100多M的可用空间。

另回复楼上，直接在tmp下复制文件，超过13M就崩溃

cdtits

回复 4# frank529


    意思是说，没有修改任何代码，它就崩了

Godbach

回复 4# frank529
X86 下做过测试吗


   

zyr-linux

frank529 发表于 2012-07-18 16:12
changelog找不到了，kernel.org上只有2.6.13以前的changelog。另外我觉得虽然2.6.25不是稳定版，但也不 ...

这问题没遇到过，只能说说大概思路。

看出错信息是内存地址方面，很大可能是ramdisk，文件系统的话，可能性很小。

如果只为干活的话，直接上30好了，没那么多时间钻研的。

如果想深入研究，
出错信息配上版本号去搜，尤其是邮件list上；
changlog看看源代码document目录或者根目录，把25版本起到30版本的挨个看；
再不行，找各大发行版靠近的版本号对比可能的部分（文件系统，ramdisk）代码；
甚至修改copy源代码，记录到底拷到那儿去了；
等等等等……

wloveg

对比一下这两个内核的配置文件（.config），看看有没有tmpfs和内存相关的选项不一样，没准能找到点线索。

frank529

NND拖了这么久才发现问题根源，是UBOOT配置处理器的SDRAM控制器配错了，导致它实际使用的内存空间只有32M，而传给内核的参数是128M，所以才会发生崩溃。我就说内核不应该有这么大这么明显的BUG