QAS question

Elliott, Robert Robert.Elliott at
Tue Feb 27 13:19:23 PST 2001

* From the T10 Reflector (t10 at, posted by:
* "Elliott, Robert" <Robert.Elliott at>

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

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

Nobody should recognize that as a QAS cycle, even the target that
issued the QAS REQUEST or the currently connected initiator
receiving it.  BUS FREE should follow after a valid retry.

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

The latter two suggestions create new requirements for targets.
I'd rather just let them continue using their existing message 
parity error handling behavior without having to worry about 
which message was being sent.  The existing requirement just
allows a few extra QAS REQUEST messages before the eventual 

Rob Elliott, Compaq Server Storage
Robert.Elliott at

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

More information about the T10 mailing list