Sistem file Linux 2.6 jffs2, penggunaan mount / umount yang berulang untuk kartu SD hang kernel

Menggunakan sistem file jffs2

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

Ketika perintah [mount] dan [umount] digunakan berulang kali, terkadang kernel akan hang.

Dan tidak ada hitungan yang jelas untuk berapa banyak pengulangan. Itu dapat berjalan 1000 kali tanpa kesalahan, atau akan bertahan pada kali ke-300. Tapi sebagian besar ada di angka tinggi (200 ++ mungkin) Tertangkap kesalahan ini 5 kali sekarang.

Jika ada yang bisa membantu saya menguraikan log ini, atau tahu di mana memperbaikinya, saya pikir masalahnya mungkin di [umount].

===== Ini adalah log yang keluar (kurang lebih) =====

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)

Mungkin jika seseorang tahu apa arti garis di bawah ini, itu akan sangat membantu. [sddrv_irq] adalah fungsi yang saya gunakan untuk menangani interupsi kartu sd. Jadi saya kira saya mengacaukan suatu tempat dalam menangani interupsi. saya tidak bisa menunjukkan di mana dengan log ini.

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

Pertama, bukan berarti masalah penguncian lunak sama sekali tidak jarang .

Sebagaimana dinyatakan di Wikipedia:

Frasa komputasi "permintaan interupsi" (atau IRQ) digunakan untuk merujuk pada tindakan mengganggu jalur bus yang digunakan untuk memberi sinyal interupsi, atau jalur input interupsi pada Programmable Interrupt Controller (PIC).

Wikipedia juga mencantumkan masalah menarik di JFFS2:

Semua node masih harus dipindai pada waktu mount. Ini lambat dan menjadi masalah yang semakin serius karena perangkat flash ditingkatkan ke dalam kisaran Gigabyte.

Teori saya adalah bahwa itu adalah batasan sistem file, dan itu membanjiri perangkat keras dengan terlalu banyak permintaan untuk membaca dari kartu SD Anda, tergantung pada ukurannya.

Tapi sekali lagi, saya tidak bisa mengatakan saya tahu apa-apa tentang sistem file, jadi ini mungkin didasarkan pada beberapa poin.