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 <boaz.bd@wellsense-tech.com> 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
(text/plain)