Data corrupted

[Bobzin,Heiko]

Hello mtd-fellows,

I ran into trouble with a test I've implemented. It is basically the same
as the mtd-util checkfs: writing into the flash while powering down
the device. The problem is, that files which are never touched are
corrupted, not the data I write.
I diff'd the data and exactly one 4K block is set to zero in a 500k file
in a ~7MB JFFS2 flash partition.
It is reproducible in some hours, but the location differs.

Here is the info about the chips and the system:

MX29LV640T (64Mbit)
Flash:  8 MB

Linux version 2.4.27-vrs1 (root at linux) (gcc version 3.4.3) #16 Wed Feb 16
12:24:31 CET 2005
with latest stable mtd patched.

CPU: Arm920Tid(wb) revision 0
Machine: ATMEL AT91RM9200

 Amd/Fujitsu Extended Query Table at 0x0040
  Silicon revision: 0
  Address sensitive unlock: Required
  Erase Suspend: Read/write
  Block protection: 4 sectors per group
  Temporary block unprotect: Supported
  Block protect/unprotect scheme: 4
  Number of simultaneous operations: 0
  Burst mode: Not supported
  Page mode: Not supported
  Vpp Supply Minimum Program/Erase Voltage: 0.0 V
  Vpp Supply Maximum Program/Erase Voltage: 0.0 V
  Top/Bottom Boot Block: Top boot

Last messages while booting, before detecting the corrupted file:

Node header CRC failed at 001f4ec8. But it must have been OK earlier.
Node was: { 0000, 2000, 00000000, 00000000 }
Eep. Unknown node type 0000 at 00603348 was marked REF_UNCHECKED
Node header CRC failed at 00603348. But it must have been OK earlier.
Node was: { 0000, 2000, 00000000, 00000000 }
jffs2_do_read_inode(): No data nodes found for ino #294
Returned error for crccheck of ino #294. Expect badness...

I've also seen read errors, though after a later reboot the system was
intact
and the "read error" was gone.

Any ideas? Does it look like a hardware (chip timing) or software problem?

Thanks in advance,
Heiko