ADDITIONAL FCP_RESP IUs

TBattle at corp.adaptec.com TBattle at corp.adaptec.com
Thu May 4 10:30:00 PDT 1995


Header: Adaptec
Giles Frazier wrote:

>I assume "Exception handling Selection Mode Page" (X3T10/94-190)  is the 
>same as what is in SPC rev 6 under the title of "Informational exceptions 
>control page".  The problem I have with this approach is the way I read SPC,
 
>the only error I can indicate is an ASC of FAILURE PREDICTION THERSHOLD 
>EXCEEDED. (section 8.3.3, first paragraph.)  The assumption is the host can 
>determine what went wrong after the fact.  I am not sure that assumption is 
>always true.

If you'd like to explore this further, Mike Fitzpatrick of Seagate 
(Mike_Fitzpatrick at notes.seagate.com) plans to propose several ASCQs for 
X3T10/94-190.  His intent is to extend coverage to such items as DETECTED 
TEMPERATURE THRESHOLD EXCEEDED.  I believe he'd be open to exploring other 
suggestions.

The original plan was that he'd propose the extensions at the next Working 
Group meeting.  Given the short timeframe between now and the meeting, 
however, that seems unlikely to happen.

Tom Battle
Adaptec, Inc.
TBattle at corp.adaptec.com
-------------
Original Text
>From cbinford at ppdpost.ks.symbios.com ("Binford, Charles"), on 5/4/95 1:46 
PM:
To: fibre-channel-ext at think.com (fibre-channel-ext), scsi at symbios.com (scsi)


 ----------
>From: GFRAZIER
>To: scsi; fibre-channel-ext
>Subject: ADDITIONAL FCP_RESP IUs
>Date: Wednesday, May 03, 1995 1:48PM
>--------------------------------------------------------------------------- 
 
 ---
>Charles Binford wrote the following note about a problem caused when the
>FCP_RESP IU is lost. My comments on his proposal follow his note.
>

original note from me (Charles Binford) deleted....

>
>These new FCP_RESP IUs elimate only part of a data integrity exposure. To
>completely eliminate the exposure, both of the following must be ensured.
>
>1) Ensure that the initiator is informed about the asynchronous event.
>   (Charles's proposal eliminates this exposure adequately.)
>2) Ensure that the problem caused by the asynchronous event is not
>   compounded by additional commands received from the initiator before it
>   knows about the event.
>   (Charles's proposal does not prevent this from occuring.)
>
>
>Rather than invent yet another mechanism to eliminate exposure (2)
>it is better to use existing SCSI-3 mechanisms to eliminate both (1) and
>(2) in the first place.
>
>For exposure 1), the "Exception handling Selection Mode Page"
>(X3T10/94-190) can be used. This page allows the initiator to instruct the
>target to periodically report asynchronous events. Therefore, if an
>FCP_RESP frame is lost, others will be sent until the condition causing the
>event is resolved. This ensures that the initiator eventually is informed
>of the asynchronous event.
>

I assume "Exception handling Selection Mode Page" (X3T10/94-190)  is the 
same as what is in SPC rev 6 under the title of "Informational exceptions 
control page".  The problem I have with this approach is the way I read SPC, 
the only error I can indicate is an ASC of FAILURE PREDICTION THERSHOLD 
EXCEEDED. (section 8.3.3, first paragraph.)  The assumption is the host can 
determine what went wrong after the fact.  I am not sure that assumption is 
always true.


>For exposure 2) ACA can be used. SPC, section 7.19.1, Deferred Errors,
>specifies that an asynchrounous event can be reported by reporting a
>CHECK CONDITION and setting the appropriate sense bytes. The CHECK
>CONDITION establishes an ACA and prevents additional commands from
>causing additional damage.
>
I see no conflict between my proposal and the use of the NACA bit.  You are 
correct, exposure 2 needs ACA.  By the way. I agree with you that Kurt 
Chan's interpretation of SAM concerning this is incorrect.  (See Kurt's 
response to Giles, same discussion, different email.)

>Since existing SCSI-3 mechanisms address the problem, it is best
>to use them instead of the new FCP_RSP IUs. Microcode development, testing
>time, and the SCSI Specifications will all be simplified.
>
I agree with keeping microcode development simple.  I am not convinced your 
approach covers the issue.

While I'm here, let me respond to your comments which were in response to 
Kurt's email I referenced earlier.  (I cut and pasted your text from the 
other email.)

(Give yourself a pat of the back if you have kept up with who said 
what.....)
>>>>Giles wrote in response to Kurt in response to Giles in response to me 
:-)
>Charles's proposal stated that the problem he was solving was the loss of
>status NOT ASSOCIATED WITH THE COMMAND. This status could be either an
>asynchronous event or a deferred error such as a loss of cached write
>data. My previous note described a standardized method of ensuring delivery
>of asynchronous events. For ensuring delivery of deferred errors, it would
>be just as good for the target to use the following procedure:
>
>1) Send the FCP_RESP frame with the deferred error.
>2) Log the defferred error (in this case, the loss of the cached data).
>
>If the FCP_RESP was lost, the initiator would discover it after a ULP
>timeout and it could then read the log to discover that the cached data was
>lost. Again, this procedure uses existing SCSI-3 procedures--no
>reinvention.

Sounds good, but I haven't seen a standardized method of retrieving log 
information.  Data which is in a vendor specific format.  Maybe we should 
redirect our efforts to create a standard log page which keeps the last n 
sense buffers!

Charles.Binford at Symbios.com

>
>Giles Frazier
>IBM Austin
>gfrazier at ausvm6.vnet.ibm.com
>
>




More information about the T10 mailing list