All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Hunter <ext-adrian.hunter@nokia.com>
To: linux-mtd <linux-mtd@lists.infradead.org>
Subject: Re: OneNAND: Rate of write errors
Date: Thu, 22 Feb 2007 11:28:57 +0200	[thread overview]
Message-ID: <45DD6259.8010504@nokia.com> (raw)
In-Reply-To: <e167438e0702211621i2eadbf15s33db7c34dc989bb2@mail.gmail.com>

ext Julianne C. wrote:
> We are still struggling to understand and manage the OneNAND part on a
> LogicPD PXA270 board.  We are using the mtd development snapshot build
> of 2-15-07 for the fs and device layers.  Our requirements lead us to
> use JFFS2 as the file system.
> 
> What we are seeing is that when we write to a file system that is
> freshly erased and mounted using the command:
>> mount -t jffs2 /dev/mtdblockx /mnt
> and then performing some operation like tar or rsync to place files in
> the new fs, we see about 5 to 8 "write errors" of the form per MB:
> 
> onenand_write: verify failed -74
> Write of 2663 bytes at 0x007a6e14 failed. returned -74, retlen 0
> Not marking the space at 0x007a6e14 as dirty because the flash driver
> returned retlen zero

Note that verify errors will not occur if you have ECC turned on because
you will get ECC errors instead, in which case I would say the block
is bad.  Possibly you have inadvertently removed a bad block marker.

The other possibility is that the data is not making it to OneNAND
correctly in the first place.  By default this is done by
onenand_write_bufferram.  You could add a comparison to be sure.

Also I guess jffs2 would be happier if the length was returned
when the verify fails, say like this:

diff --git a/drivers/mtd/onenand/onenand_base.c b/drivers/mtd/onenand/onenand_base.c
index 1a38414..8fc1570 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -1238,6 +1238,8 @@ static int onenand_write(struct mtd_info
 			break;
 		}
 
+		written += thislen;
+
 		/* Only check verify write turn on */
 		ret = onenand_verify(mtd, (u_char *) wbuf, to, thislen);
 		if (ret) {
@@ -1245,8 +1247,6 @@ static int onenand_write(struct mtd_info
 			break;
 		}
 
-		written += thislen;
-
 		if (written == len)
 			break;
 



> Is this common to see this many errors in that amount of page writes?

Not in my experience with OneNAND.

  reply	other threads:[~2007-02-22  9:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-22  0:21 OneNAND: Rate of write errors Julianne C.
2007-02-22  9:28 ` Adrian Hunter [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-02-22 16:35 Julianne C.
2007-02-23  8:04 ` Adrian Hunter
2007-02-26  0:41 ` Kyungmin Park

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45DD6259.8010504@nokia.com \
    --to=ext-adrian.hunter@nokia.com \
    --cc=linux-mtd@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.