On Friday, February 02, 2007 4:34 PM, Edward Goggin wrote: > On Fri, 2007-02-02 at 17:18 -0600, James Bottomley wrote: > > On Fri, 2007-02-02 at 18:11 -0500, Edward Goggin wrote: > > > That solution doesn't work for the RDAC/MPP driver as the > BUSY status > > > handler retries indefinitely. We need a solution which > works for both a > > > bare metal host running RDAC/MPP which for this use case, > wants to get > > > control over the failed command ASAP and a VMware host > which may need to > > > retry longer than DID_BUS_BUSY currently allows for. > > > > No it doesn't, not any longer... the mid-layer retries for > the command > > up to its timeout before failing. That's the point about > questioning > > the validity of the original problem. > > > > James > > > > > > I think I see your argument ... retries for BUSY and all > other scsi/host > status's are limited by the code in scsi_softirq_done which > filters the > disposition returned by scsi_decide_disposition, so no status > will yield > an indefinite retry. > > Not clear if that's soon enough for RDAC/MPP. For the VMware case, it > appears to allow an additional 30 seconds (beyond what DID_BUSY_BUSY > would allow) for a retry. > > Yanling, comments? IMO we can kill the code that interprets the BUSY sam status. Eric - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
