使用 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]
答案1
首先，软锁定问题并不是一点也不罕见。
正如维基百科所述：
计算短语“中断请求”（或 IRQ）用于指中断用于发出中断信号的总线线路或可编程中断控制器 (PIC) 上的中断输入线的行为。
Wikipedia 还列出了 JFFS2 中的一个有趣问题：
在挂载时仍必须扫描所有节点。这很慢，而且随着闪存设备规模上升到千兆字节范围，这个问题变得越来越严重。
我的理论是，这是一个文件系统的限制，并且它会向硬件发送太多从 SD 卡读取的请求，具体取决于 SD 卡的大小。
但话又说回来，我不能说我对文件系统一无所知，所以这可能在某些方面是错误的。