All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shmulik Ladkani <shmulik.ladkani@gmail.com>
To: artem.bityutskiy@linux.intel.com
Cc: linux-mtd@lists.infradead.org,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Mike Dunn <mikedunn@newsguy.com>
Subject: Re: flash bbt broken due to unitialized bitflip_threshold?
Date: Wed, 6 Jun 2012 18:15:29 +0300	[thread overview]
Message-ID: <20120606181529.291aa9a6@halley> (raw)
In-Reply-To: <1338989453.6875.49.camel@sauron.fi.intel.com>

Hi Artem,

On Wed, 06 Jun 2012 16:30:53 +0300 Artem Bityutskiy <artem.bityutskiy@linux.intel.com> wrote:
> On Wed, 2012-06-06 at 12:50 +0300, Shmulik Ladkani wrote:
> > +	if (!mtd->bitflip_threshold)
> > +		mtd->bitflip_threshold = mtd->ecc_strength;
> 
> Hmm, why se default is to report bit-flips only when one more flipping
> bit would cause an ECC error? The default be 1 - report on any bit-flip.
> The same should be done in 'add_mtd_device()' - we should preserve the
> old behavior, as it was before these patches. Do I miss something?

Mike's patchset modified behavior of mtd_read() to return EUCLEAN only
if max number of bitflips (per ecc step) exceeds the bitflip_threshold:

	return ret_code >= mtd->bitflip_threshold ? -EUCLEAN : 0;

mtd->bitflip_threshold can be set in the following ways:
- By the lowlevel driver
- By 'add_mtd_device'. Here it defaults to 'ecc_strength' if NOT
  previously set by the driver.
- Using sysfs attribute

Currently, no driver explicitly sets bitflip_threshold, so it defaults
to ecc_strength. This is not necessarily 1; it depends on the hardware
driver, or software algorithm, etc...

So the "old behavior" was not preserved by the patchset, at least for
those setups with ecc_strength greater than 1. And I don't think the
intention was to preserve 'bitflip_threshold' as 1.

As Sascha spotted, the patchset created a problem for 'scan_bbt'.
This is since 'scan_bbt' calls 'mtd_read()' to read the BBT pages,
however 'bitflip_threshold' is usually NOT YET assigned at that point,
which results in mtd_read's condition (quoted above) to ALWAYS
return -EUCLEAN.
This leads to constantly scrubbing the BBT. Ouch.

My suggestion is to assign the default value of 'ecc_strength' to
'bitflip_threshold' at the end of 'nand_scan_tail', PRIOR the call to
scan_bbt().
Hence, BBT will be scrubbed only if maximum bitflips exceeded the
'ecc_strength' of this mtd (which is the default behavior).

Does it make sense to you?

Or would you like to scrub the BBT upon every bitflip, regardless
ecc_strength?

Regards,
Shmulik

  reply	other threads:[~2012-06-06 15:15 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 [this message]
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
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=20120606181529.291aa9a6@halley \
    --to=shmulik.ladkani@gmail.com \
    --cc=artem.bityutskiy@linux.intel.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mikedunn@newsguy.com \
    --cc=s.hauer@pengutronix.de \
    /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.