Possible typo in SPL (this came from SASr16 as well)

Gerry.Houlder at seagate.com Gerry.Houlder at seagate.com
Wed Jul 22 07:02:34 PDT 2009


Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r0907220_f.htm">HTML-formatted message</a>
Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r0907220_graycol.gif">graycol.gif</a>
Attachment #2: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r0907220_pic28856.gif">pic28856.gif</a>
Attachment #3: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r0907220_ecblank.gif">ecblank.gif</a>

The existing wording is correct. The intent is that the START STOP UNIT
command with IMMED=0 will not post Good status until it has reached the
ready condition of the Active state. This is a crude attempt to describe
the existing working of this command within the backdrop of the power
condition model. This wording makes START STOP UNIT coming from STOPPED
power condition an exception to the usual Active_Wait rule of quickly
posting a CHECK CONDITION status with WAITING FOR NOTIFY sense bytes.
A more technically correct method to do this would be to pass a variable to
the Active_Wait state that says to bypass the WAITING FOR NOTIFY action. If
Kevin Marks further develops his idea for a state machine that adds a
Becoming_Ready state, then the variable will have to pass through
Active_Wait, Becoming_Ready, and arrive at Active before ending status gets
posted. Note that other commands received after the Stopped state is exited
(including an overlapping START STOP UNIT) will get different treatment in
that they will quickly post CHECK CONDITION status and WAITING FOR NOTIFY
sense bytes until after a NOTIFY primitive is received.
	     Bill.Martin at emule					       
	     x.com						       
	     Sent by:							To
	     owner-t10 at t10.org	       <t10 at t10.org>		       
	     No Phone Info						cc
	     Available		       <Narayan.Ayalasomayajula at emulex.com
				       >			       
								   Subject
	     07/21/2009 03:24	       Possible typo in SPL (this came 
	     PM 		       from SASr16 as well)	       
In 9.2.10.6 the following text exists:
9.2.10.2.6.3 Transition SA_PC_4:Stopped to SA_PC_5:Active_Wait
This transition shall occur if:
a) a START STOP UNIT command with the POWER CONDITION field set to 0h
(i.e., START_VALID) and the START bit set to one is processed; or
b) a START STOP UNIT command with the POWER CONDITION field set to ACTIVE
is processed.
If the transition is based on a START STOP UNIT command with the IMMED bit
set to zero, then the device server shall not complete the command until
this state machine reaches the SA_PC_1:Active state.
The last sentence is based on the transition to SA_PC_1:Active state;
however the transition is actually to the SA_PC_5:Active_Wait state. I
believe that the last sentence should read:
If the transition is based on a START STOP UNIT command with the IMMED bit
set to zero, then the device server shall not complete the command until
this state machine reaches the SA_PC_5:Active_Wait state.
Bill Martin
Emulex
Office of Technology
Industry Standards
916 772-3658
916 765-6875 (Cell)



More information about the T10 mailing list