Mike Christie wrote:
> Mike Christie wrote:
>>> As you mentioned that there were issues like this prior to shared
>>> tag map fix in libfc, therefore not sure on reverting shared tag map
>>> fix from libfc with added over head of maintaining link list of
>> I think we agree we need a way to loop over running commands for error
>> handling operations. Are you saying you want to keep the shared tag map
>> way of looking up commands? My issue with the shared tag map is if we
>> absolutely needed to go from some unique tag to some struct then a look
>> up table is great.
>>
>> However, if there is any way we can not have to use that code I would
>> prefer it. Using it to just loop over the running commands is really
>> ugly and more difficult than it needs to be. We have to handle the cases
>> where the tag is mapped to a fc_fcp_pkt (normal case), the tag is
>> allocated but not yet mapped to a fc_fcp_pkt (in this case the scsi mid
>> layer is either cleaning up the command because we called scsi_done on
>> it, or scsi-ml has allocated a tag and associated it with a scsi_cmnd,
>> but has not yet called fc_queuecommand). We also have to worry about the
>> cases where the tag is reused and the scsi-ml eh is running, but I think
>> that should be handled by the first two cases (at least that is how I
>> worked it out) - I do not like having to worry about it though.
>>
>
> Oh yeah, we actually had this discussion for iscsi a while back. We need
> to be able to loop over the running commands to cleanup lun and target
> resets, and for when a session goes bad and we need to return the
> commands back to scsi-ml.
>
> For the scsi eh paths, scsi_error.c actually has a list of commands that
> need cleaning up, so we could modify scsi_error to pass us a list of
> commands to work on.
>
> For transport class paths though, I am not sure what to do. For example
> for fc when the rport is deleted and eventualy when the fast io fail or
> dev loss tmo fire we will want to cleanup commands in the terminate
> rport io callouts (that is if we decide not to just cleanup them up when
> the rport is deleted like how qla2xxx does it (ignoreing tape
> commands)). Unfornately the classes do not maintain a list for us like
> scsi_error.c. If we could figure something out though we could fix this
> issue in a lot of drivers. Do you guys have any tricks?
> _______________________________________________
> devel mailing list
> [email protected]
> http://www.open-fcoe.org/mailman/listinfo/devel
The exchange manager reset function should help here. It should call
the response handler for any open exchanges. It isn't currently
being used when a remote port goes away, but that is easy to change.
I sent Mike a similar message.
Joe
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel
