Ricard Wanderlof ricard.wanderlof at
Tue Feb 15 08:02:57 EST 2011

On Tue, 15 Feb 2011, David Peverley wrote:

> I've noticed that some of the problems we see are exacerbated further by 
> us having CONFIG_MTD_NAND_VERIFY_WRITE enabled. In the case where blocks 
> have occasional 1-bit ECC failures (i.e. normally correctable and not 
> enough to warrant marking as bad) the generic verify routine will cause 
> nand_write_page() to return failure. I've prototyped a verify routine 
> that uses an ECC corrected read in our driver and it seems to do the job 
> correctly.

I may be wrong here, but as I understand, normally, bit read errors occur 
after a while (often called 'read disturb' in the literature) as the 
contents of certain bit cells leak away (either over time, or by 
accessing), first causing random data, and then after a while settling 
down into a permanently inverted state, until the data is rewritten.

If this is the case, then a verify performed just after a write (which I'm 
assuming is when it is performed) should yield correct data, unless a 
given bit cell is in a really bad condition, in which case the block 
should probably not be used anyway, as there as not been enough time for 
the bit to decay for whatever reason.

Of course, if there are bit cells which have other failure modes, your 
idea might help, but again, if a bit is in such a bad state as to not 
being able to retain data between write and verify, the block should 
probably be discarded (marked as bad) anyway.

One rationale would be that if you have one more or less permanently bad 
bit, although it can be handled by ECC, as soon the contents of another 
bit cell decays, the ECC won't be effective, so in practice, the ECC 
strength is severely reduced for the page (or sub-page more likely, as ECC 
usually operates over less-than-page sizes in modern flashes) in question.

Ricard Wolf Wanderlöf                           ricardw(at)
Axis Communications AB, Lund, Sweden  
Phone +46 46 272 2016                           Fax +46 46 13 61 30

More information about the linux-mtd mailing list