All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Mike Dunn <mikedunn@newsguy.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: ubi on MLC nand flash
Date: Tue, 08 Nov 2011 23:32:03 +0200	[thread overview]
Message-ID: <1320787925.17770.31.camel@koala> (raw)
In-Reply-To: <4EB6A6A8.7010703@newsguy.com>

On Sun, 2011-11-06 at 07:24 -0800, Mike Dunn wrote:
> Hi everyone,
> 
> I recently started to do serious testing of UBI on the diskonchip G4 MLC nand
> driver I'm finishing up.

Sounds promising - we've got another serious mtd community memeber! :-)

>   I started with the io_basic ubi test in mtd-utils.

Makes sense to exclude UBIFS and test UBI directly first indeed.

> What I find is that, after a few minutes, enough PEBs are marked as bad to
> exhaust the reserve PEB pool

I guess you can make it larger, the default 1% is just something which
was good enough for our super-robust OneNAND flash.

Also, for MLC you probably want a smaller WL threshold, I heard that
modern MLCs have ereaseblock liftimes smaller than 10000 erase-cycles.
So the default 4096 might be too big.

> , UBI switches to r/o mode, and the test fails.  The
> reason is that - on this device at least - bit flips seem to be persistent;
> i.e., you will get e.g. 1 bit flip every time you read a certain page. 
> Consequently, when the bit flip occurs and the PEB gets scrubbed, the torture
> test fails because the bit flip reoccurs, and the PEB is marked bad.

A quick hack you can do to go further in your investigations without
being block by this issue is to hack your driver and make it to just not
return -EUCLEAN in case of 1 bit flip or may be even 2. Then you can see
ahead what else happens to UBI.

WRT the real solution - I agree with Ivan - see his e-mail, and I'll
send some comments on that.

> I expected that eventually I might have to dig into the "program disturb",
> "read-disturb" or "paired pages" MLC issues, but the problem seems more
> fundamental.  My general impression is that UBI is too unforgiving for this
> device.  The ecc can correct up to 4 bit flips, so 1 bit flip seems to not be a
> big deal.  I'm new to UBI so this is not a critique or a proposal, I'm just
> hoping some experts can offer some advice or opinions.  The obvious remedy is to
> set a higher threshold for marking a PEB as bad, say 2 or 3 bit flips.

You are right - UBI is too unforgiving. But this should be fixable, it
just needs a brave knight to do the job :-)

Artem.

  parent reply	other threads:[~2011-11-08 21:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-06 15:24 ubi on MLC nand flash Mike Dunn
2011-11-06 17:35 ` Ivan Djelic
2011-11-06 20:28   ` Mike Dunn
2011-11-08 21:45     ` Artem Bityutskiy
2011-11-09  3:04       ` Mike Dunn
2011-11-09  8:44         ` Artem Bityutskiy
2011-11-09 13:13           ` Mike Dunn
2011-11-09 12:22             ` Artem Bityutskiy
2011-11-08 21:32 ` Artem Bityutskiy [this message]
2011-11-09  1:51   ` Mike Dunn

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=1320787925.17770.31.camel@koala \
    --to=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mikedunn@newsguy.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.