Sistema de arquivos Linux 2.6 jffs2, uso repetido de mount / umount para o cartão SD trava o kernel

0

Usando um sistema de arquivos jffs2

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

Quando o comando [mount] e [umount] é usado repetidamente, às vezes o kernel trava.

E não há contagem clara de quantas repetições. Pode ser executado 1000 vezes sem erro ou será interrompido pela 300ª vez. Mas principalmente é nos números altos (200 ++ talvez). Peguei esse erro 5 vezes agora.

Se alguém puder me ajudar a decifrar este log, ou souber onde consertar isso, estou pensando que o problema pode estar em [umount].

===== Este foi o log que saiu (mais ou menos) =====

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)

Talvez, se alguém souber o que a linha abaixo significa, será uma grande ajuda. [sddrv_irq] é a função que eu usei para lidar com interrupções de cartão sd. Então eu estou supondo que eu estraguei um pouco onde lidar com a interrupção. Eu simplesmente não posso apontar onde com este log.

PC is at __delay+0x0/0xc
LR is at sddrv_irq+0x3c8/0x4d4 [sddrv]
    
por Naze Kimi 10.06.2011 / 09:56