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 [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > > - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
