Linux 2.6 jffs2 filesystem, repeated usage of mount/umount for the SD card hangs the kernel

Question

Using a jffs2 filesystem

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

When the [mount] and [umount] command is repeatedly used, sometimes the kernel will hang.

And there is no clear count for how many repetitions. It may run 1000 times with no error, or will hang on the 300th time. But mostly it's on the high numbers (200++ maybe). Caught this error 5 times now.

If anyone could help me decipher this log, or knows where to fix this, i'm thinking the problem might be in [umount].

===== This was the log that came out(more or less) =====

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)

Maybe if someone knows what the line below means, it will be a great help. [sddrv_irq] is the function i used to handle sd card interrupts. So im guessing i messed up some where in handling the interrupt. i just can't pin-point where with this log.

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

Answer 1

First, not that the problem of soft lockups is not at all uncommon.

---

As stated on Wikipedia:

The computing phrase "interrupt request" (or IRQ) is used to refer to either the act of interrupting the bus lines used to signal an interrupt, or the interrupt input lines on a Programmable Interrupt Controller (PIC).

Wikipedia also lists an interesting issue in JFFS2:

All nodes must still be scanned at mount time. This is slow and is becoming an increasingly serious problem as flash devices scale upward into the Gigabyte range.

My theory is that it is a filesystem limitation, and that it is flooding the hardware with too many requests for reading from your SD card, depending on its size.

But then again, I can't say I know anything about file systems, so this is probably off base on some points.