JFFS garbage collection(?) fails

JFFS garbage collection(?) fails

[David Vrabel]

Hi,

I was running a script which copies files back and forth checking their
checksums.  The machine would then reboot after a random time (between
5-10 min). The test had been running successfully for about 2 hrs. 


Here's a sample of the log produced

Aug  9 12:17:33 linux-sbc logger: 1k: OK
Aug  9 12:17:33 linux-sbc logger: 2k: OK
Aug  9 12:17:33 linux-sbc logger: 4k: OK
Aug  9 12:17:33 linux-sbc logger: 8k: OK
Aug  9 12:17:33 linux-sbc logger: Success
Aug  9 12:17:33 linux-sbc kernel: jffs_garbage_collect_thread():
collecting. 
Aug  9 12:17:33 linux-sbc last message repeated 21 times
Aug  9 12:17:33 linux-sbc kernel: Waiting for chip, status = 4 
[machine reboots here]

Aug  9 12:18:59 linux-sbc syslogd 1.3-3: restart.
Aug  9 12:18:59 linux-sbc kernel: jffs_mknod: bogus imode (140755) 
[The above line looks odd too...]
Aug  9 12:18:59 linux-sbc logger: Starting test...
Aug  9 12:18:59 linux-sbc logger: 1k: OK
Aug  9 12:18:59 linux-sbc logger: 2k: OK
Aug  9 12:18:59 linux-sbc logger: 4k: OK
Aug  9 12:18:59 linux-sbc logger: 8k: OK
Aug  9 12:18:59 linux-sbc logger: Success

[lots more successes...(about 20)]

Aug  9 12:19:04 linux-sbc logger: 1k: OK
Aug  9 12:19:04 linux-sbc logger: 2k: OK
Aug  9 12:19:05 linux-sbc logger: 4k: OK
Aug  9 12:19:05 linux-sbc logger: 8k: OK
Aug  9 12:19:05 linux-sbc logger: Success
Aug  9 12:19:05 linux-sbc kernel: jffs_garbage_collect_thread():
collecting. 
Aug  9 12:19:05 linux-sbc kernel: jffs_garbage_collect_thread():
collecting. 
Aug  9 12:19:05 linux-sbc kernel: jffs_flash_erasable_size() given
length which runs off the end of device (ofs 160000 + len 27ad4 =
187ad4, > 180000) 
Aug  9 12:19:05 linux-sbc kernel: jffs_erasable_size:
flash_erasable_size() returned something less than zero (-3). 
Aug  9 12:19:05 linux-sbc kernel: jffs_erasable_size: offset =
0x00160000 
Aug  9 12:19:05 linux-sbc kernel: jffs_garbage_collect_thread():
collecting. 
Aug  9 12:19:05 linux-sbc kernel: jffs_flash_erasable_size() given
length which runs off the end of device (ofs 160000 + len 27b1c =
187b1c, > 180000) 
Aug  9 12:19:05 linux-sbc kernel: jffs_erasable_size:
flash_erasable_size() returned something less than zero
(-3).              
[and on and on and on...]

The JFFS filesystem is now garbled.

David Vrabel



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: JFFS garbage collection(?) fails

[David Woodhouse]

dvrabel@arcom.co.uk said:
>  I was running a script which copies files back and forth checking
> their checksums.  The machine would then reboot after a random time
> (between 5-10 min). The test had been running successfully for about 2
> hrs.  

I ran one of those overnight on the board here, but without the power 
cycles, and without the problems. Actually, I was running two of them in 
parallel.

I hate to say this again, but are you using the latest version of the code, 
with the semaphores in to make writes and garbage collection atomic?

Could you copy reports of JFFS problems to the JFFS development list too?

It's difficult to know what happened without seeing a full debug log of 
what it was doing before the power cycle, and/or a snapshot of the flash 
before the power was returned.

Is there any way you could modify your test cycle to take an image of the 
JFFS flash before attempting to remount it?

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: JFFS garbage collection(?) fails

[David Woodhouse]

dvrabel@arcom.co.uk said:
>  The JFFS filesystem is now garbled.

I've just committed a 'jffs-dump' program which may be useful in working 
out exactly _how_ your JFFS filesystem is garbled. 

It's currently hardwired to dump the contents only of jffs nodes with 
ino == 425 - because that was utmp on the system on my desk, which is 
happily oopsing on boot at the moment because the size of utmp appears to 
be going negative :)



--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org