Hi Ian,
On 8/2/07,
ian@brightstareng.com <
ian@brightstareng.com> wrote:
> 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.
Yes, the block is being erased before each write + verify, And the
verification is failing all the time in same page. This might be
possible that the block might have factory marked bad, but got erased
during earlier driver development/test on that board.
>
> > 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.
I have a doubt, If a block is gone bad, writing 0xA5 may end up to for
example 0xF5 or similar at some byte, somewhere in page. In this case
the flash controller will not return error or Will it ?.
I agree on the cost part, however if write verify makes the solution
more robust, atleast I
am not averse to the idea.
If write verify is not there, should not the yaffs2 layer mark the
block bad during the next read. Do you think it might be due to the
check-pointing. As earlier (6months back) I was using the yaffs2 code
without check pointing, I did not faced the mount failure problem.
Thanks,
Raj Kumar Yadav
(text/plain)