ADTr9a removed checksum error from NAK codes

Banther, Michael michael.banther at hp.com
Thu Jan 29 02:05:43 PST 2004


* From the T10 Reflector (t10 at t10.org), posted by:
* "Banther, Michael" <michael.banther at hp.com>
*
1.  I agree with Paul's recollection of the removal of the NAK status
code for bad checksum.

2.  The solution to Kevin's second question lies in the different
asymmetric logical unit access states.  Take a look at SPC-3r16
sub-clause 5.8.4 and especially 5.8.4.5.  A Logical Unit in Unavailable
state for a given port (say the primary port in the case of the ADC LU)
gets to choose what Task Management functions from that port it honors.

Regards,
Michael Banther
Hewlett-Packard Company
Telephone +44 (117) 312 9503


-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Paul.A.Suhler at certance.com
Sent: Wednesday, January 28, 2004 9:11 PM
To: t10 at t10.org
Subject: Re: ADTr9a removed checksum error from NAK codes


* From the T10 Reflector (t10 at t10.org), posted by:
* Paul.A.Suhler at certance.com
*

Hi, Kevin.

1.  Removing the NAK status for a bad checksum was intentional.  If the
checksum is not valid then none of the fields in the frame can be
trusted, including Frame Number, so the receiving port wouldn't know
what to put in that field of the NAK.  TimeoutAck will eventually kick
in and initiate recovery.

Fibre Channel has an analogous situation with bad CRC, in which the port
seeing the bad CRC doesn't even know whether the D_ID is right; as a
result it discards the FC frame.

2.  My initial thought is that this is an argument for not presenting
the ADC device server on a primary port.

Cheers,

Paul Suhler
Certance



 

                      <kdbutt at cox.net>

                      Sent by:                 To:       t10 at t10.org

                      owner-t10 at t10.org        cc:
kdbutt at us.ibm.com

                                               Subject:  ADTr9a removed
checksum error from NAK codes                                  
 

                      01/27/2004 07:28

                      PM

 

 





* From the T10 Reflector (t10 at t10.org), posted by:
* <kdbutt at cox.net>
*
In reading ADTr9a I noticed a couple of items that I wish to resolve:

1) The NAK code for corrupted checksum no longer exists in the status
code table.  I think this unintentionally happened during the
reordering.

2) One of the consequences of the ADT port being an additional SCSI port
is that if automation is talking to a drive a host on the primary port
can issue a task management function such as LUN Reset and blow away an
automation command that is in progress and the automation will receive
no SCSI Response IU.  This has raised concerns among those that are used
to the automation never being affected by primary port activity.  My
intent of this discourse is to make sure that this "side effect" is
understood and is indeed the desired effect.  If it is not, then we have
a lot of work to respond to this.

===  Please respond to either the reflector or kdbutt at us.ibm.com ====

Thanks,

Kevin

*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org





*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org 

*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




More information about the T10 mailing list