Moore, Eric wrote:
On Friday, February 29, 2008 5:25 PM, Mike Christie wrote:
This patchset fixes the problem where scsi-ml will call the
device reset
handler for each logical unit, but some drivers are sending a target
reset. Because we do not need to send a target reset multiple times,
this patchset creates a new target reset callout which of course is
called once per target instead of once per lu. It also cleans up
the all the commands sent to the target when SUCCESS is returned.
qla4xxx, qla2xxx and lpfc were test with a hacked up sg_reset. I also
sent lots of commands to the target and decreased the cmd timeout to
1 second so the scsi would run (turned off the eh abort callout too).
The arm scsi, mpt fusion, sym53c8xx_2, and a100u2w, and qla1280
drivers were only compile tested, but looked like the only needed
a rename of the scsi eh handler.
The zfcp driver is also only compile tested. It was doing a lun
reset and possibly target reset, so I split that up to use
the device and target reset handlers. scsi-ml will escalate from
the device to the target reset for the driver.
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.
How about I add the LU reset support in a separate patch, so git revert
will be kinder to me?
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.
--
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
