From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bitbox.plus.com ([81.174.226.42] helo=galago.localnet) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1UJU69-0003Du-KT for linux-mtd@lists.infradead.org; Sat, 23 Mar 2013 19:27:27 +0000 Message-ID: <514E0229.5040502@bitbox.co.uk> Date: Sat, 23 Mar 2013 19:27:37 +0000 From: Peter Horton MIME-Version: 1.0 To: David Mosberger-Tang Subject: Re: on-die ECC support References: <514C147B.3030609@bitbox.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "linux-mtd@lists.infradead.org" List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 22/03/2013 21:14, David Mosberger-Tang wrote: > > I ended up going with a brutally simple approach: read the page and if > it gets the REWRITE status bit, read it again with on-die ECC turned > off, then do a bitdiff of the data read (and the ECC bytes read) to > count the number of bitflips. While perhaps brutish, this approach > has the advantage of only relying on documented features. As long as > the layout described by ecc->layout is accurate, this should work > reliably. Thus, Micron can screw around with the ECC encoding as they > wish, as long as the layout doesn't change, we're fine. > I prefer this solution to ours, much simpler and probably faster too. > Note that the patch below doesn't check for bitflips in the OOB areas > that Micron calls "User metadata I". We don't care about those bits > since our file system doesn't use OOB at all. > > Do you have any recommendation on a good value for bitflip_threshold? > 1 is obviously too small and 4 feels a bit like playing with fire, no? > IIRC we reprted only when there were three or more bit errors in a page. This would allow two bits with fixed states per page. P.