SAS-2: HARD RESET stalls at PL_PM

George Penokie gop at us.ibm.com
Fri Mar 2 09:34:59 PST 2007


Formatted message: <A HREF="r0703024_f.htm">HTML-formatted message</A>

Bob,
Sounds to me like a proposal is coming ;-) 
I don't see any problem removing the hard_reset wording from the PL_PM 
state machine. But I see no harm in leaving it there either. If it is 
removed then it should be completely removed because if PL_PM is in the 
idle state then there are no operations to terminate.
Of course all this assumes you are correct in your assumption that a Phy 
Disabled confirmation always comes before a Hard_Reset. I admit I did not 
dig down to that level.
Bye for now,
George Penokie
Dept 9A8 030-3 A410
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208
"Sheffield, Robert L" <robert.l.sheffield at intel.com> 
Sent by: owner-t10 at t10.org
03/02/2007 10:05 AM
To
George Penokie/Rochester/IBM at IBMUS
cc
<owner-t10 at t10.org>, "T10 Reflector" <t10 at t10.org>
Subject
RE: SAS-2: HARD RESET stalls at PL_PM
George,
Your's is the first response I've received.
The problem is that the text specifying "operations are terminated" is 
described in transitions from PL_PM2 or PL_PM3 to PL_PM1:IDLE, and are 
associated with a condition that will never occur in those states (i.e., 
HARD RESET Received confirmation). That's because of the constraint that a 
HARD RESET primitive cannot be recognized until after DWS is lost COMINITs 
and COMSAS have been exchanged, and speed negotiation has completed - long 
after the PL_PM state machine made it's transition to PL_PM1. So, at a 
minimum, we have state transition trigger conditions defined that are 
meaningless since the PL_PM will never be in the PL_PM2 or PL_PM3 state 
when the HARD RESET primitive is recognized. Because the text about "all 
operations are terminated" is associated with state transition conditions 
that will never occur, I'm concerned that if the state machine is 
implemented scritly according to the text, the operations will not be 
terminated when they need to.
Wouldn't it make more sense to remove the transition conditions related to 
the HARD RESET Received confirmation defined for the PL_PM2 and PL_PM3 
states, and instead put a statement in the PL_PM1:IDLE state general 
description along the lines of:
    If a HARD RESET Received confirmation is received in this state, all 
operations are terminated.
?
Bob
From: George Penokie [mailto:gop at us.ibm.com] 
Sent: Friday, March 02, 2007 8:21 AM
To: Sheffield, Robert L
Cc: owner-t10 at t10.org; T10 Reflector
Subject: Re: SAS-2: HARD RESET stalls at PL_PM
Bob, 
Don't know if anyone responded to this. But here's my 2 cents. 
I don't see any problem. The hard_reset goes to the PL_OC and those states 
forward it up to the transport layer. The information in the PL_PM is only 
there to get PL_PM back to idle. Remember, that the port layer is not just 
the PL_PM but also includes the PL_OC. So there is no stalling of the 
hard_reset at PL. 
If I'm missing your point let me know. 
Bye for now,
George Penokie
Dept 9A8 030-3 A410
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208 
"Sheffield, Robert L" <robert.l.sheffield at intel.com> 
Sent by: owner-t10 at t10.org 
02/08/2007 02:09 PM 
To
"T10 Reflector" <t10 at t10.org> 
cc
Subject
SAS-2: HARD RESET stalls at PL_PM
One of our designers noticed an interesting conundrum in looking at the 
details of the PL_PM state machine and how a HARD RESET arriving on the 
wire is processed. It appears the intent is to "terminate all operations", 
however when walking through the specific state sequences, this doesn't 
appear to happen in most cases (except when there's an outstanding OPEN 
address frame). 
There are two other places where the PL_PM processing of a HARD_RESET 
Received confirmation is specified: 
8.2.3.3.6 Transition PL_PM2:Req_Wait to PL_PM1:Idle 
This transition shall occur after: 
a) a Retry Open message is sent to the PL_OC state machine; 
b) an Unable To Connect message is sent to the PL_OC state machine; 
c) all operations have been terminated after a HARD_RESET Received 
confirmation is received; or 
d) a Phy Disabled confirmation is received. 
8.2.3.4.2 Transition PL_PM3:Connected to PL_PM1:Idle 
This transition shall occur after: 
a) a Connection Closed (Transition to Idle) message is sent to the PL_OC 
state machine; or 
b) all operations are terminated after a HARD_RESET Received confirmation 
is received. 
The trouble is, the PL_PM will never be in the PL_PM2 or PL_PM3 state when 
the HARD_RESET Received confirmation is received. The PL_PM2 state machine 
will take the transition to PL_PM1 based on condition (d) first, and the 
PL_PM3 state will take the transition to PL_PM1 based on condition (a) 
first. 
The SP state machine takes a transition to SP0:OOB_COMINIT upon receiving 
COMINIT/DWS Lost. 
The SP0:OOB_COMINIT state sends a Phy Layer Not Ready confirmation to the 
link layer. 
Receiving a Phy Layer Not Ready confirmation causes the SL_IR_IRC state 
machine to transition to the SL_IR_IRC1:Idle state.
The SL_IR_IRC1:Idle state sends a Phy Disabled confirmation to the port 
layer, and an Enable Disable SAS Link (Disable) message to the SL state 
machines. 
Receiving a Phy Disabled confirmation (condition d) causes the transition 
PL_PM2->PL_PM1. 
Receiving an Enable Disable SAS Link (Disable) message causes the SL_CC 
state machine to transition to SL_CC0:Idle. 
The SL_CC0:Idle state sends a Connection Closed (Transition to Idle) 
confirmation to the port layer 
Receiving a   Connection Closed (Transition to Idle) confirmation 
(condition a) causes the transition PL_PM3->PL_PM1. 
All of this happens before the HARD RESET part of the link reset sequence 
can occur, and so the PL_PM state machine is in PL_PM1:Idle when the HARD 
RESET Received confirmation is processed. PL_PM1:Idle specifies no 
processing based on the HARD_RESET Received confirmation. 
Perhaps I'm missing something - is there something that prevents the SP 
state machine from transmitting Phy Layer Not Ready at the beginning of a 
link reset sequence? 
Respectfully, 
Bob Sheffield 
Intel Corporation 



More information about the T10 mailing list