Windows (StorPort drivers) supports LUN, target, and bus resets in a hierarchical fashion. If an I/O times out, Storport will issue a LUN reset first. If that fails, it will escalate to a target reset. If that fails, it will escalate to a bus reset. What does "fail" mean? If the TM request returns with a non-success status, or if there are outstanding I/O's for the scope of the reset remaining after we receive the TM reply, then the reset is considered failed. Our miniport driver will return error status back to Storport and it will escalate to the next level of reset. A bus reset cannot be failed back to Storport. If a bus reset fails (as above) then the only recourse if for the miniport to do a hard reset of the adapter and return all outstanding I/O's with reset status. Steve H. -----Original Message----- From: Moore, Eric Sent: Tuesday, March 04, 2008 11:35 AM To: Mike Christie Cc: linux-scsi@xxxxxxxxxxxxxxx; james.smart@xxxxxxxxxx; andrew.vasquez@xxxxxxxxxx; christof.schmitt@xxxxxxxxxx; mp3@xxxxxxxxxx; rmk@xxxxxxxxxxxxxxxx; matthew@xxxxxx; Hagan, Steve; Rivera, Peter; Prakash, Sathya Subject: RE: scsi: fix target reset handling On Tuesday, March 04, 2008 8:21 AM, Mike Christie wrote: > > The fusion firmware supports Logical Unit Reset, so why not fix > > mptscsih_dev_reset so its passing > > MPI_SCSITASKMGMT_TASKTYPE_LOGICAL_UNIT_RESET, and lun number to > > mptscsih_TMHandler, and create the new function > mptscsih_target_reset as > > you've done? > > > > I did not do this because I was not trying to add new functionality. I > was just trying to fix what was there. No problem, lets go for what you've done already, thanks, > > How about I add the LU reset support in a separate patch, so git > revert will be kinder to me? > Seperate patch, no problem. > There was also some side discussion about side affects of doing a lu > reset and if we need to be doing something more than what we do today > from the device reset handler, so I did not want to dig into that in > this patchset. I am just trying to get target reset done in the proper > place on this pass. In later patches I want to tackle TMFs like lu > reset, abort task set, etc. > I'm pretty sure that windows supports LU Reset callback handlers, instead of target reset. I'm not sure if there are any side effects, for instance non supported devices. I've copied Steve Hagan, perhaps he might have some feedback on that. Is there any chance for TM callback support in the transport, for instance in SAS, we have phy, link and hard reset. I believe the current support is manually invoked via sysfs. 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
