I agree with Eric. RDAC/MPP will survive with the straight SAM BUSY status. --yanling > -----Original Message----- > From: Moore, Eric > Sent: Friday, February 02, 2007 5:59 PM > To: Edward Goggin; James Bottomley; Qi, Yanling > Cc: linux-scsi@xxxxxxxxxxxxxxx > Subject: RE: [PATCH 0/2] : definion, code, and use of new SCSI ML > hoststatus DID_COND_REQUEUE > > 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
