On Friday 07 August 2009 08:02:41 Andrew McKay wrote:
> Hi Charles,
>
> > First off, please pick up the latest from cvs. The most recent patches
> > should not be material to the issues you are dealing with but they might
> > be confusing things a bit.
>
> I have compiled in the latest version of YAFFS as of what was in the public
> repository Aug 6th and loaded it on my board. I've been testing the
> filesystem by untarring an archive and repeatedly copying the directory to
> new directories, removing some of them, and then continuing copying.
> Things seems to be working fine. When I went to go remove everything from
> NAND and give the board to one of the other developers I got some more bad
> messages from YAFFS.
>
Did you do any reboots during the above? Rebooting forces rescanning which
will test the ECC.
> /mnt/nand # \rm -rf *
> **>> Erasure failed 3515
> **>> Block 3515 retired
> Block 3515 is in state 9 after gc, should be erased
> **>> Erasure failed 4201
> **>> Block 4201 retired
> Block 4201 is in state 9 after gc, should be erased
> **>> Erasure failed 8045
> **>> Block 8045 retired
> Block 8045 is in state 9 after gc, should be erased
It looks like the erasure command failed. Try instrumenting the erase function
in the mtd.
Was it just those few blocks kicking up a problem or was there a whole slew of
them? If it was just a few then those might be real bad blocks and then the
above is OK.
From the /proc/yaffs it looks like many erasures worked and only a few
failed. That indicates that the mtd did not tell yaffs these were bad blocks.
I would inspect the bad block marking and ID strategy and make sure it is
working OK.
>
> /proc/yaffs is reporting:
> /mnt/nand # cat /proc/yaffs
> YAFFS built:Aug 6 2009 12:52:21
> $Id: yaffs_fs.c,v 1.81 2009-05-26 01:22:44 charles Exp $
> $Id: yaffs_guts.c,v 1.87 2009-07-29 04:30:24 charles Exp $
>
> Device 0 "NAND 1GiB 3,3V 8-bit"
> startBlock......... 0
> endBlock........... 8191
> totalBytesPerChunk. 4096
> nDataBytesPerChunk. 4096
> chunkGroupBits..... 0
> chunkGroupSize..... 1
> nErasedBlocks...... 3834
> nReservedBlocks.... 5
> blocksInCheckpoint. 0
> nTnodesCreated..... 41600
> nFreeTnodes........ 26625
> nObjectsCreated.... 71100
> nFreeObjects....... 45012
> nFreeChunks........ 456051
> nPageWrites........ 0
> nPageReads......... 0
> nBlockErasures..... 4733
> nGCCopies.......... 776
> garbageCollections. 1513
> passiveGCs......... 1513
> nRetriedWrites..... 0
> nShortOpCaches..... 10
> nRetireBlocks...... 3
> eccFixed........... 0
> eccUnfixed......... 0
> tagsEccFixed....... 0
> tagsEccUnfixed..... 0
> cacheHits.......... 0
> nDeletedFiles...... 0
> nUnlinkedFiles..... 89898
> nBackgroudDeletions 0
> useNANDECC......... 1
> isYaffs2........... 1
> inbandTags......... 0
>
> I ran nanddump from mtd-utils, and it is reporting that there were a bunch
> of ECC errors while reading NAND:
>
> /mnt/zen/mtd-utils # ./nanddump /dev/mtd12 > /dev/null
> ECC failed: 6144
> ECC corrected: 0
> Number of bad blocks: 13
> Number of bbt blocks: 0
> Block size 262144, page size 4096, OOB size 128
> Dumping data starting at 0x00000000 and ending at 0x80000000...
Many ECC errors suggest that your mtd is trying to use the same oob bytes for
both data and ECC and/or bad block markers
When yaffs reads/writes spare bytes it just passes a contiguous buffer (say
yyyyyyyy)
Now let's say the mtd is using 6 bytes for ECC (shon as e) and 2 bytes for the
bad block table shown by b
The actual oob placement might end up being
bbyyyyyeeeyyyyyee
or maybe
bbeeeeeeyyyyyyyyy
or whatever
and it is the job of the mtd to sort this out.
>
> Do you have anymore hints? I'm running out of ideas. I'm starting to
> wonder if there is something fishy about these NAND parts (MT2916G08DAA).
> I am testing across 3 boards, so it isn't limited to one particular part or
> board. This part has been EOL'd by Micron and there is a recommended
> replacement. I wonder if the replacement will show the same issues.
>
> Our NAND driver is pretty simple and mainly uses the functions defined by
> nand_base, and has worked fine with ST NAND parts. When I was testing the
> block device directly with dd, I wasn't able to turn up any obvious issues,
> though I'm going to look into that a bit further.
>
> Thanks,
> Andrew McKay
(text/plain)