Doing "echo all > /proc/yaffs" did not reveal any special information as far as I could see. This is what's on my kernel log when I issue "touch" on a test file in the partition: Dec 28 14:01:24 kernel: ext.tags eccres 0 blkbad 0 chused 1 obj 268435455 chunk0 byte 0 del 0 ser 0 seq -16694686 Dec 28 14:01:24 kernel: packed tags obj -1 chunk -1 byte -1 seq -16694686 Dec 28 14:01:24 kernel: ext.tags eccres 3 blkbad 0 chused 1 obj 268435455 chunk0 byte 0 del 0 ser 0 seq -16694686 Dec 28 14:01:24 kernel: find next checkpt block: search: block 3295 oid 268435455 seq -16694686 eccr 3 Dec 28 14:01:24 kernel: nandmtd2_ReadChunkWithTagsFromNAND chunk 421760 data (null) tags c402fcc8 Dec 28 14:01:24 kernel: packed tags obj -1 chunk -1 byte -1 seq -16699276 Dec 28 14:01:24 kernel: ext.tags eccres 0 blkbad 0 chused 1 obj 268435455 chunk0 byte 0 del 0 ser 0 seq -16699276 Dec 28 14:01:24 kernel: packed tags obj -1 chunk -1 byte -1 seq -16699276 Dec 28 14:01:24 kernel: ext.tags eccres 3 blkbad 0 chused 1 obj 268435455 chunk0 byte 0 del 0 ser 0 seq -16699276 Dec 28 14:01:24 kernel: find next checkpt block: search: block 3296 oid 268435455 seq -16699276 eccr 3 Dec 28 14:01:24 kernel: found no more checkpt blocks Dec 28 14:01:24 kernel: checkpoint byte count 0 Dec 28 14:01:24 kernel: restore exit: isCheckpointed 0 Dec 28 14:01:24 kernel: yaffs2_ScanBackwards starts intstartblk 1 intendblk 3296... Dec 28 14:01:24 kernel: nandmtd2_QueryNANDBlock 0 Dec 28 14:01:24 kernel: nandmtd2_ReadChunkWithTagsFromNAND chunk 0 data (null) tags c402fcc8 Dec 28 14:01:24 kernel: packed tags obj -1 chunk -1 byte -1 seq -1 Dec 28 14:01:24 kernel: ext.tags eccres 0 blkbad 0 chused 0 obj 0 chunk0 byte 0 del 0 ser 0 seq 0 Dec 28 14:01:24 kernel: packed tags obj -1 chunk -1 byte -1 seq -1 Dec 28 14:01:24 kernel: ext.tags eccres 1 blkbad 0 chused 0 obj 0 chunk0 byte 0 del 0 ser 0 seq 0 Dec 28 14:01:24 kernel: block is bad seq 0 state 3 Dec 28 14:01:24 kernel: Block scanning block 1 state 3 seq 0 Dec 28 14:01:24 kernel: Block empty Dec 28 14:01:24 kernel: nandmtd2_QueryNANDBlock 1 Dec 28 14:01:24 kernel: nandmtd2_ReadChunkWithTagsFromNAND chunk 128 data (null) tags c402fcc8 Dec 28 14:01:24 kernel: packed tags obj -1 chunk -1 byte -1 seq -1 Dec 28 14:01:24 kernel: ext.tags eccres 0 blkbad 0 chused 0 obj 0 chunk0 byte 0 del 0 ser 0 seq 0 Dec 28 14:01:24 kernel: packed tags obj -1 chunk -1 byte -1 seq -1 Dec 28 14:01:24 kernel: ext.tags eccres 1 blkbad 0 chused 0 obj 0 chunk0 byte 0 del 0 ser 0 seq 0 Could it be that the nand driver is writing some data to the spare area and this is why yaffs thinks the block is bad? What more can I do to debug this? On Mon, 2010-12-27 at 17:38 +0000, Ross Younger wrote: > * Boaz Ben-David wrote: > > My problem is that when I try to write some files (even using "touch") > > it seems yaffs is trying to retire all of the blocks on the partition. > > Most problems I've encountered of this nature have been caused by bugs in > the MTD driver(s). The root causes have been things like the MTD driver > misreporting to YAFFS that the write failed, the write actually failing > due to a protocol or timing error, or YAFFS believing there to be an > ECC mismatch somewhere along the line. Particularly check the ECC - > sometimes you have to special-case the check for empty pages (if the > ECC for an erased block - all 0xFF - is not itself all 0xFF). > > You may be able to get more of an insight into exactly what has gone > wrong by turning on tracing and working backwards from the exact error > reported. > > Ross > > _______________________________________________ > yaffs mailing list > yaffs@lists.aleph1.co.uk > http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs