Message-ID: <20160614113426.3950e3e4@bbrezillon>
Date:	Tue, 14 Jun 2016 11:34:26 +0200
From:	Boris Brezillon <boris.brezillon@...e-electrons.com>
To:	"George Spelvin" <linux@...encehorizons.net>
Cc:	beanhuo@...ron.com, computersforpeace@...il.com,
	linux-kernel@...r.kernel.org, linux-mtd@...ts.infradead.org,
	richard@....at
Subject: Re: [PATCH 2/4] mtd: nand: implement two pairing scheme

On 14 Jun 2016 05:07:26 -0400
"George Spelvin" <linux@...encehorizons.net> wrote:

> Boris Brezillon wrote:
> > On 12 Jun 2016 16:24:53 George Spelvin wrote:  
> >> Boris Brezillon wrote:
> >> My problem is that I don't really understand MLC programming.  
> 
> > I came to the same conclusion: we really have these 2 cases in the
> > wild, which makes it even more complicated to define a standard
> > behavior.  
> 
> I did find a useful stuy of the issue: "Program Interference in MLC NAND
> Flash Memory: Characterization, Modeling, and Mitigation"
> 
> https://users.ece.cmu.edu/~omutlu/pub/flash-programming-interference_iccd13.pdf
> 
> It describes the write-disturb-precompensation technique, and also
> shows how the two-stage programming works.  (Although the fact that the
> "least significant bit" is the *largest* voltage difference and is shown
> on the *left* makes no sense at all.)
> 
> Looking at the demonstrated programming sequence, it looks like
> it should be possible to probe for the bit assignment.  If you have
> a half-programmed page, then any bits programmed to "0" are actually
> sitting close to the threshold between the two middle voltage levels.
> 
> So you'll get a lot of errors reading them as "1", but the interesting
> part is the read-back of the unprogrammed bit.
> 
> If the chip is using the binary sequence, you'll read either 10 or 01.
> If the chip us ising the Gray-code sequence, you'll read 10 or 00.
> 
> Basically, you read both pages and see which bit combination never
> appears.  That is the combination that corresponds to the highest voltage
> level.
> 
> Another interesting paper is "Read Disturb Errors in MLC NAND Flash
> Memory: Characterization, Mitigation, and Recovery"
> https://users.ece.cmu.edu/~omutlu/pub/flash-read-disturb-errors_dsn15.pdf
> 
> That talks about tricks that do as you observe: increase read error to start.
> (In order to decreaease read disturb, and thus read errors later.)

Thanks a lot for sharing your thoughts along with all these references,
that's really useful. I'll carefully read all of them.

> 
> >> It's more considering it to have 16K pages that can be accessed in half-pages.  
> 
> > Yes, I know, but it's not really easy to fake that at the NAND level,
> > because programming 2 pages still requires 2 page program operation.
> > The MTD user could detect that the pairing scheme always exposes 2
> > consecutive non-paired pages, but as you've seen, this condition does
> > not necessarily imply the 'pair coupling' constraint, and we don't want
> > to increase the min_io_size value if it's not really necessary.  
> 
> Ideally, it would be nice to separate the "SLC hack" from the "later
> write failures can corrupt earlier data" workaround.
> 
> First, you get the latter working on SLC flash.

When you say SLC flash, you're talking about MLC NANDs operating in SLC
mode, right?

> Then you add MLC, and
> make MLC another reason why it can happen.
> 
> But I'm not certain this is actually necessary.  Could listing 4 pages
> rather than 2 as in other data sheets just be an editing or translation
> error?  Maybe someoe got confused about "in the same row" when they
> wrote that clarifying example.

Yes, that's what I supposed. I'll try to test that on a real device.

> 
> > I'm just realizing this is actually a non-issue for the solution we
> > developed with Ricard.  As I said, it's unsafe to partially write a
> > block in MLC mode, so the only sane way is either to write a block in
> > SLC mode, or atomically write a block in MLC mode, and that's what
> > we're doing with our 'UBI LEB consolidation' approach.  I'm pretty sure
> > the problem described in the Hynix datasheet does not happen when only
> > writing in SLC mode.  So, even if the pairing scheme does not account
> > for this extra 'coupling' constraint, we should be safe.  
> 
> I can't see any reason why it would affect MLC and not SLC.

That's something we'll have to check on a real NAND exposing this
constraint (I'll try to find a board with one of these NANDs), but if
that's really the case, and programming page 1 can really spoil page 0
even if they're not sharing the same cells, then that's a big problem.

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Powered by blists - more mailing lists