Raj,

On Thursday 02 August 2007 06:31, Raj Kumar Yadav wrote:
> On 7/31/07, ian@brightstareng.com <ian@brightstareng.com> 
wrote:
> > On Tuesday 31 July 2007 07:16, Raj Kumar Yadav wrote:
> > > I am using ARM9 based board with 512MB large page(2K page,
> > > 256K Block) nand flash. The linux kernel version is 2.6.14
> > > with yaffs source on date July
> > > 12, 2007 from
> > > http://www.aleph1.co.uk/cgi-bin/viewcvs.cgi/yaffs2/.
> >
> > <snip>
> >
> > > nandmtd2_ReadChunkWithTagsToNAND chunk 60290 data 00000000
> > > tags c0ae9ccc packed tags obj -1 chunk -1 byte -1 seq -1
> > > ext.tags eccres 0 blkbad 0 chused 0 obj 0 chunk0 byte 0
> > > del 0 ser 0 seq 0 Allocating from 472 2
> > > nandmtd2_ReadChunkWithTagsToNAND chunk 60289 data 00000000
> > > tags c0ae9ccc packed tags obj -1 chunk -1 byte -1 seq -1
> > > ext.tags eccres 0 blkbad 0 chused 0 obj 0 chunk0 byte 0
> > > del 0 ser 0 seq 0 Allocating from 472 1
> > > nandmtd2_ReadChunkWithTagsToNAND chunk 60288 data 00000000
> > > tags c0ae9ccc packed tags obj 117900047 chunk 117698535
> > > byte 117902083 seq 117905375 ext.tags eccres 3 blkbad 0
> > > chused 1 obj 117900047 chunk117698535 byte 117902083 del 0
> > > ser 0 seq 117905375
> > > yaffs: Tnodes added
> > > yaffs: yaffs_GutsInitialise() aborted.
> >
> > Some decoding...
> > The "ext.tags eccres 3" indicates that an underlying NAND
> > page read has failed with YAFFS_ECC_RESULT_UNFIXED (3).
> >  This may have come from the MTD's NAND read returning
> > -EBADMSG, or Yaffs's tags ecc test.  Probably the later
> > because this error is during the mount scan.  Either way,
> > the data read from chunk/page 60288 is bad.
>
> Thanks for pointing, I found that the block is bad but not
> marked as bad, I wrote and verify the data on the chunk number
> 60288 and found the nand ecc correction is failing.

Are you saying that, after erasing the block that contains the
'bad page', the page again fails to store data correctly?  If so
then this really looks like a failure.  If not, there are other 
possibilities, like an incomplete write, not fully erased,
or corrupt data transfer during write.

> Do you think, it is necessary to enable the option "page
> verify after write" in nand driver under MTD layer. Will it
> solve the problem ?

Turning on verify while you figure out what's going is not a bad 
idea. Verification costs however, the data is read back and 
compared after the write, so there's additional i/o and CPU 
involved. The NAND chip itself is supposed to check that the 
write/erase is successful as the operation completes -- it 
indicates this in a status byte that's read by MTD -- so it 
should not be necessary to read back the data to verify the 
write. Now there could be other issues outside the NAND chip 
that cause data errors, in which case having MTD read-back and 
verify data just written may be useful.

-imcd