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 1PnZ1h-0005yT-4S for linux-mtd@lists.infradead.org; Thu, 10 Feb 2011 16:05:49 +0000 In-Reply-To: <85661EDC-9882-41B1-A926-0A88EF1CEF2E@prograde.net> 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> <85661EDC-9882-41B1-A926-0A88EF1CEF2E@prograde.net> Subject: Re: Numonyx NOR and chip->mutex bug? To: Michael Cashwell Message-ID: From: Joakim Tjernlund Date: Thu, 10 Feb 2011 17:05:46 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: linux-mtd@lists.infradead.org, stefan.bigler@keymile.com, Holger brunck , =?ISO-8859-15?Q?Anders_Grafstr=F6m?= List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Michael Cashwell wrote on 2011/02/10 16:59:50: > > > A simpler impl. would be a suspend counter. When no. of suspends > 1000, do usleep(500) or usleep(500) every 100-500 suspends. > > Our messages crossed each other. I just saw this problem with 29 suspends. > > I wonder if THAT is what's different between these chips and the older 130nm parts. And none of that addresses whether or not this change is just an anomaly in this batch or if we would continue to get them. > > I'm going to run my test on the older 130nm (2003 vintage) parts just for grins. Here is another idea, don't resume between every write_buffer etc. If less than 500 us has passed, just continue with the next write_buffer. That would be much more efficient.