From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gw1.transmode.se ([213.115.205.20]) by canuck.infradead.org with esmtps (Exim 4.72 #1 (Red Hat Linux)) id 1PnX80-0004pQ-Lx for linux-mtd@lists.infradead.org; Thu, 10 Feb 2011 14:04:13 +0000 In-Reply-To: <4D53E660.4020305@users.sourceforge.net> References: <16826B66-31FE-41AD-A6EF-E668A45AF1FE@prograde.net> <4D4AD9ED.8060104@keymile.com> <4D4B37D4.4050204@keymile.com> <4D4BDD48.6040600@keymile.com> <541E19B8-D428-4F59-B6BB-A3BD8F455AE4@prograde.net> <0488D3BA-7BA3-4E98-B289-3F3D1DB485D4@prograde.net> Subject: Re: Numonyx NOR and chip->mutex bug? To: =?ISO-8859-15?Q?Anders_Grafstr=F6m?= Message-ID: From: Joakim Tjernlund Date: Thu, 10 Feb 2011 15:04:08 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 Cc: linux-mtd@lists.infradead.org, Holger brunck , stefan.bigler@keymile.com, Michael Cashwell List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Anders Grafström wrote on 2011/02/10 14:21:36: > > On 2011-02-09 22:59, Michael Cashwell wrote: > > On Feb 9, 2011, at 3:13 PM, Joakim Tjernlund wrote: > > > >> hmm, this sounds similar(from http://www.numonyx.com/Documents/Specification%20Updates/SU-309045_P30.pdf) > >> > >> 5. W602: erase suspend resume operation > >> Problem: P30 product may fail to erase in intensive erase/suspend/resume environments. This is > >> due to an internal firmware issue that is exhibited in certain applications that require at > >> least 3000 to 4000 erase/suspend/resume cycles during the erase of a single block. > >> Implication: Customer may see erase failure (SR reports “A0”) during a background erase. This > >> does not damage the device in any way, but data in the block may be disturbed from its > >> original state. > > I've seen this issue with Intel 28F640J5 chips as well. > > There's an old thread on it. > http://lists.infradead.org/pipermail/linux-mtd/2008-April/021266.html > > A delay was suggested similar to the one you're experimenting with I think. > http://lists.infradead.org/pipermail/linux-mtd/2008-April/021436.html Oh, I had forgotten about this thread :) I agree with the latency theory, for Numonyx there is this: W602 is the typical time between an initial block erase or erase resume command and the a subsequent erase suspend command. Violating the specification repeatedly during any particular block erase may cause erase failures. W602 is defined to 500us Adding a delay after resume will do it but is a bit crude. Possibly one could add a timestamp at resume/initial erase and a check in suspend that enough time has passed before suspending again. How does that sound? Jocke