dallas at dallas at
Thu May 4 13:32:06 PDT 1995

I have been following this thread with great interest and 

Currently the log pages are optional and the logging
of any type of condition is poorly defined or not define
at all.  It seems to me that this type of error delivery
mechanism is poor.

The service responses and delivery mechanisms to the periheral 
drivers must be consistent in their behavior.  The 
peripheral drivers should have no knowledge of the transport
mechanisms (FCP, SBP, SIP etc) to the logical unit and should 
only know about SAM behavior and the behavior model that the
device presents (SBC, SCC, etc).  

The introduction of transport specific behavior is in my
opinion is a large mistake and will result in a fragmentation 
of support for such protocols (e.g, this disk driver knows
about SSA and SIP behavior but not FCP or SBA).

Currently CAM defines that the SIM/HBAs know about the transport
mechanisms and have no device knowledge and the periheral drivers
have the knowledge about the devices.  This is a clear and
distinct division of knowledge but this thread of dicussion 
breaks down those divisions.

The original models of the new transport protocols were advertised
as presenting the same behavior models as SIP (how they accomplished
this was left to the protocol).  In the last year I have seen more
and more crud creeping in from these protocols that present 
different behavior back up to the drivers.

I beleive that all the new transport protocols should re-examine
their behavior models and correct any deviation from the SIP behavior
models.  I do realize that there are certain cases a one to one
mapping is impossible (e.g., unexpected bus free etc.) but
unconfirmed service responses is not one them, it has been
chosen not to be done.

You may flame if you like.

Bill Dallas

------- Forwarded Message

Return-Path: at
Received:  from by; (5.65v3
	  	id AA26245; Thu, 4 May 1995 15:06:59 -0400
Date:  Thu, 4 May 1995 15:06:59 -0400
Message-Id:  <9505041906.AA26245 at>
From: at (Kurt Chan)
Cc:  scsi at, fibre-channel-ext at

| 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.


You're right about deferred errors - there are other methods to
determine if a deferred errors are reported, such as logs.  Would a
new proposal be needed to describe how to report deferred errors using
log pages?

| I do not think this is correct. ACA remains in effect until it is
| explicitly cleared by the initiator with a CLEAR ACA TM function.

Right again - the autosense only clears the ACA if NACA=0 in the CDB
of the faulting command.  After several months of reading SAM, I'm
still trying to understand ACA (am I just thick, or is this difficult

Then the only question I have with respect to SAM compliance is:

  "Sense data shall be preserved by the logical unit until it is
   transferred by one of the methods listed below or until another
   task from that initiator is entered into the task set.  The
   information may be obtained by the intiator through:

   a) The REQUEST SENSE command
   b) An asynchronous event report
   c) Autosense delivery"

I'd like to get a clearer definition of what SAM means (from the
Target's perspecive) by the term "transferred".  Does this imply
"successful transfer", or does merely refer to the act of physically
transmittingt the autosense?  

If it means successful transfer, then we may have to reevaluate
whether or not SPI conforms, and whether or not FCP without confirmed
responses conforms.  If it means just the physical transfer, then
both FCP and SPI conform to this clause.

Any SAM experts care to comment?

      Kurt Chan                          kc at
      Hewlett-Packard                    Voice: 916-785-5621
      System Interconnect Lab            Fax:   916-785-2875

% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ======
% Received: from by (5.65/rmc-22feb94) id 
AA18311; Thu, 4 May 95 15:05:24 -040
% Received: from by; (5.65 EXP 4/12/95 for 
V3.2/1.0/WV) id AA16059; Thu, 4 May 1995 12:02:21 -070
% Received: (from root at localhost) by ( id 
MAA24074; Thu, 4 May 1995 12:59:00 -0600
% Received: from by via 
smap (V1.3) id sma023710; Thu May  4 12:50:00 199
% Received: from ncrwic.WichitaKS.NCR.COM ( 
[]) by Symbios.COM ( with SMTP id MAA18683; Thu, 4 May 
1995 12:49:26 -0600
% Received: by ncrwic.WichitaKS.NCR.COM; 4 May 95 13:46:23 CDT
% Received: from ([]) by Symbios.COM 
( with ESMTP id MAA18571 for <scsi at>; Thu, 4 May 1995 
12:44:29 -0600
% Received: (from root at localhost) by ( id 
MAA23510 for <scsi at>; Thu, 4 May 1995 12:45:00 -0600
% Received: from by via smap (V1.3) 
id sma023500; Thu May  4 12:44:46 199
% Received: from by with SMTP 
( 3.3) id AA271483081; Thu, 4 May 1995 11:44:41 -070
% Received: from by with SMTP (16.6/15.5+IOS 
3.21) id AA05661; Thu, 4 May 95 11:44:39 -070
% Received: by (16.6/15.5+IOS 3.21) id AA02301; Thu, 4 May 95 
11:44:38 -070
% From: Kurt Chan <kc at>
% Message-Id: <9505041844.AA02301 at>
% Date: Thu, 4 May 95 11:44:38 PDT
% Cc: scsi at, fibre-channel-ext at
% In-Reply-To: <199505041349.HAA12634 at>; from 
"GFRAZIER at AUSVM6.VNET.IBM.COM" at May 4, 95 8:47 am
% Mailer: Elm [revision:]

------- End of Forwarded Message

More information about the T10 mailing list