WARNING: cfi_cmdset_0002 - consider updating your revision

[Thayne Harbaugh]

All cfi_cmdset_0002 users please read.

I have just committed revision 1.67 of cfi_cmdset_0002.c.  It now works
well with interleaved chips - thanks to Alexander Wild for helping with
the debugging and testing.  It may change one more time for interleaved
chips to handle a very remote, spurious rejection case (it might return
an error when an operation really succeeded - see the FIXME comment that
was added in do_write_oneword()).

URGENT NOTE:  revision 1.64 of cfi_cmdset_0002.c and likely most prior
revisions allow some UNREPORTED failures (yes, I am yelling).  That
means that erase or write operations could fail and go unreported. 
Depending on your application this could be serious data loss and I
encourage you to evaluate revision 1.67 to decide if you should upgrade.

The care and feeding of flash devices for erase and write operations
requires understanding of how the devices work and isn't as simple as it
appears - especially coupled with interleaved cases and other varying
uses.  The logic often seems redundant and inefficient.  I am quite
convinced that in the past, as people fixed bugs, different requirements
were understood by different people at different times and bugs would
get pushed back and forth and 'round and 'round and some would just
never get squished - the symptoms would just change.

I feel good that things are finally settling down with cfi_cmdset_002
and that it might just work now.  If the current version doesn't work
for you I need to hear about it soon.

To be completely forthcoming, I need to admit that I still have an
SST49LF040A that doesn't work completely.  I'm still trying to decide if
it's a software problem or a hardware problem.  I have multiple devices
that of this part - one being used for a BIOS chip on an Opteron
motherboard and one as BIOS on a Tyan 2466.  Both have the same problem
that occasionally they ignore an erase or write command - as if the
command was never sent.  This problem happened in cfi_cmdset_0002
revision 1.64 - it was never reported as an error by cfi_cmdset_0002 so
failures would happen at other locations - especially user-space
programs.  Strangely, these failures disappear on retries of the same
operation.

Kernel messages have enough information to get a feel for the operation
that failed and why it was marked as a failure.  If CONFIG_MTD_DEBUG is
turned on and CONFIG_MTD_DEBUG_VERBOSE is set to 3 then significant
command state is reported.  If you have a failure, please set the debug
level to 3 and send me your dmesg output.

Thanks.


-- 
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/20030415/1c61a99c/attachment.bin