AER and UA interlock

Elliott, Robert Robert.Elliott at COMPAQ.com
Fri Jan 4 12:19:21 PST 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert" <Robert.Elliott at compaq.com>
*
I don't think the UA Interlock works as Gerry describes.  It only
interlocks CHECK CONDITION statuses that return UNIT ATTENTION sense
keys, not not all CHECK CONDITION statuses.

I've posted 02-025r0 which gets rid of the "instead of" wording, so UAs
reported via AER will interlock.

An open question is still whether a deferred error reported via AER
should interlock too?  Or, should all deferred errors interlock no
matter how they are reported (AER or by taking over a command with
otherwise GOOD status)?

---
Rob Elliott, Compaq Server Storage
Robert.Elliott at compaq.com



> -----Original Message-----
> From: Gerry.Houlder at seagate.com [mailto:Gerry.Houlder at seagate.com]
> Sent: Wednesday, November 28, 2001 11:24 AM
> To: t10 at t10.org
> Subject: Re: AER and UA interlock
> 
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Gerry.Houlder at seagate.com
> *
> 
> My impression of the UA interlock proposal is that any 
> "normal" error (one
> that is reported with CHECK CONDITION status) gets the 
> interlock treatment
> like a UA if the UA interlock feature is enabled. For instance, if an
> unrecoverable read or write error occurs (this is not 
> reported with Unit
> Attention sense key) occurs with the UA Interlock feature 
> enabled, it is
> supposed to get the same interlock behavior that a Unit 
> Attention (e.g.,
> reset occurred, device not ready, anything else with Unit 
> Attention sense
> key) is supposed to get. If this is the case then deferred errors and
> regular errors all inherit the behavior associated with Unit 
> Attentions.
> 
> 
> 
> 
> 
> "Elliott, Robert" <Robert.Elliott at COMPAQ.com>@t10.org on 11/27/2001
> 05:51:44 PM
> 
> Sent by:  owner-t10 at t10.org
> 
> 
> To:   <t10 at t10.org>
> cc:
> 
> Subject:  AER and UA interlock
> 
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Elliott, Robert" <Robert.Elliott at compaq.com>
> *
> The Control mode page defines how asynchronous event 
> reporting (AER) is
> enabled for three kinds of events:
> a) ready unit attentions (initialization complete)
> b) other unit attentions (all other kinds of UAs)
> c) deferred errors
> 
> It says that AER is used <instead of> creating a unit attention
> condition for the first two cases.  Taken literally, if the event is
> reported via AER, a unit attention condition is not established.
> 
> This did not matter before the UA interlock proposal 
> (00-359r7, sam2r21,
> spc3r2).
> That proposal mentions interlocking unit attentions that are reported
> with AERs.
> However, the SPC-3 wording means no UA condition exists to be reported
> (see below).  I suggest changing SPC-3 to indicate that unit 
> attentions
> are created for cases a) and b) - getting rid of the "instead of"
> wording.
> 
> Also, although deferred errors don't generate UAs, should they also be
> covered by the UA interlock feature?
> 
> 
> SAM-2 revision 21 section 5.8.5
> ===============================
> If a logical unit reports a unit attention condition with
> autosense (see 5.8.4.3) or with an asynchronous event
> report (see 5.8.4.2) and the UA_INTLCK_CTRL field in the
> Control mode page contains 00b (see SPC-3), then the logical
> unit shall clear the reported unit attention condition for that
> initiator on the logical unit. If the UA_INTLCK_CTRL field in
> the Control mode page contains 10b or 11b, the logical unit
> shall not clear unit attention conditions reported with
> autosense or an asynchronous event report.
> 
> 
> SPC-3 revision 2 section 8.3.6
> ==============================
> A ready AER permission (RAERP) bit of one specifies that the device
> server may issue an asynchronous event report upon completing its
> initialization sequence <instead of generating a unit attention
> condition>. A RAERP bit of zero specifies that the device server shall
> not issue an asynchronous event report upon  completing its
> initialization sequence.
> 
> NOTE 49 - If the device server's default value for the RAERP 
> bit is one
> and it does not implement saved parameters or include a 
> hardware switch,
> then it may be impossible to disable the initialization sequence
> asynchronous event
> reporting.
> 
> A unit attention AER permission (UAAERP) bit of one specifies that the
> device server may issue an asynchronous event report <instead of
> creating a unit attention condition> upon detecting a unit attention
> condition event, other than
> upon completing an initialization sequence. A UAAERP bit of zero
> specifies that the device server shall not issue an asynchronous event
> reporting _instead of creating a unit attention condition_.
> 
> An error AER permission (EAERP) bit of one specifies that the device
> server may issue an asynchronous event report upon detecting 
> a deferred
> error condition instead of waiting to report the deferred error on the
> next command. An EAERP bit of zero specifies that the device server
> shall not report deferred error  conditions via an asynchronous event
> reporting.
> 
> ---
> 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
> 
> 
> 
> *
> * 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