From: Mike Dunn <mikedunn@newsguy.com>
To: artem.bityutskiy@linux.intel.com
Cc: Ivan Djelic <ivan.djelic@parrot.com>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
Sascha Hauer <s.hauer@pengutronix.de>,
Shmulik Ladkani <shmulik.ladkani@gmail.com>
Subject: Re: flash bbt broken due to unitialized bitflip_threshold?
Date: Thu, 07 Jun 2012 10:34:42 -0700 [thread overview]
Message-ID: <4FD0E632.2080905@newsguy.com> (raw)
In-Reply-To: <1339054570.6875.84.camel@sauron.fi.intel.com>
On 06/07/2012 12:36 AM, Artem Bityutskiy wrote:
> On Wed, 2012-06-06 at 19:55 +0200, Ivan Djelic wrote:
>> 1. on legacy systems with 1-bit nand and strength = 1, default bitflip_threshold is 1
>> 2. on legacy systems with 1-bit nand and strength > 1, default bitflip_threshold is 'strength'
>> 3. on new systems with 2+ bit nand and strength > 1, default bitflip_threshold is 'strength'
>
> Ivan, Shmulik,
>
> I've gave this another though, and I think it is OK to leave this as it
> is now. Your replies were very helpful, thanks.
Yes, many thanks guys. It seems I picked the wrong couple days to be away from
email.
This is not an issue on my docg4 because it does not use a flash-based BBT, but
instead scans the whole device for blocks that are marked bad in oob. EUCLEAN is
ignored in this case. The following code is present in both scan_block_full()
and scan_block_fast():
/* Ignore ECC errors when checking for BBM */
if (ret && !mtd_is_bitflip_or_eccerr(ret))
return ret;
Digging into this, it turns out this is a problem only in the case of:
(1) nand->td != NULL (flash-based BBT present)
(2) NAND_BBT_NO_OOB is not set
Here's the call stack for the above case, and with NAND_BBT_ABSPAGE not set
(this is true for the mxc_nand controller). The problem occurs in
scan_read_raw_oob()...
nand_scan_bbt()
|
+-> search_read_bbts() ignores return code
|
+-> search_bbt() always returns 1
|
+-> scan_read_raw() -EUCLEAN propagated up
|
+-> scan_read_raw_oob() returns without updating buf, len, offs
|
+-> mtd_read_oob() -EUCLEAN returned
I addition to the patch suggested by Shmulik, I would also suggest the
following, in the interest of consistency with the bad block scanning code, and
also thoroughness:
diff --git a/drivers/mtd/nand/nand_bbt.c b/drivers/mtd/nand/nand_bbt.c
index 30d1319..ed59aa8 100644
--- a/drivers/mtd/nand/nand_bbt.c
+++ b/drivers/mtd/nand/nand_bbt.c
@@ -319,7 +319,7 @@ static int scan_read_raw_oob(struct mtd_info *mtd, uint8_t
*buf, loff_t offs,
res = mtd_read_oob(mtd, offs, &ops);
- if (res)
+ if (res && !mtd_is_bitflip_or_eccerr(res))
return res;
buf += mtd->oobsize + mtd->writesize;
Shmulik, please let me know if yuo'd like me to submit the patch you suggested,
and I will do so promptly. Otherwise, thanks again!
More gory details... by comparison, here's the call stack for the same case,
except NAND_BBT_NO_OOB is set. Here, there's no problem.
nand_scan_bbt()
|
+-> search_read_bbts() ignores return code
|
+-> search_bbt() always returns 1
|
+-> scan_read_raw() -EUCLEAN propagated up
|
+-> scan_read_raw_data() -EUCLEAN propagated up
|
+-> mtd_read_oob() -EUCLEAN returned
Thanks, and sorry for the oversight,
Mike
next prev parent reply other threads:[~2012-06-07 17:34 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-05 22:06 flash bbt broken due to unitialized bitflip_threshold? Sascha Hauer
2012-06-06 9:50 ` Shmulik Ladkani
2012-06-06 13:30 ` Artem Bityutskiy
2012-06-06 15:15 ` Shmulik Ladkani
2012-06-06 15:46 ` Artem Bityutskiy
2012-06-06 16:08 ` Shmulik Ladkani
2012-06-06 17:55 ` Ivan Djelic
2012-06-07 7:36 ` Artem Bityutskiy
2012-06-07 14:02 ` Shmulik Ladkani
2012-06-07 17:34 ` Mike Dunn [this message]
2012-06-07 21:07 ` Shmulik Ladkani
2012-06-10 7:08 ` Shmulik Ladkani
2012-06-22 20:39 ` Brian Norris
2012-06-25 17:44 ` Mike Dunn
2012-06-07 7:43 ` Artem Bityutskiy
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=4FD0E632.2080905@newsguy.com \
--to=mikedunn@newsguy.com \
--cc=artem.bityutskiy@linux.intel.com \
--cc=ivan.djelic@parrot.com \
--cc=linux-mtd@lists.infradead.org \
--cc=s.hauer@pengutronix.de \
--cc=shmulik.ladkani@gmail.com \
/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.