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.
Also, are there certain port types we wouldn't want to send this reset to
such as tape?
@@ -3266,8 +3271,8 @@ fc_timeout_fail_rport_io(struct work_struct *work)
if (rport->port_state != FC_PORTSTATE_BLOCKED)
return;
- rport->flags |= FC_RPORT_FAST_FAIL_TIMEDOUT;
fc_terminate_rport_io(rport);
+ rport->flags |= FC_RPORT_FAST_FAIL_TIMEDOUT;
}
What was the reason for moving this? For the eh case in this patch was
it causing IO to be failed with DID_TRANSPORT_FAILFAST when we wanted it
failed with some other error.
________________________________
This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
--
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
