QAS question

Bruce Leshay Bruce.Leshay at quantum.com
Tue Feb 27 13:47:12 PST 2001


* From the T10 Reflector (t10 at t10.org), posted by:
* Bruce Leshay <Bruce.Leshay at quantum.com>
*
Gerry,

	I think there might be a simpler solution.  The primary purpose of
coupling QAS with IU was the difficulties in detecting the QAS message in
the middle of a string of message bytes during a single MSG_OUT phase, as
normally happens in non-IU transfers with a disconnect message first, or a
"save data pointers" followed by a disconnect.  Without rehashing those
arguments from years ago, if we said now that if you negotiated QAS, and see
a 0x55 as the FIRST message byte of a message phase, then you enter into a
QAS arbitration (if no ATN & no parity error).  We just eliminate the
requirement that all those monitoring the bus also check that the previous
phase was a DTDATA phase. We would keep the restriction that QAS can only be
negotiated with IU, but now we can handle the retry of the QAS message
without any problem.
	Also, I think we already accepted the Compaq proposal that non-IU
devices can still participate in QAS arbitration, they just can't administer
it.  This would probably make things simpler for them as well.

						Bruce Leshay
						Quantum Corporation

-----Original Message-----
From: Gerry.Houlder at seagate.com [mailto:Gerry.Houlder at seagate.com]
Sent: Tuesday, February 27, 2001 3:50 PM
To: t10 at t10.org
Cc: Jim.Bell at seagate.com; Daniel.F.Smith at seagate.com
Subject: Re: QAS question


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

I will expand a bit on Bruce's response.

The initiator should raise ATN and send MESSAGE PARITY ERROR message in the
following Message out phase. This is the normal message parity error
response. Now for the hard part -- what will the target do with this?

The target will normally resend the previous message again. There will be a
vendor unique number of retries before the target gives up retrying the
message and eventually goes unexpected bus free.

Let us suppose the first resend of the 0x55 message is received by the
initiator without any parity error. ATN stays inactive. The target will
probably go to QAS. Will anyone else recognize this as a valid QAS phase?
It no longer satisifies the requirement of a single 0x55 message
immediately preceeded by a packet, so it probably should not be recognized
as a valid QAS. Thus no one but the target and maybe the initiator involved
with the last command will participate in the QAS cycle. If neither of
these has a command, the bus should change to BUS FREE.

Perhaps we would be better off to create a new message parity error rule
for 0x55 message. If a target sends 0x55 and a MESSASGE PARITY ERROR
message response is received, the target should change to COMMAND COMPLETE
message in the resend. If this is successful a normal bus free will occur
instead of QAS.

Another legal response the target can make is go to unexpected bus free
when a MESSAGE PARITY ERROR message is returned. (A vendor unique number of
retries can mean 0 retries.) Mandating this response could also be a simple
way to break the QAS cycle in a way that will not be misinterpreted by any
other devices on the bus.

Should we be thinking about choosing a single method for handling parity
error in the case of 0x55 message? This would surely simplify some of the
problems that can result in different actions for the several "allowed but
different" actions that exist today.





George_Penokie at tivoli.com@t10.org on 02/27/2001 01:17:41 PM

Sent by:  owner-t10 at t10.org


To:   t10 at t10.org
cc:

Subject:  QAS question


* From the T10 Reflector (t10 at t10.org), posted by:
* George_Penokie at tivoli.com
*
OK all you QAS experts, here is a question I have received that I don't
have a good answer for.

What happens if the initiator on the I_T nexus detects a parity error on a
QAS message? And, to make things even more interesting, the device that
wants the bus does not see a parity error on the same QAS message?

Bye for now,
George Penokie

Dept 2C6  114-2 N212
E-Mail:    gpenokie at tivoli.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
*
* 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