From: Josh Wu <josh.wu@atmel.com>
To: Brian Norris <computersforpeace@gmail.com>,
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Cc: Steve deRosier <derosier@gmail.com>,
Ricard Wanderlof <ricard.wanderlof@axis.com>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
Huang Shijie <shijie8@gmail.com>,
Richard Weinberger <richard@nod.at>
Subject: Re: NAND ECC capabilities
Date: Mon, 12 Jan 2015 16:35:17 +0800 [thread overview]
Message-ID: <54B38745.70007@atmel.com> (raw)
In-Reply-To: <20150108190916.GT9759@ld-irv-0074>
Hi, Brian
On 1/9/2015 3:09 AM, Brian Norris wrote:
> On Thu, Jan 08, 2015 at 01:42:53PM -0300, Ezequiel Garcia wrote:
>> On 01/08/2015 05:32 AM, Ricard Wanderlof wrote:
>>> On Thu, 8 Jan 2015, Steve deRosier wrote:
>>>> Is my general understanding correct?
>>> I'd say yes, but the ECC threshold should be per 512 byte ECC block (which
>>> seems to be the correct term rather than 'sector'), rather than per page.
>>> Are you sure that the threshold is set to 4 (see
>>> /sys/devices/virtual/mtd/mtd<n>/bitflip_threshold )?
>>>
>>> Normally the threshold is set below the ECC correction capability, so that
>>> bit scrubbing has a chance to occur before the bits rot too far. Say you
>>> have the threshold set at 4 bits, and you have 3 bits that have flipped.
>>> If another bit flips, the block would be scrubbed, but say that two bits
>>> flipped before you read the data the next time. You would have lost your
>>> chance of recovery, so it makes sense to have the threshold lower than the
>>> ECC capability. I would say 3/4 of the ECC capability would be a
>>> reasonable value.
>>>
>> This makes a lot of sense. However, do we have any way of telling if the
>> bitflips where produced on the same ECC sector?
>>
>> From a cursory look to the code, I'd say there's no such feature with
>> the current MTD/NAND design. So, if an mtd_read reports 3 bitflips you
>> have no way of telling they happened on the same sector or not, so you
>> can't implement your idea.
> I'm not sure if I'm misunderstanding you or if you are misunderstanding
> the code. Please review Documentation/ABI/testing/sysfs-class-mtd for
> the 'bitflip_threshold' description. We only deal with the max # of
> bitflips per sector (or block, or whatever you want to call it). No
> ECC-related concept is handled on a per-page basis.
>
> So I believe Ricard is accurately describing the current reality, not
> "his idea."
>
> Side note: I wonder if we want to change the nand_base defaults so
>
> bitflip_threshold == 3/4 * ecc_strength
>
> rather than
>
> bitflip_threshold == ecc_strength
>
> See in nand_scan_tail():
>
> if (!mtd->bitflip_threshold)
> mtd->bitflip_threshold = mtd->ecc_strength;
According to the discussion, this change really make sense.
Will you generate a patch for this? Thanks.
Best Regards,
Josh Wu
>
> Brian
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2015-01-12 8:38 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-08 3:10 NAND ECC capabilities Steve deRosier
2015-01-08 4:17 ` Ezequiel Garcia
2015-01-08 6:22 ` Steve deRosier
[not found] ` <0D23F1ECC880A74392D56535BCADD73526C0EA9A@NTXBOIMBX03.micron.com>
2015-01-08 17:09 ` Steve deRosier
2015-01-08 18:57 ` Brian Norris
2015-01-08 8:32 ` Ricard Wanderlof
2015-01-08 16:42 ` Ezequiel Garcia
2015-01-08 17:26 ` Steve deRosier
2015-01-08 19:09 ` Brian Norris
2015-01-08 19:27 ` Ezequiel Garcia
2015-01-12 8:35 ` Josh Wu [this message]
2015-01-12 20:51 ` [PATCH] mtd: nand: default bitflip-reporting threshold to 75% of correction strength Brian Norris
2015-01-13 2:01 ` Huang Shijie
2015-01-13 2:38 ` Brian Norris
2015-01-13 2:56 ` Huang Shijie
2015-01-13 13:25 ` Richard Weinberger
2015-01-13 18:48 ` Brian Norris
2015-01-13 18:51 ` Richard Weinberger
2015-01-13 19:51 ` Brian Norris
2015-01-17 19:01 ` Boris Brezillon
2015-01-17 19:26 ` Richard Weinberger
2015-01-17 19:42 ` Boris Brezillon
2015-01-17 19:54 ` Richard Weinberger
2015-01-21 8:22 ` Brian Norris
2015-01-21 8:42 ` Boris Brezillon
2015-02-10 13:50 ` Boris Brezillon
2015-01-21 7:45 ` Brian Norris
2015-01-08 17:14 ` NAND ECC capabilities Steve deRosier
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=54B38745.70007@atmel.com \
--to=josh.wu@atmel.com \
--cc=computersforpeace@gmail.com \
--cc=derosier@gmail.com \
--cc=ezequiel@vanguardiasur.com.ar \
--cc=linux-mtd@lists.infradead.org \
--cc=ricard.wanderlof@axis.com \
--cc=richard@nod.at \
--cc=shijie8@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.