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
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@us.ibm.com
Internal:
553-5208
External: 507-253-5208
"Sheffield, Robert L"
<robert.l.sheffield@intel.com>
Sent by: owner-t10@t10.org
02/08/2007 02:09 PM
|
|
To
| "T10 Reflector"
<t10@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