Re: [PATCH 2/5] fusion: vmware bug fix prevent inifinite retries

[Michael Reed <mdr@sgi.com>]

Moore, Eric wrote:
> On  Monday, January 08, 2007 3:25 PM, James Bottomley wrote:
> 
>> Right, I sort of suspected something like this.  BUSY/QUEUE_FULL
>> handling was a bit iffy in 2.4; but it was sorted out in the 2003/4
>> timeframe.  Nowadays, I think you want to translate the
>> MPI_SCSI_STATUS_BUSY directly to SAM_STAT_BUSY (i.e. just remove the
>> special casing if).

Christoph put in code to limit a command's lifetime to prevent infinite
loops in the case of QUEUE_FULL and BUSY.  (See scsi_softirq_done()
for implementation.)

DID_OK / COMMAND_COMPLETE / BUSY results in a ADD_TO_MLQUEUE for a retry,
same as QUEUE_FULL.  I don't infinite retries, just a whole lot of them.
See scsi_decide_disposition().

Mike

>>
> 
> I think your'e on the same page with the folks from VMware,
> where the've asked us to go back to our old driver code.
> Meaning we kill the check for "MPI_SCSI_STATUS_BUSY", instead the sam
> status
> is sent back "as is" without changing the DID_OK to DID_BUS_BUSY, etc. 
> 
> My problem with that is whether is breaks the Fibre Channel Folks. 
> Will FC failover solution work properly if we go back to the old code?
> I add Stephen Shirron and Mike Reed. 
> I don't know.   Here is an explanation why that fix was needed back
> about a year ago:
> 
> 
> "When a target device responds with BUSY status, the MPT driver was
> sending DID_OK to the 
> SCSI mid layer, which caused the IO to be retried indefinitely between
> the mid layer and the 
> driver.  By changing the driver return status to DID_BUS_BUSY, the
> target BUSY status can 
> now flow through the mid layer to an upper layer Failover driver, which
> will manage the I/O timeout."
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
>