Adam Dosch
2005-11-07 22:58:49 UTC
Hi,
I've been in the process of implementing Linux kernel 2.6 (specifically now
2.6.14) on an IXP425 development board.
When the kernel boosts, it will mount the jffs2 flash partition and start to
initialize `init`, then I start getting a soft lock errors like:
BUG: soft lockup detected on CPU#0!
Alot of these are caused by some custom software that is executed on the
filesyste that was written for kernel 2.4. Once I stop that from executing on
bootup, my other problem lies with the JFFS2 garbage collection daemon that is
initialized as a kernel thread/process ./fs/jffs2/background.c, line 75.
I've commented out the line so the JFFS2 garbage collection daemon doesnt
initialize at all as that kernel process/thread and I have a stable filesystem
as far as I can tell.
I was curious though; I know stopped the error from coming up, but I want to
know if not having the garbage collection daemon running is a bad idea? From a
forum post back in August 2000 (http://mhonarc.axis.se/jffs-dev/msg00123.html)
it was said that it's not that big of deal b/c, at most, instead of keeping the
filesystem constantly in-check and fresh, if/when the filesystem runs out of
space, the garbage collection mechanism will kick in anyway.
Is that still safe to assume now? Or am I doing something wrong when
implementing the JFFS2 filesystem under 2.6? Or maybe it was just the older
software that was doing it all along.
Any information that can be offered, I'd greatly appreciate it. I know how well
enough how that garbage collection daemon to really fine tune my trouble-shooting.
NOTE: below is my output with the soft lock error for jffs2_gcd_mtd2.
Thank you,
Adam
-----------------
# mount / -o remount,rw
BUG: soft lockup detected on CPU#0!
Pid: 59, comm: jffs2_gcd_mtd2
CPU: 0
PC is at release_console_sem+0x15c/0x210
LR is at 0x238e9e5
pc : [<c0034ea0>] lr : [<0238e9e5>] Not tainted
sp : c3ec3d24 ip : c3ec3d24 fp : c3ec3d44
r10: c3cb9fa8 r9 : 60000013 r8 : ffffc000
r7 : c01bef68 r6 : 60000013 r5 : 0238e9e5 r4 : 0238e9e5
r3 : c01c7960 r2 : ffffffff r1 : 0238e9e5 r0 : 0238e9e5
Flags: nZCv IRQs on FIQs on Mode SVC_32 Segment user
Control: 39FF Table: 03EB8000 DAC: 00000015
[<c0020690>] (show_regs+0x0/0x4c) from [<c004e888>] (softlockup_tick+0x64/0x7c)
r4 = C3EC3CDC
[<c004e824>] (softlockup_tick+0x0/0x7c) from [<c003bf3c>] (do_timer+0x414/0x490)
r4 = 00000001
[<c003bb28>] (do_timer+0x0/0x490) from [<c00237d8>] (timer_tick+0xb4/0xe4)
[<c0023724>] (timer_tick+0x0/0xe4) from [<c0029ac8>] (ixp4xx_timer_interrupt+0x5
0/0x90)
r6 = C3EC3CDC r5 = C01FB5A0 r4 = C01F6074
[<c0029a78>] (ixp4xx_timer_interrupt+0x0/0x90) from [<c001f7f8>] (__do_irq+0x4c/
0x88)
r6 = 00000000 r5 = 00000000 r4 = C01BE2D0
[<c001f7ac>] (__do_irq+0x0/0x88) from [<c001fa40>] (do_level_IRQ+0x6c/0xbc)
r8 = C3EC3CDC r7 = C01BEF68 r6 = C3EC3CDC r5 = 00000005
r4 = C01F5588
[<c001f9d4>] (do_level_IRQ+0x0/0xbc) from [<c001fadc>] (asm_do_IRQ+0x4c/0x128)
r6 = 00000020 r5 = 0000001F r4 = C01F5588
[<c001fa90>] (asm_do_IRQ+0x0/0x128) from [<c001e804>] (__irq_svc+0x24/0x60)
[<c0034d44>] (release_console_sem+0x0/0x210) from [<c00351e4>] (vprintk+0x290/0x
2e8)
r8 = 00000051 r7 = C01F6F42 r6 = 00208000 r5 = C3EC3DC8
r4 = C01F6EF4
[<c0034f54>] (vprintk+0x0/0x2e8) from [<c0035258>] (printk+0x1c/0x20)
[<c003523c>] (printk+0x0/0x20) from [<c00c7324>] (jffs2_lookup_node_frag+0x64/0x
13c)
r3 = C3EBE7AC r2 = 00208000 r1 = 00207000 r0 = C019A218
[<c00c72c0>] (jffs2_lookup_node_frag+0x0/0x13c) from [<c00ca970>] (jffs2_add_ful
l_dnode_to_inode+0xac/0x660)
r6 = C3EBE790 r5 = C3E6BD70 r4 = 00000000
[<c00ca8c4>] (jffs2_add_full_dnode_to_inode+0x0/0x660) from [<c00cb2cc>] (jffs2_
do_read_inode_internal+0x178/0x8d4)
[<c00cb154>] (jffs2_do_read_inode_internal+0x0/0x8d4) from [<c00cba90>] (jffs2_d
o_crccheck_inode+0x68/0xbc)
[<c00cba28>] (jffs2_do_crccheck_inode+0x0/0xbc) from [<c00d32b8>] (jffs2_garbage
_collect_pass+0x1c8/0x840)
r6 = C3C11200 r5 = C3EC2000 r4 = C03FFC98
[<c00d30f0>] (jffs2_garbage_collect_pass+0x0/0x840) from [<c00d5400>] (jffs2_gar
bage_collect_thread+0x14c/0x18c)
[<c00d52b4>] (jffs2_garbage_collect_thread+0x0/0x18c) from [<c00367d0>] (do_exit
+0x0/0xb24)
r6 = 00000000 r5 = 00000000 r4 = 00000000
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to ***@axis.com
I've been in the process of implementing Linux kernel 2.6 (specifically now
2.6.14) on an IXP425 development board.
When the kernel boosts, it will mount the jffs2 flash partition and start to
initialize `init`, then I start getting a soft lock errors like:
BUG: soft lockup detected on CPU#0!
Alot of these are caused by some custom software that is executed on the
filesyste that was written for kernel 2.4. Once I stop that from executing on
bootup, my other problem lies with the JFFS2 garbage collection daemon that is
initialized as a kernel thread/process ./fs/jffs2/background.c, line 75.
I've commented out the line so the JFFS2 garbage collection daemon doesnt
initialize at all as that kernel process/thread and I have a stable filesystem
as far as I can tell.
I was curious though; I know stopped the error from coming up, but I want to
know if not having the garbage collection daemon running is a bad idea? From a
forum post back in August 2000 (http://mhonarc.axis.se/jffs-dev/msg00123.html)
it was said that it's not that big of deal b/c, at most, instead of keeping the
filesystem constantly in-check and fresh, if/when the filesystem runs out of
space, the garbage collection mechanism will kick in anyway.
Is that still safe to assume now? Or am I doing something wrong when
implementing the JFFS2 filesystem under 2.6? Or maybe it was just the older
software that was doing it all along.
Any information that can be offered, I'd greatly appreciate it. I know how well
enough how that garbage collection daemon to really fine tune my trouble-shooting.
NOTE: below is my output with the soft lock error for jffs2_gcd_mtd2.
Thank you,
Adam
-----------------
# mount / -o remount,rw
BUG: soft lockup detected on CPU#0!
Pid: 59, comm: jffs2_gcd_mtd2
CPU: 0
PC is at release_console_sem+0x15c/0x210
LR is at 0x238e9e5
pc : [<c0034ea0>] lr : [<0238e9e5>] Not tainted
sp : c3ec3d24 ip : c3ec3d24 fp : c3ec3d44
r10: c3cb9fa8 r9 : 60000013 r8 : ffffc000
r7 : c01bef68 r6 : 60000013 r5 : 0238e9e5 r4 : 0238e9e5
r3 : c01c7960 r2 : ffffffff r1 : 0238e9e5 r0 : 0238e9e5
Flags: nZCv IRQs on FIQs on Mode SVC_32 Segment user
Control: 39FF Table: 03EB8000 DAC: 00000015
[<c0020690>] (show_regs+0x0/0x4c) from [<c004e888>] (softlockup_tick+0x64/0x7c)
r4 = C3EC3CDC
[<c004e824>] (softlockup_tick+0x0/0x7c) from [<c003bf3c>] (do_timer+0x414/0x490)
r4 = 00000001
[<c003bb28>] (do_timer+0x0/0x490) from [<c00237d8>] (timer_tick+0xb4/0xe4)
[<c0023724>] (timer_tick+0x0/0xe4) from [<c0029ac8>] (ixp4xx_timer_interrupt+0x5
0/0x90)
r6 = C3EC3CDC r5 = C01FB5A0 r4 = C01F6074
[<c0029a78>] (ixp4xx_timer_interrupt+0x0/0x90) from [<c001f7f8>] (__do_irq+0x4c/
0x88)
r6 = 00000000 r5 = 00000000 r4 = C01BE2D0
[<c001f7ac>] (__do_irq+0x0/0x88) from [<c001fa40>] (do_level_IRQ+0x6c/0xbc)
r8 = C3EC3CDC r7 = C01BEF68 r6 = C3EC3CDC r5 = 00000005
r4 = C01F5588
[<c001f9d4>] (do_level_IRQ+0x0/0xbc) from [<c001fadc>] (asm_do_IRQ+0x4c/0x128)
r6 = 00000020 r5 = 0000001F r4 = C01F5588
[<c001fa90>] (asm_do_IRQ+0x0/0x128) from [<c001e804>] (__irq_svc+0x24/0x60)
[<c0034d44>] (release_console_sem+0x0/0x210) from [<c00351e4>] (vprintk+0x290/0x
2e8)
r8 = 00000051 r7 = C01F6F42 r6 = 00208000 r5 = C3EC3DC8
r4 = C01F6EF4
[<c0034f54>] (vprintk+0x0/0x2e8) from [<c0035258>] (printk+0x1c/0x20)
[<c003523c>] (printk+0x0/0x20) from [<c00c7324>] (jffs2_lookup_node_frag+0x64/0x
13c)
r3 = C3EBE7AC r2 = 00208000 r1 = 00207000 r0 = C019A218
[<c00c72c0>] (jffs2_lookup_node_frag+0x0/0x13c) from [<c00ca970>] (jffs2_add_ful
l_dnode_to_inode+0xac/0x660)
r6 = C3EBE790 r5 = C3E6BD70 r4 = 00000000
[<c00ca8c4>] (jffs2_add_full_dnode_to_inode+0x0/0x660) from [<c00cb2cc>] (jffs2_
do_read_inode_internal+0x178/0x8d4)
[<c00cb154>] (jffs2_do_read_inode_internal+0x0/0x8d4) from [<c00cba90>] (jffs2_d
o_crccheck_inode+0x68/0xbc)
[<c00cba28>] (jffs2_do_crccheck_inode+0x0/0xbc) from [<c00d32b8>] (jffs2_garbage
_collect_pass+0x1c8/0x840)
r6 = C3C11200 r5 = C3EC2000 r4 = C03FFC98
[<c00d30f0>] (jffs2_garbage_collect_pass+0x0/0x840) from [<c00d5400>] (jffs2_gar
bage_collect_thread+0x14c/0x18c)
[<c00d52b4>] (jffs2_garbage_collect_thread+0x0/0x18c) from [<c00367d0>] (do_exit
+0x0/0xb24)
r6 = 00000000 r5 = 00000000 r4 = 00000000
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to ***@axis.com