Fw: corrupt my NAND flash device

Thayne Harbaugh tharbaugh at lnxi.com
Fri Apr 25 19:10:43 EDT 2003


On Fri, 2003-04-25 at 16:23, Alex Samoutin wrote:
> > > cause. As I mentioned NAND driver (nand.c) has lock mechanism to prevent
> > > this situation. But it doesn't work in my case. I don't know why - the
> code
> > > look Ok. A added some additional locks and it solved this problem.

You added locks?

> >
> > Ah, sorry for me misinterpreting you original post. I thought, you had
> > found a problem in yaffs.
> >
> > Do you have a patch for this? Even if it is ugly and slow, correct
> > code is better than broken one.
> >
> This is diff file for drivers/mtd/nand.c  (I made to many changes to create
> a patch)
> 
> 151a152,154
> > static struct semaphore sam;
> > #define NAND_WRITE_RETRY 1

Hmmm - looks like you have more than just locking - you also have some
retry logic for failed commands.

I'm jumping in because I have some chips that appear to be broken - they
occasionally drop operations (erase/write).  Eric Beiderman and I have
been through the code (specifically cfi_cmdset_0002.c) and can't find
anywhere that the software might be at fault.  Until I connect a logic
analyzer I can't be certain it's the hardware either - although none of
the other models of flash chip have this problem and everything points
to bad hardware.

Right now Eric and I are debating adding retry logic.  When a command is
"dropped" it seems to always succeed when sent a second time (don't have
any examples that failed on the second try).  I'm interested because
your situation seems to be related.  Is the problem that the chip
sometimes ignores a command?  Does your retry fix things?

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?

-- 
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/20030425/2441a606/attachment.bin 


More information about the linux-mtd mailing list