Nandwrite's behavior in case of write failure
Jehan Bing
jehan at orb.com
Mon Jun 8 16:43:26 EDT 2009
Artem Bityutskiy wrote:
> Yes, write and erase failure mean that the erasblock is bad. But I think
> marking a block as bad straight away is just dangerous. Who knows may be
> this is a small glitch in a bus, or a software bug, or some-one
> corrupted driver's memory, or whatever. This is why UBI is doing
> eraseblock torturing before marking it as bad. And it is very careful
> about error codes - only EIO code is considered as a reason to mark an
> eraseblock as bad.
Fixed broken behavior in case of write failure. More specifically:
- Only try to mark a block bad if the errors are EIO. Other errors
will abort the tool.
- Also abort the tool if the marking fails instead of ignoring it.
Signed-off-by: Jehan Bing <jehan at orb.com>
--- a/nandwrite.c 2009-06-08 13:31:14.000000000 -0700
+++ b/nandwrite.c 2009-06-08 13:33:32.000000000 -0700
@@ -586,6 +586,10 @@ int main(int argc, char * const argv[])
erase_info_t erase;
perror ("pwrite");
+ if (errno != EIO) {
+ goto closeall;
+ }
+
/* Must rewind to blockstart if we can */
rewind_blocks = (mtdoffset - blockstart) / meminfo.writesize; /* Not including the one we just attempted */
rewind_bytes = (rewind_blocks * meminfo.writesize) + readlen;
@@ -602,7 +606,9 @@ int main(int argc, char * const argv[])
(long)erase.start, (long)erase.start+erase.length-1);
if (ioctl(fd, MEMERASE, &erase) != 0) {
perror("MEMERASE");
- goto closeall;
+ if (errno != EIO) {
+ goto closeall;
+ }
}
if (markbad) {
@@ -610,7 +616,7 @@ int main(int argc, char * const argv[])
fprintf(stderr, "Marking block at %08lx bad\n", (long)bad_addr);
if (ioctl(fd, MEMSETBADBLOCK, &bad_addr)) {
perror("MEMSETBADBLOCK");
- /* But continue anyway */
+ goto closeall;
}
}
mtdoffset = blockstart + meminfo.erasesize;
More information about the linux-mtd
mailing list