On Thu, 2007-11-15 at 15:35 -0700, Moore, Eric wrote: > > No. When the command goes via SG_IO it bypasses all return status > > processing (and QUEUE_FULL/BUSY is a return status). When it's > > submitted in the normal way (i.e. via a ULD) then the mid-layer > > processes these returns to a retry strategy. > > > > James - Today I'm working some other customer issue, and my target > returns SAM_STAT_TASK_SET_FULL when sg_inq is sent. I see about 10 > retries before the data is finally returned. Who is issuing the retries > to my driver? Doesn't sg_inq (sg3_utils), use SG_IO -> > scsi_execute_async-> scsi_softirq_done, where SAM_STAT_TASK_SET_FULL is > translated to ADD_TO_MLQUEUE, then retried, regardless the fact that > SG_DEFAULT_RETRIES equal zero. Maybe I'm missing something, but I'm > seeing retries. No, you're not ... I'm not thinking straight about the disposition path. There's another thing at work, which is the command default timeout, when that exhausts we do return the status back to SG_IO; otherwise we will follow the retry strategy in all cases. Jmaes - 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
