All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@bootlin.com>
To: Mark Spieth <mspieth@digivation.com.au>
Cc: linux-mtd@lists.infradead.org, Richard Weinberger <richard@nod.at>
Subject: Re: [RFC PATCH] UBI fixable bit-flip issue
Date: Fri, 17 Aug 2018 17:22:46 +0200	[thread overview]
Message-ID: <20180817172246.45fa784c@bbrezillon> (raw)
In-Reply-To: <20180817165322.61958720@bbrezillon>

On Fri, 17 Aug 2018 16:53:22 +0200
Boris Brezillon <boris.brezillon@bootlin.com> wrote:

> On Sat, 18 Aug 2018 00:33:25 +1000
> Mark Spieth <mspieth@digivation.com.au> wrote:
> 
> > >> I hope this description is clear enough.    
> > > Well, I think selecting the bitflip threshold properly is really
> > > important, simply because some NANDs (including SLC NANDs) are showing
> > > bitflips even on blocks that have a low EC. Check the NAND ECC
> > > requirements, and if it's something like 8bit/512bytes, I guess that's
> > > more or less expected (it all depends on how many bitflips you have in
> > > the faulty block). It's less likely on NANDs requiring 1bit/512bytes
> > > ECC, and if that happens on such NANDs, you may have a problem in the
> > > controller driver.    
> > 4 bits ECC per 512 bytes, from memory 28 bytes in OOB, using software 
> > ECC in the MTD driver.
> > As I said, I believe the better threshold is hiding the root cause. It 
> > is only a band-aid.  
> 
> What you describe will anyway happen sooner or later: if you're using
> almost al LEBs, and the remaining free ones are all impacted by the
> correctable bit-flip issue you'll have to use them anyway. So, yes,
> this is a band-aid, just like your solution is just improving things
> but not really solving the issue. This being said, if the blocks
> really show too many bitflips, they should be marked bad at some point,
> because during the scrubbing process we do write a pattern and check
> that we can read it back. I'll have to double check, but I think we're
> also checking for EUCLEAN and mark the block bad when that happens.

Hm, actually we're not torturing the source PEB when moving a LEB
because of bitflips (probably because it's expensive and tends to wear
the block even faster) :-/. The destination PEB is tortured if we fail
to read the VID header back, which is definitely not a guarantee that
other data are readable or do not contain too much bitflips.

There's definitely something to improve there.

  reply	other threads:[~2018-08-17 15:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-17  0:34 [RFC PATCH] UBI fixable bit-flip issue Mark Spieth
2018-08-17  8:25 ` Boris Brezillon
2018-08-17 14:33   ` Mark Spieth
2018-08-17 14:53     ` Boris Brezillon
2018-08-17 15:22       ` Boris Brezillon [this message]
2018-08-20  0:40         ` Mark Spieth
2018-08-20  8:36           ` Boris Brezillon
2018-08-20 10:01             ` Arnaud Mouiche

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=20180817172246.45fa784c@bbrezillon \
    --to=boris.brezillon@bootlin.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mspieth@digivation.com.au \
    --cc=richard@nod.at \
    /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.