Fw: corrupt my NAND flash device

[Thayne Harbaugh]

On Sat, 2003-04-26 at 04:23, Jörn Engel wrote:
> On Fri, 25 April 2003 17:10:43 -0600, Thayne Harbaugh wrote:
> > 
> > The big question is how common is this problem (needing retries)? 
> > Should this be more formalized and added to he chip drivers or should it
> > be left up to individuals having to fix things for their special or less
> > common cases?
> 
> This looks more like an implementation problem. If you manage to add
> retry code somewhere central

Any suggestion where somewhere central is?  Right now I've been playing
with it down in the cmdset code - hardly a central place.  I'll have to
look at the mtdchar.c or something.  The nice thing about the cmdsets is
that they are the best place to retry an individual command - especially
individual writes.

> so that all drivers benefit from it,

Agreed - why do the work in each command set - duplicate code issues.

> there should hardly be a performance hit, even for drivers that don't
> need it.

The performance hit is very small - loop while a counter is less than a
set maximum test - compared to the time of a command (erase/write).

> And once in a central place, it would be trivial to add a
> config option for this.

Agreed.

> But someone has to do it. :)
> 
> Jörn

The whole thing just makes me sick.  It's ugly putting in such a hack. 
One little voice in my head keeps telling me that there's an error in
software and I just have to find and fix the bug.  Another little voice
in my head keeps telling me that broken hardware is more common than
most people want to believe.

I haven't been very aggressive about adding the retry code because right
now I'm interested in more data points: Am I the only one that sees the
problem of a flash chip that occasionally drops commands or are others
seeing this same problem?  Is this problem more common but people don't
see it because the flash filesystems think that a location is bad and
mark it as unusable?

I'm more than happy to do the work if others think it's a good thing and
if someone has a suggestion where/how it should be done.

-- 
Thayne Harbaugh
Linux Networx
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: This is a digitally signed message part
Url : http://lists.infradead.org/pipermail/linux-mtd/attachments/20030428/4a9665f3/attachment.bin