Re: FCP target reset

[Douglas Gilbert <dgilbert@interlog.com>]

It looks like "target reset" is being phased out of SCSI
terminology and being partially replaced by "hard reset".

The third paragraph in the introduction of draft SAM-5
(sam5r02.pdf section 1.1) states:

"The following concepts from previous versions of this
  standard are made obsolete by this standard:
    a)    support for the SPI-5 SCSI transport protocol;
    b)    Contingent Allegiance;
    c)    the TARGET RESET task management function;
    d)    basic task management model;
    e)    untagged tasks; and
    f)    linked command function."

The TARGET RESET task management function last appeared
in SAM-2 (ANSI INCITS 366-2003).

A "hard reset" is associated with a power cycle at an
initiator, target or somewhere in between. There is no
SCSI task management function to generate a hard reset.

Some transports have the ability to generate hard resets
via non-SCSI protocols. For example in SAS a target can
be reset with a SMP PHY CONTROL request to an expander
phy attached to a phy on that target. SAS also has a lower
order "link reset" which is invisible at the SCSI protocol
level.

So is there a "hard reset" hook somewhere in FCP-3 ?

Doug Gilbert


James Smart wrote:
> Just because a newer rev of the spec doesn't do something does not mean 
> that all the targets/environments stopped using it...  Target Reset was 
> a mandatory item for FCP-2 compliance, which is what most of the stuff 
> in the field is at.   So, I recommend that the header be updated with 
> the older definition - It can be flagged any way you desire (/* 
> Deprecated as of FCP-3 */).
> 
> As for use in LLD's - there's nothing else (TMF-wise) that works at the 
> I_T nexus level to map to the shost eh_target_reset_handler.  Thus, I'd 
> continue to use it for the entrypoint. You can always choose to not 
> implement the entry point, but my recommendation is to support it if 
> possible. It's much better than having to resort to a "bus" or "adapter" 
> reset after a lun reset fails.
> 
> -- james s
> 
> Christof Schmitt wrote:
>> While trying to replace the Fibre Channel protocol definitions in
>> zfcp with the definitions in include/scsi/fc i came across the FCP
>> target reset flag.
>>
>>> From what i understand, older versions of the FCP standard defined the
>> target reset flag, but newer versions do not. Adhering to the newer
>> standard, the file include/scsi/fc/fc_fcp.h does not define the target
>> reset.
>>
>> Does this mean that FC device drivers should not issue target resets
>> any more?
>>
>> Some FC device drivers in Linux define the flag:
>>
>> grep -r FCP_TARGET_RESET *
>> drivers/s390/scsi/zfcp_dbf.h:    zfcp_scsi_dbf_event(flag == 
>> FCP_TARGET_RESET ? "trst" : "lrst", tag, 1,
>> drivers/s390/scsi/zfcp_def.h:#define FCP_TARGET_RESET    0x20
>> drivers/s390/scsi/zfcp_scsi.c:    return 
>> zfcp_task_mgmt_function(scpnt, FCP_TARGET_RESET);
>> drivers/scsi/lpfc/lpfc_scsi.c: FCP_TARGET_RESET);
>> drivers/scsi/lpfc/lpfc_scsi.c: FCP_TARGET_RESET);
>> drivers/scsi/lpfc/lpfc_scsi.h:#define  FCP_TARGET_RESET    0x20    /* 
>> bit 5 */
>>
>> If the target reset is not required, i would remove it from zfcp. If
>> it is still required, would adding it to include/scsi/fc/fc_fcp.h make
>> sense, probably flagged as "obsolete"?
>>
>> -- 
>> Christof Schmitt
>> -- 
>> 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
>>
> -- 
> 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
>