unsolicited event clarification for RBC devices

George Chrysanthakopoulos georgioc at microsoft.com
Wed Feb 18 15:29:21 PST 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* George Chrysanthakopoulos <georgioc at microsoft.com>
*
It might be important for harddrives since events such as error reporting or
power state changes that were ready to be communicated through unsolicited
status, never made it because of the bus reset.
However i agree that this is an implementation specific issue for HDDss.
Such events should be reported eventually no matter what the cause of
failing to transmit them was. This particular proposal focuses on user
initiated events, so it could be made optional for HDDs....

However if we want it to make it to SBP2 ( if  its not late) then no matter
what the device, unsolicited status reporting has to be persistant through
bus resets..

I dont feel strongly either way but i would prefer its made mandatory for
all devices under RBC, and if its accepted as part of SBP2, for all devices
period.
thanx
g

> -----Original Message-----
> From:	Mike_N_Bryan at notes.seagate.com [SMTP:Mike_N_Bryan at notes.seagate.com]
> Sent:	Wednesday, February 18, 1998 3:19 PM
> To:	George Chrysanthakopoulos
> Cc:	't10 at symbios.com'
> Subject:	Re: unsolicited event clarification for RBC devices
> 
> George,
> 
> We  don't oppose your proposal, but we would prefer to throw  away any old
> status
> while processing the bus reset. We understand that events occur in
> removeable drives that are important to the initiator, but is this
> requirement really
> necessary for HDD's? If you can convince us that its necessary for hard
> drives,
> then we'll support the proposal.
> 
> By the way, this proposal is broad enough to be incorporated into SBP-2,
> instead of RBC.
> 
> Mike
> 
> 
> 
> 
> 
> George Chrysanthakopoulos <georgioc at microsoft.com> on 02/12/98 01:01:43 AM
> 
> To:   "'t10 at symbios.com'" <t10 at Symbios.COM>
> cc:    (bcc: Mike N Bryan)
> Subject:  unsolicited event clarification for RBC devices
> 
> 
> 
> 
> * From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
> * George Chrysanthakopoulos <georgioc at microsoft.com>
> *
> > hi,
> >
> > this is a proposed addition to the RBC document that shall attempt to
> > clarify the status of an asynchronous(unsolicited) event when a bus
> reset
> > occurs. This is a followup to what we discussed in the last RBC meeting.
> >
> > " A device implementing the RBC command set and supporting asynchronous
> > event notification through unsolicited status shall defer any user
> > initiated event(s) notification, if a bus reset occurs after the user
> has
> > initiated the event(s) and before the event(s) was signalled through
> > unsolicited status, to the currently logged in initiator(s). If the
> > initiator(s) fail to reconnect to the target device, where the event(s)
> > occured, the user initiated event(s) must be discarded and unsolicited
> > status shall not be send. If the initiator succesfully reconnects using
> > the SBP2 RECONNECT function, the initiator shall perform a write to the
> > UNSOLICITED_STATUS register, to enable unsolicited status. Unsolicited
> > status must then follow the reconnect status, signalling the defered
> user
> > initiated event(s) to the initiator."
> >
> > thanks,
> > g
> >
> ps. I accidentally posted this on the old diskboys reflector so please
> excuse the duplicate.
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at symbios.com
> 
> 
> 
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com




More information about the T10 mailing list