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