Использование файловой системы jffs2
mount /mnt/sd/
umount /mnt/sd/
Когда команды [mount] и [umount] используются повторно, иногда ядро зависает.
И нет точного подсчета, сколько повторений. Он может работать без ошибок 1000 раз или зависнет в 300-й раз. Но в основном это на высоких цифрах (200++, может быть). Поймал эту ошибку 5 раз сейчас.
Если кто-то может помочь мне расшифровать этот журнал или знает, где это исправить, я думаю, что проблема может быть в [umount].
===== Это был журнал, который вышел (более или менее) =====
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)
Может быть, если кто-то знает, что означает строка ниже, это будет очень полезно. [sddrv_irq] - это функция, которую я использовал для обработки прерываний SD-карты. Так что, думаю, я кое-где перепутал при обработке прерывания. я просто не могу точно определить, где этот журнал.
PC is at __delay+0x0/0xc
LR is at sddrv_irq+0x3c8/0x4d4 [sddrv]