Hệ thống tập tin Linux 2.6 jffs2, sử dụng lặp lại mount / umount cho thẻ SD treo kernel

Sử dụng hệ thống tập tin jffs2

mount /mnt/sd/
umount /mnt/sd/

Khi lệnh [mount] và [umount] được sử dụng nhiều lần, đôi khi kernel sẽ bị treo.

Và không có số lượng rõ ràng cho bao nhiêu lần lặp lại. Nó có thể chạy 1000 lần mà không có lỗi, hoặc sẽ bị treo ở lần thứ 300. Nhưng chủ yếu là số lượng cao (200 ++ có thể). Bắt lỗi này 5 lần.

Nếu bất cứ ai có thể giúp tôi giải mã nhật ký này hoặc biết nơi khắc phục sự cố này, tôi nghĩ vấn đề có thể nằm ở [umount].

===== Đây là nhật ký xuất hiện (ít nhiều) =====

BUG: soft lockup - CPU#0 stuck for 11s! [swapper:0]

Pid: 0, comm:              swapper
CPU: 0    Not tainted  (2.6.24-1-MyProgram #503)
PC is at __delay+0x0/0xc
LR is at sddrv_irq+0x3c8/0x4d4 [sddrv]
pc : [<c022cd90>]    lr : [<bf020c68>]    psr: 20000013
sp : c03ddd40  ip : 00000000  fp : c03ddd8c
r10: 80000003  r9 : c03dc000  r8 : 00000943
r7 : c03ddd58  r6 : 00000007  r5 : c11d1e64  r4 : c1158da0
r3 : c03ddd68  r2 : 000001e7  r1 : c03ddd74  r0 : 00000071
Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 4000317f  Table: c11c4000  DAC: 00000017
[<c013b3f0>] (show_regs+0x0/0x50) from [<c0175e7c>] (softlockup_tick+0xf4/0x140)
 r4:00001c6d
[<c0175d88>] (softlockup_tick+0x0/0x140) from [<c015ba34>] (run_local_timers+0x18/0x1c)
[<c015ba1c>] (run_local_timers+0x0/0x1c) from [<c015bac0>] (update_process_times+0x38/0x60)
[<c015ba88>] (update_process_times+0x0/0x60) from [<c013de94>] (timer_tick+0xd0/0xf0)
 r6:00000000 r5:00000000 r4:c0412f70
[<c013ddc4>] (timer_tick+0x0/0xf0) from [<c0143a60>] (lh7a40x_timer_interrupt+0x38/0x6c)
 r5:00000000 r4:c0412f70
[<c0143a28>] (lh7a40x_timer_interrupt+0x0/0x6c) from [<c0176198>] (handle_IRQ_event+0x44/0x80)
 r4:c03ea918
[<c0176154>] (handle_IRQ_event+0x0/0x80) from [<c0177e7c>] (handle_level_irq+0xb0/0x154)
 r7:00020106 r6:c03ea918 r5:00000033 r4:c03f0548
[<c0177dcc>] (handle_level_irq+0x0/0x154) from [<c0139048>] (__exception_text_start+0x48/0x64)
 r6:c03dddf0 r5:c03f0548 r4:00000033
[<c0139000>] (__exception_text_start+0x0/0x64) from [<c0139958>] (__irq_svc+0x38/0xac)
Exception stack(0xc03ddcf8 to 0xc03ddd40)
dce0:                                                       00000071 c03ddd74
dd00: 000001e7 c03ddd68 c1158da0 c11d1e64 00000007 c03ddd58 00000943 c03dc000
dd20: 80000003 c03ddd8c 00000000 c03ddd40 bf020c68 c022cd90 20000013 ffffffff
 r6:00000001 r5:f8008000 r4:ffffffff
[<bf0208a0>] (sddrv_irq+0x0/0x4d4 [sddrv]) from [<c0176198>] (handle_IRQ_event+0x44/0x80)
[<c0176154>] (handle_IRQ_event+0x0/0x80) from [<c0177e7c>] (handle_level_irq+0xb0/0x154)
 r7:00010105 r6:c1167540 r5:00000036 r4:c03f05f0
[<c0177dcc>] (handle_level_irq+0x0/0x154) from [<c0139048>] (__exception_text_start+0x48/0x64)
 r6:c03dde98 r5:c03f05f0 r4:00000036
[<c0139000>] (__exception_text_start+0x0/0x64) from [<c0139958>] (__irq_svc+0x38/0xac)
Exception stack(0xc03dddf0 to 0xc03dde38)
dde0:                                     00000034 c1139500 c03dc000 60000013
de00: c1139500 00000034 c1139500 00000034 00000103 c03dc000 00000000 c03dde54
de20: c03dde58 c03dde38 c0177e7c c0176180 60000013 ffffffff
 r6:00000001 r5:f800a000 r4:ffffffff
[<c0176154>] (handle_IRQ_event+0x0/0x80) from [<c0177e7c>] (handle_level_irq+0xb0/0x154)
 r7:00000104 r6:c1139500 r5:00000034 r4:c03f0580
[<c0177dcc>] (handle_level_irq+0x0/0x154) from [<c0139048>] (__exception_text_start+0x48/0x64)
 r6:c03ddf40 r5:c03f0580 r4:00000034
[<c0139000>] (__exception_text_start+0x0/0x64) from [<c0139958>] (__irq_svc+0x38/0xac)
Exception stack(0xc03dde98 to 0xc03ddee0)
de80:                                                       00000000 c03dc000
dea0: 00000103 20000013 c0411940 00000002 0000000a c0411940 00000001 c0412c30
dec0: 00000000 c03ddf0c c03ddee0 c03ddee0 c01570d8 c01570e8 20000013 ffffffff
 r6:00000001 r5:f8008000 r4:ffffffff
[<c0157098>] (__do_softirq+0x0/0xd0) from [<c0157564>] (irq_exit+0x44/0x58)
[<c0157520>] (irq_exit+0x0/0x58) from [<c013904c>] (__exception_text_start+0x4c/0x64)
[<c0139000>] (__exception_text_start+0x0/0x64) from [<c0139958>] (__irq_svc+0x38/0xac)
Exception stack(0xc03ddf40 to 0xc03ddf88)
df40: 00000001 c03dc000 00000001 60000013 c013b578 c03dc000 c013b578 c04005a8
df60: c001d2ac 41029220 c001d278 c03ddf94 c03ddf98 c03ddf88 c013b5b8 c013b5c4
df80: 60000013 ffffffff
 r6:00000001 r5:f800a000 r4:ffffffff
[<c013b578>] (default_idle+0x0/0x54) from [<c013b39c>] (cpu_idle+0x40/0x6c)
[<c013b35c>] (cpu_idle+0x0/0x6c) from [<c0344970>] (rest_init+0x64/0x74)
 r7:c03dfcf8 r6:c0136f88 r5:c0400168 r4:c041429c
[<c034490c>] (rest_init+0x0/0x74) from [<c0008bd8>] (start_kernel+0x244/0x2b0)
[<c0008994>] (start_kernel+0x0/0x2b0) from [<c0008034>] (__enable_mmu+0x0/0x2c)

Có lẽ nếu ai đó biết dòng dưới đây có nghĩa là gì, nó sẽ là một trợ giúp tuyệt vời. [sddrv_irq] là chức năng tôi đã sử dụng để xử lý các ngắt thẻ sd. Vì vậy, tôi đoán tôi đã nhầm lẫn một số nơi trong việc xử lý ngắt. tôi chỉ không thể xác định chính xác nơi với nhật ký này.

PC is at __delay+0x0/0xc
LR is at sddrv_irq+0x3c8/0x4d4 [sddrv]

Đầu tiên, không phải là vấn đề khóa mềm không phải là hiếm .

Như đã nêu trên Wikipedia:

Cụm từ điện toán "yêu cầu ngắt" (hoặc IRQ) được sử dụng để chỉ hành động làm gián đoạn các tuyến xe buýt được sử dụng để báo hiệu ngắt hoặc các dòng đầu vào ngắt trên Bộ điều khiển ngắt lập trình (PIC).

Wikipedia cũng liệt kê một vấn đề thú vị trong JFFS2:

Tất cả các nút vẫn phải được quét tại thời điểm gắn kết. Điều này là chậm và đang trở thành một vấn đề ngày càng nghiêm trọng khi các thiết bị flash mở rộng lên phạm vi Gigabyte.

Lý thuyết của tôi là nó là một giới hạn hệ thống tập tin và nó đang tràn ngập phần cứng với quá nhiều yêu cầu đọc từ thẻ SD của bạn, tùy thuộc vào kích thước của nó.

Nhưng một lần nữa, tôi không thể nói rằng tôi biết bất cứ điều gì về các hệ thống tệp, vì vậy điều này có thể không dựa trên một số điểm.