All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jeff Lauruhn (jlauruhn)" <jlauruhn@micron.com>
To: Richard Weinberger <richard@nod.at>,
	Boris Brezillon <boris.brezillon@free-electrons.com>,
	Andrea Marson <andrea.marson@dave.eu>
Cc: Andrea Scian <rnd4@dave-tech.it>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"dedekind1@gmail.com" <dedekind1@gmail.com>
Subject: RE: RFC: detect and manage power cut on MLC NAND (linux-mtd Digest, Vol 144, Issue 70)
Date: Wed, 18 Mar 2015 17:11:46 -0000	[thread overview]
Message-ID: <0D23F1ECC880A74392D56535BCADD7354973EA09@NTXBOIMBX03.micron.com> (raw)
In-Reply-To: <55096A75.8080207@nod.at>

Disturb is a block level affect, but in operation data is often layout in continuous blocks, so if one block is seeing a lot of reads or P/E cycles, there's a high probability the blocks around it are also seeing very similar read and P/E patterns. 



Jeff Lauruhn
NAND Application Engineer
Embedded Business Unit



-----Original Message-----
From: Richard Weinberger [mailto:richard@nod.at] 
Sent: Wednesday, March 18, 2015 5:07 AM
To: Boris Brezillon; Andrea Marson
Cc: Jeff Lauruhn (jlauruhn); linux-mtd@lists.infradead.org; Andrea Scian; dedekind1@gmail.com
Subject: Re: RFC: detect and manage power cut on MLC NAND (linux-mtd Digest, Vol 144, Issue 70)

Am 18.03.2015 um 10:06 schrieb Boris Brezillon:
>> 1) IIUC read/program disturb effects exhibit at block level.
>> In a typical embedded linux systems there are software parts - 
>> bootloader, kernel image etc. - that virtually are never changed 
>> (almost
>> ...) but are read many times. Other parts - application libraries, 
>> log files etc. - are read and wrote many times instead.
>> If these two kinds of software are stored in different MTD partitions 
>> - ket's say partition A for bootloader, kernel etc. and partition B 
>> for application libraries, log files etc. - can we say that 
>> read/write operations performed on partition B have no disturb effects on partition A?
> 
> AFAIK, read/write disturb effects only occur on pages of the same 
> block, so we shouldn't see bitflips on partition A caused by 
> read/write on partition B.

I already saw corruptions on nearby blocks but I'm not sure if really plain read disturb was the root cause as this NAND chips showed in general funny symptoms.

Jeff, can you tell us more?

Thanks,
//richard

  reply	other threads:[~2015-03-18 17:11 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-10 11:57 RFC: detect and manage power cut on MLC NAND Andrea Scian
2015-03-10 12:51 ` Richard Weinberger
2015-03-11  7:20   ` Artem Bityutskiy
2015-03-11  8:57     ` Richard Weinberger
2015-03-11  9:05       ` Artem Bityutskiy
2015-03-11  9:09         ` Richard Weinberger
2015-03-11 17:01           ` Andrea Scian
2015-03-11 17:23             ` Jeff Lauruhn (jlauruhn)
2015-03-11 17:29               ` Richard Weinberger
2015-03-11 21:16                 ` Jeff Lauruhn (jlauruhn)
2015-03-12 10:28                   ` Richard Weinberger
2015-03-12 22:57                     ` Jeff Lauruhn (jlauruhn)
2015-03-13 20:31                       ` Boris Brezillon
2015-03-13 23:51                         ` Jeff Lauruhn (jlauruhn)
2015-03-14  9:46                           ` Andrea Marson - DAVE Embedded Systems
2015-03-16 16:02                             ` Jeff Lauruhn (jlauruhn)
2015-03-17  8:00                               ` Andrea Scian
2015-03-14 10:32                           ` Boris Brezillon
2015-03-16 21:11                             ` Jeff Lauruhn (jlauruhn)
2015-03-17  9:30                               ` Andrea Scian
2015-03-17 10:02                                 ` Boris Brezillon
2015-03-17 16:42                                   ` Jeff Lauruhn (jlauruhn)
2015-03-18  8:45                                     ` RFC: detect and manage power cut on MLC NAND (linux-mtd Digest, Vol 144, Issue 70) Andrea Marson
2015-03-18  9:07                                       ` Boris Brezillon
2015-03-18  9:56                                         ` Andrea Marson
2015-03-18 10:03                                           ` Boris Brezillon
2015-03-18 12:07                                         ` Richard Weinberger
2015-03-18 17:11                                           ` Jeff Lauruhn (jlauruhn) [this message]
2015-03-18 16:12                                       ` Jeff Lauruhn (jlauruhn)
2015-03-19  8:47                                         ` RFC: detect and manage power cut on MLC NAND Andrea Marson
2015-03-19  9:12                                           ` Boris Brezillon
2015-03-19 17:45                                             ` Jeff Lauruhn (jlauruhn)
2015-03-20  0:25                                             ` Iwo Mergler
2015-03-20  3:38                                               ` nick
2015-03-20  5:40                                                 ` Iwo Mergler
2015-03-20  8:26                                               ` Boris Brezillon
2015-03-20 17:15                                                 ` Nick Krause
2015-03-22 23:45                                                 ` Iwo Mergler
2015-03-23  2:18                                                 ` Iwo Mergler
2015-03-23  7:06                                                   ` Artem Bityutskiy
2015-03-23 19:05                                                     ` Boris Brezillon
2015-03-24  7:05                                                       ` Artem Bityutskiy
2015-03-19 18:00                                           ` Jeff Lauruhn (jlauruhn)
2015-03-20  8:07                                             ` Andrea Marson
2015-03-17 17:04                                 ` Jeff Lauruhn (jlauruhn)
2015-03-16  9:01                         ` Ricard Wanderlof
2015-03-16 17:27                           ` Jeff Lauruhn (jlauruhn)
2015-03-14 10:03                       ` Richard Weinberger
2015-03-12  9:32               ` Ricard Wanderlof
2015-03-23  4:08           ` Iwo Mergler
2015-03-23 21:15             ` Jeff Lauruhn (jlauruhn)
2015-03-24  1:17               ` Iwo Mergler
2015-03-24 16:50                 ` Jeff Lauruhn (jlauruhn)
2015-03-25  3:38                   ` Iwo Mergler
2015-03-25  8:33                     ` Ricard Wanderlof
2015-03-26  1:57                       ` Jeff Lauruhn (jlauruhn)
2015-03-26  8:55                         ` Ricard Wanderlof
2015-03-11  7:21 ` Artem Bityutskiy
     [not found] <mailman.37176.1426610573.22890.linux-mtd@lists.infradead.org>

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=0D23F1ECC880A74392D56535BCADD7354973EA09@NTXBOIMBX03.micron.com \
    --to=jlauruhn@micron.com \
    --cc=andrea.marson@dave.eu \
    --cc=boris.brezillon@free-electrons.com \
    --cc=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard@nod.at \
    --cc=rnd4@dave-tech.it \
    /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.