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