All of lore.kernel.org
 help / color / mirror / Atom feed
From: Calvin Johnson <linux.cj@gmail.com>
To: Ivan Djelic <ivan.djelic@parrot.com>
Cc: Mike Dunn <mikedunn@newsguy.com>,
	Artem Bityutskiy <dedekind1@gmail.com>,
	Richard Weinberger <richard@nod.at>,
	Kevin Cernekee <cernekee@gmail.com>,
	Jim Quinlan <jim2101024@gmail.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Joel Reardon <reardonj@inf.ethz.ch>,
	"peter.barada@gmail.com" <peter.barada@gmail.com>,
	Brian Norris <computersforpeace@gmail.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Shmulik Ladkani <shmulik.ladkani@gmail.com>
Subject: Re: MLC NAND: all 0xff after erase?
Date: Thu, 9 Aug 2012 09:20:43 +0530	[thread overview]
Message-ID: <CAEhpT-VkFDoU+mzOsEiKUrB_N5smyP8_ynfTLN2ReUWT2i354g@mail.gmail.com> (raw)
In-Reply-To: <20120807200044.GA9929@parrot.com>

On Wed, Aug 8, 2012 at 1:30 AM, Ivan Djelic <ivan.djelic@parrot.com> wrote:
> On Tue, Aug 07, 2012 at 11:08:04AM +0100, Calvin Johnson wrote:
>> Hello Ivan,
>>
>>
>> >>Due to the nature of NAND bitflips, I cannot see how a NAND datasheet
>> >> could guarantee such a thing (what would be the duration of a "0xff
>> >> guarantee" anyway ?). In practice, bitflips do appear already on 34nm SLC
>> >> devices, on blocks that have just been erased; hence I am not surprised
>> >> by your own findings on MLC devices.
>>
>>
>> Are these bit flips occurring due to power fluctuations while performing program/erase as mentioned in http://www.linux-mtd.infradead.org/doc/ubifs.html#L_unstable_bits ?
>
> Hello Calvin,
>
> No, the bitflips I was referring to are not caused by an interrupted erase or program operation.
> They just appear when reading back an erased block. They sometimes exhibit a specific pattern: the same bit column is flipped on multiple
> pages in the same block.
>

Thanks a lot Ivan. From some experts, I got some more info about the
reason behind this behaviour. I'm sharing them below.

-------------------------------------------------------------------------------------------------------------------------------------------------------------
The memory array is composed of strings of cells and numerous rows of
parallel selection lines.  When the array is being read these lines
are energized.  Granted, it is a low voltage.  But, as you know, any
electrical potential difference introduces the possibility of electron
migration.  At the current geometry technology, we’re only storing
about 100 electrons on a gate (That’s not a spec’ed count).  If you
multiply even a small possibility times 16,000,000,000 bits and a
large number of reads, it’s not unreasonable to expect an occasional
bit shift.
-------------------------------------------------------------------------------------------------------------------------------------------------------------
it is due to the fact that some bits are not well inside the
distribution of the programmed cells.
Some bits are not "substituted" because can be corrected by the ECC,
but when programmed they are in the edges of the distribution and can
be read differently.
Obviously this “not screened” bits can be managed and corrected using
the specified ECC .
-------------------------------------------------------------------------------------------------------------------------------------------------------------

best regards,
Calvin

  reply	other threads:[~2012-08-09  3:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-11  0:36 MLC NAND: all 0xff after erase? Brian Norris
2012-07-11  6:41 ` Richard Genoud
2012-07-13 21:22   ` Brian Norris
2012-07-11 16:46 ` Mike Dunn
2012-07-11 17:43 ` Ivan Djelic
2012-08-07 10:11   ` Calvin Johnson
     [not found]   ` <CAEhpT-UMk0hiDaKAwn8GtS0B3HHRudbSUSHpZ68-i+LmMNH-=A@mail.gmail.com>
2012-08-07 20:00     ` Ivan Djelic
2012-08-09  3:50       ` Calvin Johnson [this message]
2012-08-17  9:51   ` Artem Bityutskiy
2012-08-17 13:54     ` Matthieu CASTET

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=CAEhpT-VkFDoU+mzOsEiKUrB_N5smyP8_ynfTLN2ReUWT2i354g@mail.gmail.com \
    --to=linux.cj@gmail.com \
    --cc=cernekee@gmail.com \
    --cc=computersforpeace@gmail.com \
    --cc=dedekind1@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=ivan.djelic@parrot.com \
    --cc=jim2101024@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mikedunn@newsguy.com \
    --cc=peter.barada@gmail.com \
    --cc=reardonj@inf.ethz.ch \
    --cc=richard@nod.at \
    --cc=shmulik.ladkani@gmail.com \
    --cc=viro@zeniv.linux.org.uk \
    /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.