From mboxrd@z Thu Jan 1 00:00:00 1970 In-Reply-To: References: <16826B66-31FE-41AD-A6EF-E668A45AF1FE@prograde.net> <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? Message-ID: From: Joakim Tjernlund Date: Thu, 10 Feb 2011 16:04:59 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 Cc: linux-mtd-bounces@lists.infradead.org, stefan.bigler@keymile.com, Michael Cashwell , linux-mtd@lists.infradead.org, =?ISO-8859-15?Q?Anders_Grafstr=F6m?= , Holger brunck 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? A simpler impl. would be a suspend counter. When no. of suspends > 1000, do usleep(500) or usleep(500) every 100-500 suspends. Jocke