Thanks for the elaborate response. I will go over your test and see what I can come up with. I saw there are some built in test in the linux kernel which can be built as modules and then loaded for testing... Thanks, ________________________________________ From: yaffs-bounces@lists.aleph1.co.uk [yaffs-bounces@lists.aleph1.co.uk] On Behalf Of Ross Younger [yaffs@impropriety.org.uk] Sent: Tuesday, December 28, 2010 11:58 PM To: yaffs@lists.aleph1.co.uk Subject: Re: [Yaffs] yaffs2 block retirement issue * Boaz Ben-David wrote: > 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? YAFFS relies on being able to write to the spare area. If this (or reading back the spare area) fails in some way that would be entirely consistent with what you're experiencing. I see from your trace you've got a few instances of "eccres 3" and "eccr 3". This is mapped (in yaffs_guts.h) to YAFFS_ECC_RESULT_UNFIXED. In other words, an ECC check failed - but that's not a smoking gun, there are several potential causes. If I were you I'd look into putting together some low-level NAND tests. You need to ensure that you can reliably write arbitrary data to NAND pages and their spare areas, and read it all back, at full speed (whatever that means to your application); without that, you're only going to confuse both YAFFS and yourself. Hopefully somebody out there will suggest some Linux-based tests. If not, you might care to look at what I wrote for eCos some months ago - though you're probably better off using them only as inspiration and writing your own, rather than adapting, as they're very specific to that platform. They can be found at http://hg-pub.ecoscentric.com/nand-ecoscentric/file/a9d12f1a0c5b/packages/io/nand/current/tests - nand_readwrite.c is probably the most useful. Ross _______________________________________________ yaffs mailing list yaffs@lists.aleph1.co.uk http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs