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

Michael Reed
2007-01-09T16:17:36Z

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
>
>