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
h...@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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
