Wording issue with SPI-4 rev. 8

Richard Moore richard.moore at qlogic.com
Fri Jan 4 16:01:02 PST 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* "Richard Moore" <richard.moore at qlogic.com>
*
Gerry,

Your comment assumes one thing: that legacy initiators will know
to disconnect when they get a QAS REQUEST message. If they don't,
then they will see the message, followed by what looks like a long
dead time (no REQs or ACKs, BSY still set) and then what looks like
an illegal selection. I would think such initiators would become
very confused.

Of course, one would also have to assume the initiator doesn't
reject the message it doesn't recognize (which would cancel the
QAS and cause the target to go BUS FREE, and the only downside
is the time wasted), so with a proper initiator firmware
implementation this scenario won't happen. I could go along with
your change if there are no objections by anyone else.

 -- Richard Moore
    QLogic Corp.


-----Original Message-----
From: Gerry.Houlder at seagate.com [mailto:Gerry.Houlder at seagate.com]
Sent: Friday, January 04, 2002 3:31 PM
To: t10 at t10.org
Subject: RE: Wording issue with SPI-4 rev. 8


* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*

This is the paragraph Richard and Rob seem to have agreed on:

"When an initiator port and a target port have negotiated with each
other to enable QAS, either of the two ports may participate in QAS
arbitrations when attempting to connect to the other port. When an
initiator port and target port have negotiated with each other to
disable QAS, each port shall not participate in QAS arbitrations
when attempting to connect to the other port. When an initiator port
and a target port have negotiated with each other to enable both QAS
and information units, that target port may issue a QAS REQUEST message
to that initiator port to release the bus after a DT DATA phase. A
target port shall not send QAS REQUEST messages to an initiator unless
it has negotiated with that initiator to enable both QAS and
information units."

I have somee qualms about saying the "target port shall not send QAS
Request messages ..". If a target has one initiator that negotiated
QAS_REQ on and another that negotiated QAS_REQ off, what is the harm
in always sending QAS REQUEST message after all physical disconnects,
regardless of whether the command that is disconnecting (e.g., after
command or after data or after status) was directed to the initiator
that negotiated QAS_REQ on? In this case, as least one initiator and
probably a bunch of targets (if an initiator negotiated in on for one
target, it probably negotiated it on for other targets too) that are
QAS enabled. These other targets could participate in QAS and could
reselect even the initiator that doesn't participate in QAS. I think
this behavior should be allowed. I suggest this wording for the last
two sentences:

"When at least one initiator port has negotiated with a target port
to enable both QAS and information units, that target port may issue
a QAS REQUEST message to release the bus after a DT DATA phase.
When no initiator port has negotiated with a target port to enable
both QAS and information units, that target port shall not issue
a QAS REQUEST message to release the bus after a DT DATA phase."

*
* 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




More information about the T10 mailing list