From: Ivan Djelic <ivan.djelic@parrot.com>
To: Calvin Johnson <linux.cj@gmail.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: Tue, 7 Aug 2012 22:00:44 +0200 [thread overview]
Message-ID: <20120807200044.GA9929@parrot.com> (raw)
In-Reply-To: <CAEhpT-UMk0hiDaKAwn8GtS0B3HHRudbSUSHpZ68-i+LmMNH-=A@mail.gmail.com>
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.
> If that is the case, I am observing a different problem with a MLC NAND flash.
>
> I wrote 4K bytes of data and read back the same 4K several times. The page size is 4K. I am NOT performing multiple erase/programs. Please note that I am reading back the same data which sometimes matches exactly what was written and sometimes does not, showing bit flips at random locations. I am not using any ECC to correct the bit errors, which of course will be done later as I'm trying to understand this problem.
Is the amount of observed errors always within the ECC range recommended for this device ?
> Is this behavior expected in MLC NANDs? Is there any reference document/links which discuss more about this?
>
> I have read about read disturb errors but as I understand it is a permanent error.(http://www.klabs.org/richcontent/MemoryContent/nvmt_symp/nvmts_2002/docs/12/12_dan_p.pdf )
> ----------------------------------------------------------------------------------------------
> Read Disturb Errors
> The read disturb effect causes a page read operation to induce a permanent, bit value change in one of the read bits. In BLC flash technology based on a 0..16μ manufacturing
> 3 process, the typical read disturb error rate is on the order of 1 bit error per 106 repetitive reads of the page containing the bit.
> Although MLC cells are more prone to such errors, the effect in actual measurements is less severe than in program disturb errors. The measured rate is on the order of 1 bit error per approximately 105 repetitive reads of the page.
>
> ----------------------------------------------------------------------------------------------
I don't have much experience with raw MLC devices, but at least I can share a few interesting docs:
* An interesting article about SLC and MLC technology: http://www.eetimes.com/design/memory-design/4390427/-SLC-vs-MLC--Which-works-best-for-high-reliability-applications-
* An overview of NAND technology from Micron: http://www.google.com/url?sa=t&rct=j&q=nand%20mlc%20erratic%20read%20errors&source=web&cd=1&ved=0CE4QFjAA&url=http%3A%2F%2Fdownload.micron.com%2Fpdf%2Fpresentations%2Fevents%2Fflash_mem_summit_jcooke_inconvenient_truths_nand.pdf&ei=MHEhUImCLcGH0AXPzYG4Aw&usg=AFQjCNGfW2BXUfAt9zLU0Nlc5WSYooZwrA&cad=rja
* A highly technical book about NAND technology, including bit error machanisms: http://books.google.com/books?id=vaq11vKwo_kC&printsec=frontcover&dq=Inside+NAND+Flash&source=bl&ots=UIULMnmFv3&sig=pqLo7iQ2HXmLvkxcWcSWgpiqEoc&hl=en&sa=X&ei=iXAhUPDRNMHS0QXgmIDACA&ved=0CDUQ6AEwAA
* A very interesting presentation from Intel: http://www.stanford.edu/class/ee380/Abstracts/081112-Fazio-slides.pdf
My guess is that the erratic/transient bitflips that you are observing are not uncommon on MLC devices...
BR,
--
Ivan
next prev parent reply other threads:[~2012-08-07 20:00 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 [this message]
2012-08-09 3:50 ` Calvin Johnson
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=20120807200044.GA9929@parrot.com \
--to=ivan.djelic@parrot.com \
--cc=cernekee@gmail.com \
--cc=computersforpeace@gmail.com \
--cc=dedekind1@gmail.com \
--cc=dwmw2@infradead.org \
--cc=jim2101024@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=linux.cj@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox