unsolicited event clarification for RBC devices

George Chrysanthakopoulos georgioc at microsoft.com
Thu Feb 12 00:01:43 PST 1998


* 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




More information about the T10 mailing list