Robert.Elliott at COMPAQ.com
Tue Feb 27 13:19:23 PST 2001
* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert" <Robert.Elliott at compaq.com>
> -----Original Message-----
> From: Gerry.Houlder at seagate.com [mailto:Gerry.Houlder at seagate.com]
> Sent: Tuesday, February 27, 2001 2:50 PM
> To: t10 at t10.org
> Cc: Jim.Bell at seagate.com; Daniel.F.Smith at seagate.com
> 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 compaq.com
* 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