From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Reed Subject: Re: [PATCH 1/6] mpt fusion - fibre channel target discovery prematurely terminates Date: Mon, 22 May 2006 12:31:12 -0500 Message-ID: <4471F560.8050709@sgi.com> References: <446CD224.6060806@sgi.com> <1148139217.3529.19.camel@mulgrave.il.steeleye.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from omx2-ext.sgi.com ([192.48.171.19]:14482 "EHLO omx2.sgi.com") by vger.kernel.org with ESMTP id S1751078AbWEVRbQ (ORCPT ); Mon, 22 May 2006 13:31:16 -0400 In-Reply-To: <1148139217.3529.19.camel@mulgrave.il.steeleye.com> Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: James Bottomley Cc: linux-scsi James Bottomley wrote: > On Thu, 2006-05-18 at 14:59 -0500, Michael Reed wrote: >> mpt_config() can return EAGAIN. When this happens, fibre channel target >> discovery can prematurely terminate with fewer than the total number of >> targets discovered. This patch detects EAGAIN and reschedules the scan >> work. >> >> Generally, this situation only occurs when the lsiutil program is being >> used to reset the board. > > mpt_config() only returns EAGAIN when it's out of message frames. That > should be a very transient condition, so if this rarely occurs anyway, > why not just put an msleep(10) on the condition and then retry? It > would save all the requeue logic. It's not so transient during reset processing. I've measured 10 to 15 seconds of elapsed time. But, it always eventually succeeds. Mike > > James > >