On Fri, 2005-01-28 at 15:24 -0800, Andrew Vasquez wrote: > ... > There seems to be two problem with this approach: > > 1. As the storage continues to return NOT_READY, > scsi_decide_disposition() blindly increments cmd->retries and > checks against cmd->allowed, returning SUCCESS (since at this > point cmd->retries is always greater than cmd->allowed) -- I've > seen this condition loop several hundred times while the > NOT_READY condition clears. > 2. as a result of the (cmd->retries > cmd->allowed) state of the > command, if a LLDD returns any status (other than DID_OK) which > could initiate a retry, the command is immediately failed. As > an example, the qla2xxx driver returns DID_BUS_BUSY in case of > any 'transport' related problems during the exchange (dropped > frames, FCP protocal failures, etc.). > > When the qla2xxx driver managed command queuing internally, a NOT_READY > status would cause the lun-queue to be frozen for some period time while > the storage settled-down. >
Returning back DID_IMM_RETRY for these 'transport' related conditions would of course help in this issue -- but at the same time bring with it several side-effects which may not be desirable. So, beyond this particular circumstance, what would be considered a 'proper' return status for this type of event? > Would this be an approach to consider? Or should we tackle the problem > by addressing the quirky (cmd->retries > cmd->allowed) state? > -- Andrew - 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
