Re: [PATCH][RFC] scsi_transport_fc: Implement I_T nexus reset

[Hannes Reinecke <hare@suse.de>]

Am 12/07/2012 08:58 PM, schrieb Chad Dupuis:
>
>
> On Fri, 7 Dec 2012, Mike Christie wrote:
>
>> On 12/07/2012 08:51 AM, Hannes Reinecke wrote:
>>> 'Bus reset' is not really applicable to FibreChannel, as
>>> the concept of a bus doesn't apply. Hence all FC LLDD
>>> simulate a 'bus reset' by sending a target reset to each
>>> attached remote port, causing error handling to spill
>>> over to unaffected devices.
>>>
>>> This patch implements a 'I_T nexus reset' handler,
>>> which attempts to reset the I_T nexus to the remote
>>> port. This way only the affected remote ports are
>>> reset; other ports are left untouched.
>>
>> Is the I_T nexus reset we are doing in this patch supposed to be the
>> same one defined in SAM? Was the I_T nexus reset TMF added to SAM at the
>> same time the target reset one was removed? In SAM 4 and 5 there is no
>> target reset anymore is there?
>>
>> I think we should just kill the bus reset use from the FC drivers. Add a
>> new I_T nexus reset callout to the scsi_host_template or to the
>> scsi_transport_template. Then have scsi-ml call just either target reset
>> eh callout or I_T nexus eh reset callout depending on what the target
>> supports.
>>
>> To figure out what the target supports could we do a REPORTED SUPPORTED
>> TASK MANAGEMENT FUNCTION command. If the target supports that command
>> and reports that the target supports the I_T nexus reset TMF then call
>> that eh callback, else drop down to older target reset eh callback.
>>
>> It seems that if we do I_T nexus reset we do not need to also do a
>> target reset do we?
>>
>
> It would be good to have a specific I_T nexus reset callout in either the
> host or transport so we can clean things up.
>
> Currently in the bus reset handler after we perform all the
> target resets we wait for all the associated DMA activity to clear up
> before we return from the bus_reset handler.  It would be good to have
> the same capability in a new I_T nexus reset handler as well.
>
Hmm. Thanks for bringing this up, as this is exactly one of the issues
I wanted to get feedback from the hardware guys.

When doing an I_T Nexus reset I'd need:
- Set the port type to BLOCKED
- Abort all outstanding I/O
- invoke dev_loss_tmo to reset the port
- Return status 'GOOD' if we could abort all I/O or FAILED if not

I'm not sure about the third item; I _think_ we might be okay by just 
setting the port state to 'BLOCKED' and invoke the dev_loss_tmo
mechanism here. That should be resetting the port eventually.

However, the tricky bit is the second item.
fc_terminate_rport_io() is more often than not invoked asynchronously,
so the only thing I can be sure of is that we have _started_ to
abort all I/O, not neccessarily that all I/O is actually aborted.

So hooking up eh_target_reset there instead of fc_terminate_rport_io()
would not only clear up any outstanding I/O but also give me a nice
status back.

Hmm. That actually makes sense.
I think I'll be drafting out a new version of the patch.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html