All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
To: Steve deRosier <derosier@gmail.com>, linux-mtd@lists.infradead.org
Subject: Re: NAND ECC capabilities
Date: Thu, 08 Jan 2015 01:17:49 -0300	[thread overview]
Message-ID: <54AE04ED.8080002@vanguardiasur.com.ar> (raw)
In-Reply-To: <CALupW3DF2BmHBjm11yiBMLFSwX-yNFeW3q_EDyEWsBQrFPU-xw@mail.gmail.com>

On 01/08/2015 12:10 AM, Steve deRosier wrote:
> So, doing further experiments and I wondered if someone could confirm
> this finding.
> 
> With atmel_nand, we're setup for 4-bit ECC on 512 sectors with a 2k
> page.  I was thinking about this a bit and realized that there's 4 of
> these sectors per page, and this implies then that we can detect and
> correct 4 bad bits _per_ each sector.  Assuming that they're evenly
> spread, that's up to 16 bad bits per page.  Obviously in practice,
> that assumption wouldn't hold...
> 

Not sure why you say that woulnd't hold.

> So, is my understanding correct?
> 

I'm not familiar with atmel-nand, but as far as I know, you are right. A
4-bit ECC strength over 512 byte sectors, means exactly that.

Most likely your ECC hardware stores four ECC values (one for each
512-byte sector in your 2048-byte page) in the OOB of the page. Each ECC
value is used to correct up to 4-bit on each sector, so that's why you
can correct as much as that.

> I took it further and decided to play with this experimentally. On my
> UBIFS rootfs, I flipped 3 bits in the first sector of a page and then
> 3 more in the second sector.  From my kernel log I got this:
> 
> [   78.304687] atmel_nand 40000000.nand: Bit flip in data area,
> byte_pos: 98, bit_pos: 3, 0x31 -> 0x39
> [   78.304687] atmel_nand 40000000.nand: Bit flip in data area,
> byte_pos: 98, bit_pos: 2, 0x39 -> 0x3d
> [   78.304687] atmel_nand 40000000.nand: Bit flip in data area,
> byte_pos: 98, bit_pos: 1, 0x3d -> 0x3f
> [   78.304687] atmel_nand 40000000.nand: Bit flip in data area,
> byte_pos: 530, bit_pos: 6, 0x8e -> 0xce
> [   78.304687] atmel_nand 40000000.nand: Bit flip in data area,
> byte_pos: 530, bit_pos: 5, 0xce -> 0xee
> [   78.304687] atmel_nand 40000000.nand: Bit flip in data area,
> byte_pos: 530, bit_pos: 4, 0xee -> 0xfe
> [   78.304687] UBI: fixable bit-flip detected at PEB 20
> [   78.304687] UBI: schedule PEB 20 for scrubbing
> [   78.328125] atmel_nand 40000000.nand: Bit flip in data area,
> byte_pos: 98, bit_pos: 3, 0x31 -> 0x39
> [   78.328125] atmel_nand 40000000.nand: Bit flip in data area,
> byte_pos: 98, bit_pos: 2, 0x39 -> 0x3d
> [   78.328125] atmel_nand 40000000.nand: Bit flip in data area,
> byte_pos: 98, bit_pos: 1, 0x3d -> 0x3f
> [   78.328125] atmel_nand 40000000.nand: Bit flip in data area,
> byte_pos: 530, bit_pos: 6, 0x8e -> 0xce
> [   78.328125] atmel_nand 40000000.nand: Bit flip in data area,
> byte_pos: 530, bit_pos: 5, 0xce -> 0xee
> [   78.328125] atmel_nand 40000000.nand: Bit flip in data area,
> byte_pos: 530, bit_pos: 4, 0xee -> 0xfe
> [   78.343750] UBI: fixable bit-flip detected at PEB 20
> [   78.382812] UBI: scrubbed PEB 20 (LEB 0:18), data moved to PEB 250
> 
> So, my takeaway from this is a couple of things:
> 
> 1. Yes, it can correct more than 4 bits per page as long as those are
> on different sectors of the page.

Correct. It can correct as much as advertised: 4-bits per 512-byte sector.

> 2. My test of 6 bits hit the 4 bit threshold setting and at that point
> UBI decided that maybe something is wrong with that PEB.

Correct. Read/program disturb accumulates and that produces bitflips.
Given these bitflip can be eliminated by erasing the block, UBI will do
that before the block get worse.

> 3. When it did, UBI corrected the data and copied it elsewhere

Actually, your NAND controller (or MTD software ECC) corrected the data
and reported the number of bitflips to UBI.

> 4. Then UBI scrubbed. I assume it then did the torture test. Since I
> manually made a flip, it found it was fine once it erased it, so it
> didn't mark it as bad.  I checked my BBT and it's not marked. So I
> assume it's erased and ready for use again.
> 

Yes, UBI tortures the PEB on occassions. However, this does happen only
under certain circumstances (you'll have to dig the code for details). I
don't think it was tortured in your case (the block just had a few
artifitial bitflips, but other than that it was healthy).

Torture comes with a noisy message "run torture test for PEB %d", so you
would notice.

> Is my general understanding correct?
> 

I think so, yes.
-- 
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar

  reply	other threads:[~2015-01-08  4:20 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 [this message]
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
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=54AE04ED.8080002@vanguardiasur.com.ar \
    --to=ezequiel@vanguardiasur.com.ar \
    --cc=derosier@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    /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.