BUG in JFFS2 kernel 2.6.27
Joakim Tjernlund
joakim.tjernlund at transmode.se
Mon Jan 19 03:09:22 EST 2009
I think we need a JFFS2 expert on this, anyone around?
Jocke
>
> joakim.tjernlund at transmode.se wrote:
> > Just got this BUG:
> >
> > Data CRC 22c90447 != calculated CRC cbf47f8b for node at 07d2aadc
> > ------------[ cut here ]------------
> > kernel BUG at fs/jffs2/file.c:251!
> > Oops: Exception in kernel mode, sig: 5
[#1]
> > TMCUTU
> > NIP: c00eb5d0 LR: c004ab34 CTR: c00eb57c
> > REGS: ce217bf0 TRAP: 0700 Not tainted (2.6.27)
> > MSR: 00029032 <EE,ME,IR,DR> CR: 24022422 XER:
00000000
> > TASK = ce1d6800[424] 'ne_swumd' THREAD: ce216000
> > GPR00: 00000001 ce217ca0 ce1d6800 ce296520 cf51b708 00000000
002a6000
> > 00001000
> > GPR08: 00001000 00000000 c016bac4 cf86f600 00400000 10069018
10060000
> > 00000000
> > GPR16: 002a6000 00000000 00000000 c021010c 00000000 ce296520
cf86f400
> > cf51b648
> > GPR24: 00000000 00001000 00000000 002a6000 00000000 cf51b670
ce216000
> > c0441820
> > NIP [c00eb5d0] jffs2_write_end+0x54/0x228
> > LR [c004ab34] generic_file_buffered_write+0x178/0x634
> > Call Trace:
> > [ce217ca0] [c016aa94] release_sock+0x94/0xa8 (unreliable)
> > [ce217ce0] [c004ab34] generic_file_buffered_write+0x178/0x634
> > [ce217d70] [c004b394] __generic_file_aio_write_nolock+0x3a4/0x568
> > [ce217df0] [c004b6b0] generic_file_aio_write+0x68/0x120
> > [ce217e20] [c006a1a4] do_sync_write+0xc8/0x13c
> > [ce217ef0] [c006a2b4] vfs_write+0x9c/0x174
> > [ce217f10] [c006a468] sys_write+0x4c/0x90
> > [ce217f40] [c000f3ec] ret_from_syscall+0x0/0x38
> > --- Exception: c01 at 0xf9c1744
> > LR = 0x1003ce20
> > Instruction dump:
> > 83a40000 7f384214 54dc053a 817d008c 82cb019c 92e10008 3afdffd8
80090000
> > 70090008 41820004 7c000026 54001ffe <0f000000> 6b291000 7d2bfe70
7d604a78
> > ---[ end trace 79c27f7a1b03cf81 ]---
> >
> > Anyone seen something similar?
>
> I think it's this one again:
> http://lists.infradead.org/pipermail/linux-mtd/2008-April/021473.html
>
> The patch in the above post avoids this BUG_ON by aborting early
> when the dnode
> read fails and propagates an error code back to userspace and thus
> avoids this path to be taken.
This seems like the right thing to do. Why test the return value from
jffs2_do_readpage_nolock()
if it always returns 0? If this is enough though is unclear to me.
David?
>
> I didn't pursue it since I was unsure whether it would remove some
> self-healing properties of the design in non-debug builds.
>
More information about the linux-mtd
mailing list