SPI-3 technical change (part 3)

[Gerry_Houlder at notes.seagate.com]

* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry_Houlder at notes.seagate.com
*
The MESSAGE REJECT response is OK, but I disagree about requiring the target to
initiate a PPR message immediately thereafter. There are a lot of initiators out
there that would choke on a target initiated PPR message. Currently they prevent
this situation by configuring a vendor unique mode page bit to prohibit the
target from initiating a speed/ width negotiation.

Secondly, domain validation adds more complication to the scenario. If a device
initiates PPR message, is it also required to perform some domain validation
steps? Some systems experts think so. Target devices aren't adding this
complication to their firmware, however.

Feedback I am getting from systems companies suggest that domain validation
requirements are forcing the initiator camp even farther into the position of
NEVER wanting targets to initiate speed negotiation. Domain validation requires
the "validating device" to gather some info (e.g., INQUIRY data) from the target
in "slow, reliable" transfer rate before starting the negotiation to faster
rates. If a target initiates negotiation, the HBA accepts the negotiation but
higher level system software can't read the "current negotiated rate" info from
the HBA. This confusion can result in erroneous acceptance of error-prone
transfer rates. For now they are avoiding the problem by disallowing the target
to initiate transfer rate negotiation. This is merely a continuation of what
most system vendors were already doing.

Given the above situation with most initiators, requiring the target to initiate
negotiation to recover from a protocol violation is not desireable. I'm sorry I
didn't read that paragraph this carefully before the review comment period
ended.





gop at us.ibm.com on 11/25/99 10:43:18 PM

To:   t10 at t10.org
cc:    (bcc: Gerry Houlder)

Subject:  SPI-3 technical change (part 3)



* From the T10 Reflector (t10 at t10.org), posted by:
* gop at us.ibm.com
*
While reviewing Brea Technologies letter ballot comments with Bill Galloway
some issues came up that we agreed needed a wider audience before placing
the changes into SPI-3. With the change indicated below an initiator could
issue a task management function to the target during an initiator
connection while running in packetized mode. This is not allowed under the
current rules. The paragraph in section 10.3.1.1.2 that controls this
behavior is below. The change is marked by << >>.
I plan on putting this change into SPI-3 unless the is objection.

"If information unit transfers are enabled for the connecting initiator the
target shall proceed to a MESSAGE OUT phase. On detecting the MESSAGE OUT
phase the initiator shall begin a PPR negotiation (see ). On completion of
the PPR negotiation the target shall proceed to a BUS FREE phase. If the
first message received by the target during the MESSAGE OUT phase is not <<
a task management message or >> a PPR message the target shall change to a
MESSAGE IN phase and issue a MESSAGE REJECT message followed by a PPR
message."

Bye for now,
George Penokie

Dept Z9V  114-2 N212
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208   FAX: 507-253-2880


*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org