Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754050AbbG2QBJ (ORCPT ); Wed, 29 Jul 2015 12:01:09 -0400 Received: from mx.dave-tech.it ([2.229.21.40]:48123 "EHLO mx.dave-tech.it" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752795AbbG2QBH (ORCPT ); Wed, 29 Jul 2015 12:01:07 -0400 Subject: Re: [PATCH 5/6] mtd: nand: gpmi: correct bitflip for erased NAND page To: Han Xu References: <1438105841-22314-1-git-send-email-b45815@freescale.com> <55B88952.1060709@dave-tech.it> Cc: "linux-mtd@lists.infradead.org" , Han Xu , Fabio Estevam , boris.brezillon@free-electrons.com, Huang Shijie , linux-kernel@vger.kernel.org, Nicholas Mc Guire , Brian Norris , David Woodhouse From: Andrea Scian Message-ID: <55B8F8BE.4060005@dave-tech.it> Date: Wed, 29 Jul 2015 18:01:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 150729-0, 29/07/2015), Outbound message X-Antivirus-Status: Clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3220 Lines: 76 Il 29/07/2015 16:34, Han Xu ha scritto: > Hi Andrea, > > The threshold gf/2 is referred to Huang Shijie's previous patch for bitflip, > > http://lists.infradead.org/pipermail/linux-mtd/2014-January/051513.html Thanks for pointing out the reference. Looking forward on the same thread, I saw that Brian already have some doubt about having the threshold correlated with gf instead of ecc_strength. I think in this way (until someone, e.g. from micron, tell me something different ;-) ): erased pages act like the programmed one. They have bitflips and, unfortunately, cannot be protected by an ECC-like algorithm. If, let's say, your NAND device need a 30 bit ECC protection over 1024 byte page, this is nearly the same for an erased page. As additional thought: what happens if you reports that an erased page has too much bitflips? UBIFS will fail badly [1] Usually you never reach the "uncorrectable ECC error" level on standard situation (even on MLC ;-) ) because as soon as bitflips are more than a given threshold [2] those blocks are scrubbed and you're in the safe area again. If you report ECC errors before this threshold, I think we fake the scrubbing functionality of UBI (which, yes, AFAIK should work on erased blocks too, why not?) As first instance I would choose ECC strength as value to use, apart from the fact that I'm wondering what's happens if: * my erased block is close to this value (let's say ECC strength -1) * I write some data on it (with ECC) * this write probably increase bitflips (only an erase operation will lower bitflip events) and, even worst, it will point me close to "ECC strength + 1" bitflips > To verify the function, I raw write the whole NAND page with 0xFF and several > scattered bits with 0x0 to fake the bitflip, since the real bitflip is > unpredictable and tested the feature with Micron MT29F64G08AFAAA. Ok thanks. IIUC MT29F64G08AFAAA is an SLC NAND device but probably, due it's size, not a "real" SLC device and should have MLC like behavior. I think you can easily trigger this situation (as I do) as follows: * ubiformat, ubiattach, ubimkvol on a NAND MTD partition * mount -t ubifs that volume * get the physical address of LEB1 and LEB2 (somehow.. ;-) ). They have lots of erased space that UBIFS will check at boot time * umount, ubidetach the partition * do a nanddump lots of times (let's say from 10k to 100k) on those two PEBs * sooner or later you'll see some bitflips on erased page * try to mount UBIFS again: without patch it should fail, with your addition you should see that your erased-page check works correctly and UBIFS mounts successfully Maybe I'm a bit OT regarding this patch, but I think this is an interesting point to discuss about. Any comment is welcome Kind Regards, -- Andrea SCIAN DAVE Embedded Systems [1] http://lists.infradead.org/pipermail/linux-mtd/2015-July/060168.html [2] http://lists.infradead.org/pipermail/linux-mtd/2015-January/057334.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/