couple problems with JFFS2 on a PPC-based embedded system

Robert P. J. Day rpjday at
Fri Jun 25 13:45:10 EDT 2004

   i'm hoping this is the right place to ask a couple questions 
regarding some weirdnesses using JFFS2 on a PPC-based embedded system.

   first, some sudden errors that just cropped up during a boot on
one of the boards:
Waiting for write to complete timed out in do_write_oneword.<5>Write 
of 2209
es at 0x00737610 failed. returned -5, retlen 480
Scheduling in interrupt
kernel BUG at sched.c:564!
Oops: Kernel Mode Software FPU Emulation, sig: 8
NIP: C000E028 XER: 00000000 LR: C000E028 SP: C1581F10 REGS: c1581e60 
    Not tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c1580000[172] 'tar' Last syscall: 4
last math 00000000 last altivec 00000000
GPR00: C000E028 C1581F10 C1580000 0000001B 00001032 00000001 00000001
GPR08: 00000000 C015A0C8 0000001B C1581E20 FA200000 1006D20C 00000000
GPR16: 00000000 00000000 00000000 00000000 00009032 01581F40 00000000
GPR24: C00043E0 10003CF0 100094B4 00000004 00000005 7FFFDAA8 00000000
Call backtrace:
C000E028 C000468C 00000000 100411E8 10040A54 10040B04 10005F40
10007AD4 10009524 10004E4C 1000418C 10003D70 0FE70E88 00000000
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing

upon reboot, then, we get:

jffs2_scan_inode_node(): Data CRC failed on node at 0x0071dc4c: Read
  calculated 0x571a911d
jffs2_scan_inode_node(): Data CRC failed on node at 0x00737610: Read
  calculated 0x07b0d4c4

   ouch.  and, while this may show how little i know about JFFS2 
mechanics, here's something else i'm puzzled about.

   yesterday, on the same type of system, i ran "eraseall" to totally 
erase the user flash.  seemed to work fine, took its time, 64K at a 
time (total 8M).  afterwards, i could mount it -- not surprisingly it 
was totally empty.  unmounted, rebooted system, and got numerous 
errors at boot time (sorry, i don't have the actual errors at hand, 

   ok, "eraseall" again, mount and verify empty flash again, reboot, 
same thing.  third time, "eraseall", mount, and then copy a short file 
into the flash.  the write for a 2K file took the better part of a
minute, but eventually succeeded, the file was there, so unmount, 
reboot, and this time, no problem.

   so with me not knowing how JFFS2 FSes work internally, is there 
something about writing the very first file to an erased FS that 
somehow initializes it so that it works fine from then on?

   thanks for any help.


p.s.  given that this is a 2.4.22-pre8 kernel, should i download the 
latest mtd kernel stuff and update?  the current drivers/mtd directory
appears to be dated mar, 2002.  at least, that's the date in the 

More information about the linux-mtd mailing list