Abstract: This standard defines mechanical, electrical, and functional requirements for attaching host systems with each other as well as with intelligent peripherals such as rigid disks, flexible disks, magnetic tape devices, printers, optical disks, and scanners. The resulting interface facilitates the interconnection of host systems and intelligent peripherals and thus provides a common interface specification for both systems integrators and suppliers of intelligent peripherals. Although originally targeted at small computer systems, there is no upper limit on the host system size to which this interface may connect. This document adds a new protocol to SCSI to encapsulate messages, commands, command parameter data, command response data, logical blocks, and status into information packets which are capable of being processed on both serial and parallel busses. SCSI-2 was limited to short parallel busses. This addition breaks a dependence on the transmission layers and length limitations of the SCSI-2 parallel bus. A multiple path management protocol is also added to permit greater availability and performance for host systems using SCSI devices. The serial interface naturally lends itself to multiple path operation. Therefore, this function, currently described in document 89-133R1, is useful and adaptable to both the parallel and serial busses. 1. Scope This American National Standard defines input/output busses for interconnecting host systems and peripheral devices. The standard defines extensions to the Small Computer System Interface (X3.131-198X), referred to herein as SCSI-2. It also provides new commands and messages and a more complete standardization of the previously defined command sets. The document includes the necessary specification of the mechanical, electrical, and functional characteristics of the interface to allow inter-operability of devices meeting the standard. Inter-operability is only assured between two SCSI devices having compatible physical transmission layer characteristics. This standard is referred to herein as SCSI-3. The term SCSI is used wherever it is not necessary to distinguish between SCSI-2 and SCSI-3. SCSI consists of a selection of I/O busses, logical commands, and responses that can be operated over a wide range of data rates. The various physical layers through SCSI-2, represented by connectors, cables, signal definitions, and the signal protocol, required a parallel cable system to operate successfully. In several instances in SCSI-2, byte-by-byte processing was mandatory. A new optional protocol permits all SCSI device transfers to occur at maximum rate, and eliminates the asynchronous nature of most portions of the SCSI-2 physical parallel interface. The primary objective of the interface is to provide host systems with device type independence within a class of devices. Thus, different disk drives, tape drives, printers, optical media drives, and other devices can be added to the host systems without requiring modifications to host system hardware or generic software capable of handling the mandatory functions for each device class. Provision is made for the addition of special features and functions through the use of vendor specific fields and codes which may require host system software changes to use those features and functions. Reserved fields and code values are provided for future standardization. A second key objective of the standard is to provide compatibility with SCSI-2 devices. Properly conforming SCSI-2 devices, both initiators and targets, should respond in an acceptable manner to reject SCSI-3 protocol extensions. All SCSI-3 protocol extensions are designed to be permissive of such rejections and to allow SCSI-2 devices to continue inter-operation without requiring use of the extensions. SCSI-3 devices, both initiators and targets, attached to parallel busses, have the option of reverting to the SCSI-2 protocol to continue inter-operability with SCSI-2 devices. A third key objective of SCSI is to move device-dependent intelligence out to the devices. This requires the definition of a command set that allows an attached SCSI device to obtain all required initialization information from the other attached SCSI devices. The formalized sequence of requests identify the class of attached SCSI device, the characteristics of the device, and all the changeable parameters supported by the device. Further requests can determine the readiness of the device to operate, the types of media supported by the device, and all other pertinent system information. Those parameters not required by the operating system for operation, initialization, or system tuning are not exposed to the interface, but are managed by the device itself. The new optional features of SCSI-3 permit transport layer independence, since certain signal protocol requirements have been removed in favor of a logical interpretation of and response to information transfers. The optional features consist of new physical layer definitions for a serial protocol, and new commands, responses and messages. Operation in an environment with storage-to-storage transfers is possible without the use of a special I/O bus. In addition, reserved information transfer phases in the SCSI-2 parallel physical protocol are defined to permit the new features to operate on parallel bus systems without conflicting with SCSI-2 operations. Length limitations, including arbitration delays, are still imposed on the parallel interfaces. For storage devices, the interface uses logical rather than physical addressing for all data blocks. For direct-access class devices, each logical unit may be interrogated to determine how many blocks it contains. A logical unit may coincide with all or part of a peripheral device. The interface protocol includes provision for the connection of multiple initiators (SCSI devices capable of initiating an I/O process) and multiple targets (SCSI devices capable of responding to a request to perform an I/O process). A new optional provision provides for control of multiple initiator ports on one host system and multiple target ports on one target controller using more than one I/O bus. In parallel bus implementations, 1) distributed arbitration (i.e., bus-contention logic) is built into the architecture of SCSI. 2) a priority system awards interface control to the highest priority SCSI device that is contending for use of the bus. 3) the time to complete arbitration is independent of the number of devices that are contending for the bus and arbitration can be completed in less than 10 microseconds. In serial bus implementations, 1) arbitration, if any, is a function of the serial protocol used and not a concern of the SCSI architecture (e.g., an FDDI serial layer). 2) the priority of access to the interface is a function of the serial protocol 3) the time for arbitration, if any, is a function of the serial protocol used. Implementations which use other bus structures (e.g., a processor bus) for the transportation layer must follow the arbitration, priority and timing constraints of that implementation. The physical characteristics are described in Section 4. In parallel bus implementations, there are two electrical alternatives: single-ended and differential. Single-ended and differential devices are electrically different and should not be mixed on the same bus. Provision is made for cable lengths up to 25 meters using differential drivers and receivers. A single-ended driver and receiver configuration is defined for cable lengths of up to 6 meters and is primarily intended for applications within a cabinet. In serial bus implementations, TBD, but current choices may include the FDDI physical interface for up to 12.5 MB/S transfers and the Fiber Channel for up to 100 MB/S transfers in one direction. These new physical layers permit information transfers up to several kilometers. Section 5 describes the protocol for information transfer using the parallel and serial interfaces. A logical operation model is introduced (See 89-133R1). Arbitration is defined as part of and unique to each physical layer to permit multiple initiators and to permit concurrent I/O processes. For parallel bus implementations, all SCSI devices are required to be capable of operating with the defined asynchronous transfer protocol. An optional synchronous transfer protocol is defined. Section 5 also specifies a message protocol for control of the interface. An optional SCSI-3 information transfer protocol is defined in Section 5. The two message phases, the command phase, the status phase, and the two data phases are combined into two new information transfer phases. The logical functions transmitted by the SCSI-2 phases is carried over into the two new phases. A packet structure is defined which encapsulates the logical information and data for transfer using the new information transfer phases. New messages and protocols are introduced to support new functions and the new packet structure. The SCSI command and status structure is specified in Section 6. Commands are classified as mandatory (M), optional (O), or vendor unique (V). SCSI devices are required to implement all mandatory commands defined for the appropriate device class and may implement other commands as well. Within each command, there are mandatory functions which must be implemented; there are optional functions within some commands which may be implemented. When a command is implemented, an SCSI device shall implement the functions identified as mandatory. SCSI devices contain commands that facilitate the writing of self-configuring software drivers that can "discover" all necessary attributes without prior knowledge of specific peripheral characteristics (such as storage capacity). Many commands also implement a very large logical block address space (2**32 blocks), although some commands implement a somewhat smaller logical block address space (2**21 blocks). Section 7 specifies those commands that have a consistent meaning for all device classes. New commands for multiple path operation are defined in this section. (See 89-133R1.) Sections 8 through 17 contain commands for device classes called direct-access (e.g., magnetic disk), sequential-access (e.g., magnetic tape), printer, processor, write-once (e.g., optical disk), CD-ROM, scanner, optical memory, medium changer, and communications, respectively. The commands in each of these sections are unique to the device class, or they have interpretations, fields, or features that are specific for the device class. Thus, for example, although the WRITE command is used for several device classes, it has a somewhat different form for each class, with different parameters and meanings. Therefore, it is specified separately for each device class. Appendices are not a required part of this standard. They are included to give extra explanatory material about the interface options and the various protocols available. Appendices A through C provide examples of SCSI signal sequences, timing, and phase sequences for parallel bus implementations. (NOTE: These appendices need updating to include the nexus transfer phases introduced in Section 5.) Appendix D contains information on other standards related to medium types and density codes for flexible disks and magnetic tapes. Appendix E describes data integrity in command queuing environments. Appendix F describes normal procedures following a power-on condition. Appendix G describes the worst case skew times for a fast SCSI parallel bus implementation. Appendix H contains information on other SCSI standardization activities. Appendix I contains the additional sense codes and operation codes in numerical order. Appendix J contains the vendor identification codes as of the date of this document. 2. Referenced Standards and Organizations The requirements of ISO 8482:1987, "Information Processing - twisted pair multi-point interconnection data communication" apply to the use of differential drivers and receivers. American National Standard Small Computer System Interface, X3.131-1986, may also be useful to achieve compatibility with devices that conform to version 1 of SCSI. The medium catalog numbers in the CD-ROM section (13) are controlled by the Uniform Product Code Council, 8163 Old Yankee Road, Suite J, Dayton, Ohio 45459, U.S.A. and the European Article Number Council, Rue des Colonies, 54- BTE8, 1000 Brussels, Belgium. (NOTE: Add references to applicable serial interfaces as they become available. GRS) 3. Glossary and Conventions 3.1. Glossary This section contains a glossary of special terms used in this standard. Also see glossaries in sections 5.x, 8.4, 9.4, ..., 17.4. active I/O process. For targets, an I/O process that is presently in execution (not queued). For initiators, an I/O process for which a connect has been successfully performed. AEN. Asynchronous event notification (see 6.5.5). AWG. American Wire Gauge. burst. A contiguous set of bytes which represent all or part of the logical block(s) requested by a command, all or part of the command parameter data, or all or part of the command response data. Bursts are variable length. A burst transfer is made during a connection. A burst transfer is not part of every connection. Multiple burst transfers may occur in a single connection. byte. In this standard, this term indicates an 8-bit (octet) construct. CA. Contingent Allegiance (see 6.6). command. A request in the form of a command descriptor block, and optionally command parameter data, sent from a host system to a target controller to cause a logical unit or target routine to perform some function on behalf of the host system. command descriptor block (CDB). An organized collection of bytes used to communicate commands from an initiator to a target. This term is used to differentiate this data from messages, command parameter data, command response data, status and logical blocks. command parameter data. An organized collection of bytes (0 or more in length) provided as an addendum to command descriptor blocks of some commands. This term is used to differentiate this data from messages, CDBs, command response data, status and logical blocks. command response data. An organized collection of bytes (0 or more in length) provided in response to a command but which are not logical blocks from the target (e.g., sense data). This term is used to differentiate this data from messages, CDBs, command parameter data, status and logical blocks. command queue. A queue used to store the tagged I/O processes in both a host system and a target controller (see 6.8.2). connect. The initiator function that selects a target and results in establishing a nexus and starting an I/O process. The connection that results is an initial connection. connection. An initial connection or reconnection. A connection can only occur between one initiator and one target. A connection begins at the end of the SELECTION or RESELECTION phase; a connection ends with the next disconnect. contact. The electrically-conductive portion of a connector associated with a single conductor in a cable. current I/O process. The I/O process that is presently connected on the SCSI bus. Only one I/O process may be current on a single SCSI bus. device class. A similar set of peripheral devices all having the same logical model as specified in Sections 8 through 17. Mandatory and optional functions are specified. device type. A specific peripheral device which has implemented some or all of the functions specified for its device class and some or all of those functions specified in Sections 5 through 7. All mandatory functions are implemented. disconnect. (Parallel interfaces.) The action that occurs when an SCSI device releases control of the SCSI bus, allowing it to go to the BUS FREE phase. (Serial interfaces.) The action that occurs when the end of an information packet transfer is reached. ECA. Extended Contingent Allegiance (see 6.7). field. A group of one or more contiguous bits. Fields containing only one bit are usually referred to as the xx bit instead of the xx field. host adapter. A port on an SCSI device, usually a processor device class. See initiator. host system. A logical element which principally causes I/O processes to be started. A host system must have at least one SCSI port to be considered an SCSI device. H_C nexus. A nexus which exists between a host system and a target controller. An H_C nexus, or any of its derivatives, may use more than one initiator and one target combination for connections during an I/O process. H_C_L nexus. A nexus which exists between a host system, a target controller, and a logical unit. This relationship replaces the prior H_C nexus. H_C_R nexus. A nexus which exists between a host system, a target controller, and a target routine. This relationship replaces the prior H_C nexus. H_C_x nexus. A nexus which is either an H_C_L or H_C_R nexus. H_C_L_Q nexus. A nexus between a host system, a target controller, a logical unit, and a queue tag. This relationship replaces the prior H_C_L nexus. H_C_x_y nexus. A nexus which is either an H_C_x or H_C_L_Q nexus. H_I_T_C nexus. An H_C nexus, or one of its derivatives, between a host system and a target controller, restricted to one initiator and one target on one SCSI bus. An I_T nexus, or any of its derivatives, is an H_I_T_C nexus. information packet. A group of bytes containing interface control fields and interface logical elements. initial connection. (Parallel interfaces.) An initial connection is the result of a connect. (Serial interfaces.) An initial connection is the result of a connect and the successful transfer of an information packet from the initiator. initiator. A port on an SCSI device which is principally responsible for using an SCSI bus to start I/O processes. An initiator is usually attached to a host system. An initiator is a port to one SCSI bus. initiator mode. The current operating mode of an SCSI port which permits it to select another SCSI device port on the same SCSI bus. interface control fields. An organized collection of bytes used to encapsulate interface logical elements in information packets. Some of these fields are interpreted by the link layer for the proper routing of information packets between host systems and target controllers. interface logical elements. Organized collections of bytes containing messages, CDBs, command parameter data, command response data, status, or logical blocks, or a self-describing combination of these. The self-describing version of the interface logical elements is used only with the nexus transfer phases on parallel interfaces or with the serial interface. invalid. An illegal (reserved) or unsupported bit, field, code value, or bus phase. I/O process. An I/O process consists of one initial connection and zero or more reconnections, all pertaining to the exchange of an ordered set of interface logical elements. More specifically, the connection(s) pertain to a nexus in which zero or more command descriptor blocks may be transferred. An I/O process begins with the establishment of a nexus. (Parallel interfaces.) An I/O process normally ends with the disconnect following successful transfer of a COMMAND COMPLETE or a RELEASE RECOVERY message. An I/O process also ends with the disconnect following an ABORT, ABORT TAG, BUS DEVICE RESET, or CLEAR QUEUE message or when a hard RESET condition or an unexpected disconnect occurs. (Serial interfaces.) An I/O process normally ends with the successful transfer of an information packet containing a COMMAND COMPLETE or a RELEASE RECOVERY message. An I/O process also ends with the successful transfer of an information packet containing an ABORT, ABORT TAG, BUS DEVICE RESET, or CLEAR QUEUE message or when a hard RESET condition has been successfully transmitted on the interface. I_T nexus. An H_I_T_C nexus. A nexus, or any of its derivatives, which is restricted to one initiator and one target on one SCSI bus. I_T_L nexus. An I_T nexus which exists between one initiator, one target, and a logical unit. This relationship replaces the prior I_T nexus. I_T_R nexus. An I_T nexus which exists between one initiator, one target, and a target routine. This relationship replaces the prior I_T nexus. I_T_x nexus. An I_T nexus which is either an I_T_L or I_T_R nexus. I_T_L_Q nexus. An I_T nexus between one initiator, one target, a logical unit, and a queue tag following the successful receipt of one of the queue tag messages. This relationship replaces the prior I_T_L nexus. I_T_x_y nexus. An I_T nexus which is either an I_T_x or I_T_L_Q. logical block. A unit of data supplied from or requested by an initiator. This term is used to differentiate these data from messages, CDBs, command parameter data, command response data, and status. A logical block may be fixed or variable in length. logical unit. A physical or virtual peripheral device addressable through a target controller. logical unit number. An encoded identifier for a logical unit. LSB. Least significant bit. LUN. Logical unit number. message. An organized collection of bytes (1 or more) used for control of an SCSI bus between an initiator and a target or for control of a nexus, and such control is not possible through the defined commands. This term is used to differentiate these data from a CDB, command parameter data, command response data, status, and a logical block. mm. Millimeter. ms. Millisecond. MSB. Most significant bit. m**n. A mathematical expression representing the number m raised to the n-th power. Both m and n are integer decimal numbers. nexus. A relationship between a host system and a target controller that begins with an initial connection and ends with the completion of the I/O process started during the initial connection. The relationship may be restricted to operate between one initiator and one target on a single SCSI bus. The relationship may be restricted to a single logical unit or target routine through the identify function. The relationship may be further restricted by the queueing function. ns. Nanosecond. one. A true signal value or a true condition of a variable. page. Several commands use regular parameter structures that are referred to as pages. These pages are identified by a page code. page code. A field within a page whose value is unique within a command. The page code provides the means to interpret the remaining fields in a page. parameter. A structure containing one or more fields. peripheral device. A physical device that can be attached to an SCSI device, and which, in turn, is attached to at least one SCSI bus through at least one SCSI port. A peripheral device and a SCSI device may be physically packaged together. Often there is a one-to-one mapping between peripheral devices and logical units, but this is not required. Examples of peripheral devices are: magnetic disks, printers, optical disks, magnetic tapes, and processors or host systems. Although not often thought of as peripheral devices, host systems, which declare themselves as processor device types and implement target mode on at least one port in its SCSI device, are also peripheral devices. port. See SCSI port. queue tag. The value associated with an I/O process that uniquely identifies it from other queued I/O processes on the logical unit for the same host system. queued I/O process. An I/O process that is in the command queue and is not an active I/O process. reconnect. The act of reviving a nexus to continue an I/O process. The connection may be on the same initiator and target pair as the last connection or on a different pair. The action taken by the target to revive the nexus depends on the host system conditions established in the target controller. (Parallel interfaces.) A target controller reconnects with an initiator using the RESELECTION phase and transferring one or more messages. An initiator reconnects with a target using the SELECTION phase and causing the transfer of one or more messages (see 6.5.2). (Serial interfaces.) A target reconnects by successfully transferring an information packet associated with a nexus to an appropriate initiator. An initiator reconnects by successfully transferring an information packet associated with a nexus to an appropriate target. reconnection. A reconnection is the result of a reconnect. (Parallel Interfaces.) A reconnection exists from the end of the SELECTION or RESELECTION phase until the next disconnect. (Serial Interfaces.) A reconnection exists while the receiving port is actively receiving an information packet. reserved. The term used for bits, fields, code values, and bus phases that are set aside for future standardization. SCSI. Either SCSI-2 or SCSI-3. SCSI-2. The Small Computer System Interface - 2 (X3.131-198X). SCSI-3. The Small Computer System Interface - 3 (X3.131-199X). SCSI address. The representation of the unique address assigned to one SCSI port on an SCSI device. This address would normally be assigned and set in each SCSI port during system installation. The SCSI address must be unique on a single SCSI bus. Two SCSI ports on the same SCSI device connected to the same SCSI bus must have different SCSI addresses. The form of the SCSI address varies with the physical interface used. SCSI ID. (Parallel interfaces.) The bit-significant representation of the SCSI address referring to one of the data bus signal lines available to the SCSI device excluding parity lines. (Serial interfaces.) The field value assigned to the source and destination fields of the interface control fields. Neither the SCSI ID nor the number of SCSI devices on a serial interface is related to the number of signal lines in the interface. SCSI device. A device configured for attachment to one or more SCSI busses via one or more SCSI ports. The device may allow an SCSI port to function either in initiator mode or in target mode for any one connection. Many SCSI devices implement only one mode for all SCSI ports. SCSI port. A name for the portion an SCSI device where it attaches to one and only one SCSI bus. An SCSI device may have more than one port each of which may be attached to a different SCSI bus. Each port has an SCSI address and an SCSI ID unique to the SCSI bus to which it is attached. SCSI ports are usually called initiators and targets. Any SCSI device port may operate in either initiator mode or target mode. signal assertion. The act of driving a signal to the true state. (Parallel interfaces.) signal negation. The act of driving a signal to the false state or allowing the cable terminators to bias the signal to the false state (by placing the driver in the high impedance condition). (Parallel interfaces.) signal release. The act of allowing the cable terminators to bias the signal to the false state (by placing the driver in the high impedance condition). (Parallel interfaces.) status. One or more bytes of information sent from a target to an initiator upon completion of each command. This term is used to differentiate these data from a message, a CDB, command parameter data, command response data, and a logical block. target. A port on an SCSI device which is principally responsible for receiving I/O processes. A target is usually attached to a target controller. A target is a port to one SCSI bus. target controller. A logical element which principally executes I/O processes on behalf of a host system. A target controller must have at least one SCSI port to be considered an SCSI device. target mode. The current operating mode of an SCSI port which permits it to be selected by another SCSI device port on the same SCSI bus. target routine. A selectable function within a target controller which executes I/O processes. A target routine is similar to a logical unit in that it has a name, target routine number (TRN), and a command set to execute. target routine number. An encoded identifier for a target routine. third-party. When used in reference to COPY commands, third-party means a COPY command issued to one device to perform a copy operation between two other devices. When used in reference to RESERVE, or RELEASE commands, third- party means a reservation made on behalf of another device (e.g., A processor device requests that a direct-access device reserve itself for use by a sequential-access device). TRN. target routine number. unexpected disconnect. A disconnection that occurs as a result of a protocol error (see 5.1.1). (Parallel interfaces.) us. Microsecond. vendor specific (VS). Something (e.g., a bit, field, code value, etc.) that is identified in this standard, but whose use is not defined by this standard and may be used differently in various implementations. xx. Numbers, except those used as section numbers in the text of this standard, that are not immediately followed by lower-case "b" or "h" are decimal values. Large Numbers are not separated by commas or spaces (e.g., 12345; not 12,345 or 12 345). xxb. Numbers immediately followed by lower-case "b" are binary values. xxh. Numbers immediately followed by lower-case "h" are hexadecimal values. zero. A false signal value or a false condition of a variable. 3.2. Editorial Conventions Certain words and terms used in this standard have a specific meaning beyond the normal English meaning. These words and terms are defined either in the glossary (see 3.1 and 8.4, 9.4, ..., 17.4) or in the text where they first appear. Names of signals, phases, messages, commands, statuses, sense keys, additional sense codes, and additional sense code qualifiers are in all upper-case (e.g., REQUEST SENSE). Lower-case is used for words having the normal English definition unless the word or phrase is defined in context or in the glossary, in which case that definition is to be used. 3.3. Relationship of Some Defined Terms Some terms defined in the glossary have a relationship to one another which can be shown pictorially as follows. .kp on SCSI DEVICE Configurations to Initiate an I/O Process -- SCSI Device as an Initiator --------------------------- | SCSI DEVICE | --------------------------------------- | HOST || ||SCSI PORT | | SYSTEM || INITIATOR|| SCSI ADDRESS|-SCSI BUS- | || MODE || SCSI ID | --------------------------------------- -------------------------- | SCSI DEVICE | ------------------------------------------------- |PERIPHERAL|| TARGET || ||SCSI PORT | | DEVICE ||CONTROL- ||INITIATOR|| SCSI ADDRESS|-SCSI BUS- | || LER || MODE || SCSI ID | ------------------------------------------------- Configurations to Execute an I/O Process -- SCSI Device as a Target ----------------------- | SCSI DEVICE | ------------------------------------------------------ |PERIPHERAL||LU+LUN || TARGET || ||SCSI PORT | | DEVICE ||-------||CONTROL-||TARGET|| SCSI ADDRESS|-SCSI BUS- |----------||TARGET || LER || MODE || SCSI ID | |PERIPHERAL||ROUTINE|| || || | | DEVICE ||----------------------------------------- ------------- ------------------------- | SCSI DEVICE | ---------------------------------------------- | ||LU+LUN || ||SCSI PORT | | HOST ||-------|| TARGET || SCSI ADDRESS|-SCSI BUS- | SYSTEM ||TARGET || MODE || SCSI ID | | ||ROUTINE|| || | ---------------------------------------------- .kp off .kp on LOGICAL ACTIVITY CONSTRUCTS ------------------------- NEXUS ------------------------- ---------------------- I/O PROCESS ---------------------- ------------------ ACTIVE I/O PROCESS ------------------- CURRENT I/O PROCESS CURRENT I/O PROCESS ___I/O BUS ACTIVE___ ____________________ ___| |_I/O BUS INACTIVE_| |___ INFORMATION PACKET INFORMATION PACKET CONNECTION DISCONNECT CONNECTION DISCONNECT CONNECT INITIAL CONNECTION RECONNECTION .kp off .kp on INFORMATION PACKET CONTENT INTERFACE CONTROL FIELDS INTERFACE LOGICAL ELEMENTS message(s) command descriptor block command parameter data command response data logical block(s) status .kp off .kp on INFORMATION PACKET TRANSFER MANAGEMENT SCSI-2 SCSI-3 (w/Option) special phases and interface general phases and logical elements self-describing logical interface elements .kp off .kp on COMPARISON OF BUS ACTIVITIES CONNECTION 1 CONNECTION 1 MESSAGE OUT phase (w/Attention) INFORMATION TRANSFER OUT phase message(s) message(s) COMMAND phase command descriptor command descriptor block command parameter data (Opt.) DATA OUT phase (Opt.) command parameter data (Opt.) MESSAGE IN phase message(s) CONNECTION 2 CONNECTION 2 MESSAGE IN phase INFORMATION TRANSFER IN phase message(s) message(s) DATA IN/OUT phase(s) logical block(s) logical block burst(s) or command response data or command response data status STATUS phase message(s) status MESSAGE IN phase message(s) .kp off The SCSI-3 optional mode is required to operate on a serial interface. For the serial interface there are only three phases: BUS FREE, INFORMATION TRANSFER IN, INFORMATION TRANSFER OUT. 4. Physical Characteristics This section contains the definition of the physical transport layers of SCSI. Sections 4.1 through 4.8 describe the parallel physical transport layer options available. Sections 4.9 through 4.16 describe the serial physical transport layer options available. The connectors, cables, signals, terminators, and bus timing values needed to implement each transport layer are specified. For the serial interface, references are made to the appropriate standards and the options from those standards applicable to SCSI-3 are specified. See Section 2 for the complete titles and document numbers for these standards. 4.1. Parallel Interface Physical Description No Change. 4.2. Parallel Interface Cable Requirements No Change. 4.3. Parallel Interface Connector Requirements No Change. 4.4. Parallel Interface Electrical Description No Change. 4.5. Parallel Interface SCSI Bus No Change. 4.6. Parallel Interface SCSI Bus Signals No Change. 4.7. Parallel Interface SCSI Bus Timing No Change. 4.8. Parallel Interface Fast Synchronous Transfer Option No Change. 4.9. Serial Interface Physical Description SCSI devices attached to a serial interface use a 2-conductor cable made up from either copper wire or optical fiber strands. One conductor always transfers information packets into the SCSI device, called the receive conductor, and one conductor always transfers information packets away from the SCSI device, called the send conductor. Within the optical fiber option, there are plastic and glass conductors. Inter-operability of implementations using different types of conductors is not to be assumed from this standard. There are two layouts or topologies defined. The topologies are called point-to-point and string. The topology selected for an implementation determines the type of adapter required in an SCSI device. Inter-operability of implementations using different topologies is not to be presumed from this standard. All transfers use a synchronous mode of transfer. The method for balancing the count of bytes transferred during a connection is different than for parallel interfaces. For each information packet received on the receive conductor and not forwarded, there is an acknowledgement information packet sent on the send conductor. Since one or more information packets may be in the conductors at the same time, there is no mechanism to acknowledge receipt of bytes on a byte-by-byte basis. The six mutually exclusive choices are identified in Table 4-xx. NOTE: Appropriate adapters might be constructed, whose functions are outside the scope of this standard, which would permit inter-operability. .kp on Table 4-xx. Serial Transport Layer Options CONDUCTOR TYPE TOPOLOGY Copper Optical String Switch Plastic Glass Required Point-to-Point x x x No String x x x Yes .kp off 4.9.1. Point-to-Point Topology A point-to-point topology exists when, from the initiator and target perspective, one conductor is outbound from the initiator and the other is inbound to the initiator, respectively. No other devices appear to share the conductors. The send conductor of the initiator is connected to the receive conductor of the target and the send conductor of the target is connected to the receive conductor of the initiator. See Figure 4.ww. Figure 4.ww shows one implementation of the point-to-point topology which provides one initiator for each target and a single 2-conductor cable attached between them. Although possible, this is not a likely implementation, except for high performance devices or for some other host system integration reason. In this implementation, every information packet received by an SCSI device has only one source. Every information packet sent has only one destination. .kp on Figure 4-ww. Example of Point-to-Point Topology ----------- -------- | |--------Outbound Information ----------->| | |INITIATOR| |TARGET| | |<--------Inbound Information ------------| | ----------- -------- .kp off The most likely implementation of a point-to-point topology consists of one or more point-to-point switches between the initiator and the target. The switches are specified as part of the applicable standards. The initiators and targets are attached to a switch. The switches may be interconnected to provide addressability to a large set of SCSI devices. Conditions in the point-to-point switches are established in such a way to make a connection appear point-to-point, as indicated in Figure 4.ww above. Multiple initiators and targets may be attached to the switches and then the paths through the switches are adjusted, as required, to provide physical paths between an initiator and a target for the duration of a connection. The mechanism for adjusting the switches is part of the applicable standards. In the example in Figure 4.xx, the host system may be sending information packets on both of the send conductors to the target controller while, at the same time, receiving information packets on both receive conductors from the same target controller. The number of available ports, the use of multiple path operation, and the complexity of the switches determines the number of concurrent connections possible. The maximum in this example is six concurrent connections. The cabling between switches does not add to the level of concurrent connections. .kp on Figure 4-xx. Example of Point-to-Point Topology with Switches Other Switches or SCSI Device Ports | | ----------------- | | --------------- | | | | | | | H ----------- -------- -------- T | | O | |--Send--->| |-Receive->| | A | | S |INITIATOR| |SWITCH| |TARGET| R | | T | |<-Receive-| |<--Send---| | G C | | ----------- -------- -------- E O | | S | | | | T N | | Y | | | | T | | S ----------- -------- -------- R | | T | |--Send--->| |-Receive->| | O | | E |INITIATOR| |SWITCH| |TARGET| L | | M | |<-Receive-| |<--Send---| | L | | ----------- -------- -------- E | | | | | | R | ----------------- | | --------------- | | Other Switches or SCSI Device Ports .kp off In Figure 4.xx, every information packet received by an SCSI device port is similar to that of the parallel daisy-chained implementations. That is, the switch settings provide the same isolation of SCSI device ports during a connection as does the SELECTION or RESELECTION phase on a parallel interface. Concurrency in parallel bus operation is limited by the number of SCSI busses. In Figure 4.xx, each information packet may be sent to a different destination, and each information packet received may come from a different source. This is similar to parallel bus operation where each arbitration phase may result in connections between various initiators and targets connected to an SCSI bus. 4.9.2. String Topology String topology looks similar to the parallel daisy-chained bus implementation, but it is not. String topology places one additional requirement on each SCSI device port, has one performance implication, and has one availability implication. The string topology forms a loop from the send conductor of an SCSI device port to its receive conductor. See Figure 4.zz. The conductor passes through a four-point single-conductor string switch for each attached SCSI device port. See Figure 4.yy. .kp on Figure 4.zz. Example of String Topology and Point-to_Point Topology Other Switches or SCSI Devices | | | | | | <----- STRING ------> ----------- -------- -------- -------- | |---Send-->| |-Receive->|TARGET|---->|TARGET|----| |INITIATOR| |SWITCH| -------- -------- | | |<-Receive-| |<--Send----------------------------- ----------- -------- | | | | | | Other Switches or SCSI Devices .kp off The effective bandwidth of the string topology is one-half that of the point-to-point topology. There are one-half as many conductors as in the point-to-point topology. The string becomes inoperative when any string switch becomes inoperative. That is, information packet forwarding fails when a string switch fails. The receive conductor of the string switch in Figure 4.yy is switched to either receive conductor of the local SCSI device port or it is switched to the send conductor of the string switch and forwarded to the next SCSI device port attached to the string. The local SCSI device port has its send conductor attached to the switch, and the switch always routes an information packet on the send conductor of the string switch. Each conductor on this switch has a mandatory flow directions and decision points as specified above and shown in Figure 4.xx. NOTE: The SCSI device port may be implemented as a point-to-point connection to the local SCSI device conductors of the string switch. This potentially permits one implementation of the SCSI device port to be used in either topology. This permits the string switch to be a separate component in the configuration. If the string switch were not an expensive element and could be packaged with and initialized by the SCSI device, the string switch cwould be made transparent in point-to-point mode and active in string mode. If the string switch has a bypass mode, the SCSI device port can be added to or taken away from the string without disrupting string operation (i.e., hot plugged). .kp on Figure 4.yy. Example of SCSI Device Port with String Switch RECEIVE SEND -------------- -------------> CONDUCTOR | | CONDUCTOR V | --|---------|-- | S-------->S | | | A | | | STRING | | | | SWITCH | | | | | | --|---------|-- LOCAL | | LOCAL OUTBOUND | | INBOUND V | ----------------------------------- | | SCSI | | | | DEVICE | | | | PORT | | | --------------- | | | | SCSI Device | | | ----------------------------------- V, A, and > indicate the direction of the flow of information packets. S indicates the switch points where direction decisions must be made and implemented. .kp off The sender an information packet transfers it on its send conductor and then each string switch on the string, in turn, receives each information packet on its receive conductor and checks to see if it is addressed to the local SCSI device port. If it is not addressed to that SCSI device port, the information packet is switched to the send conductor of the string switch. If the information packet is improperly addressed, it will be forwarded back to the sender and received on the original sender's receive conductor. If the packet is correctly addressed to the local SCSI device port, then the string switch will route the information packet to the receive conductor of the SCSI device port. The SCSI device port will then send an acknowledgement information packet on its send conductor. The acknowledgement information packet is addressed to the sender of the original information packet. The string switch always routes this information packet on its send conductor. In the string topology, string switches may be separated by zero or more point-to-point switches. See Figure 4.zz. The connection through these switches is always 2-conductors, point-to-point. That is, the two conductors into the switch for a string are always routed through the switch in pairs, unlike the string switch which routes only one conductor. A single conductor of a string shall not be routed through a point-to-point switch. A target on the string in Figure 4.zz sends an information packet on its send conductor. The information packet is received, checked, and forwarded by each string switch until it is received at its destination. The SCSI device port, represented as an initiator in Figure 4.zz, must be attached to a string switch since it must be capable of forwarding information packets sent between any two SCSI device ports on the string. 4.10. Serial Interface Cable Requirements 4.10.1. Copper 4.10.2 Optical Glass 4.10.3 Optical Plastic 4.11. Serial Interface Connector Requirements 4.11.1. Copper 4.11.2 Optical Glass 4.11.3 Optical Plastic 4.12. Serial Interface Electrical Description for Copper 4.13. Serial Interface Optical Description 4.13.1 Optical Glass 4.13.2 Optical Plastic 4.14. Serial Interface Bus 4.15. Serial Interface Signals 4.15.1. Electrical 4.15.2. Optical Glass 4.15.2. Optical Plastic 4.16. Serial Interface Timing 4.16.1. Electrical 4.16.2 Optical Glass 4.16.3 Optical Plastic 5. Protocol for Information Transfer The protocol for information transfer is divided into five sections: 1) parallel interface in Sections 5.1 through 5.4; 2) serial interface in Sections 5.5 through 5.8; 3) logical operations model in section 5.9; 4) information packet description in section 5.10; 5) message system description in Section 5.x through 5.y. The optional nexus transfer phase provides an alternative protocol for the way information is transferred across the SCSI bus. The interface logical elements are formed in to self describing units and are then placed into an information packet of variable length. The information packet is then transferred using the nexus transfer phase. The interface logical elements are messages, command descriptor blocks, command parameter data (additional data required for some commands), command response data (data not from logical blocks), logical blocks, and status. The nexus transfer phase requires that all interface logical element lengths be declared in an information packet in advance of the information packet transfer on the SCSI bus. The information transfer phases defined in SCSI-2 are still defined and work as before. The interface logical elements are not formed in to self describing units, but rather the SCSI-2 information transfer phases serve as descriptors. The variable length nature of interface logical elements is generally variable to the initiator for inbound transfers and some outbound data transfers. The target has only one variable interface logical element and that is outbound messages. With the information packet structure, it is possible to perform all operations using only the nexus transfer phase. This is accomplished by placing descriptors in the information packet which are interpreted by the initiator or target, usually after the information packet transfer is complete. No interpretation of the data in the information packet shall be permitted which halts the transfer of the information packet on the interface. Parity errors are handled by retransmitting the information packet. The initial information packet transfers on the parallel SCSI bus, which are in asynchronous data transfer mode, permit no interlock mechanism on the individual bytes as they are transferred. Only the actual transfer time may be slower than in synchronous data transfer mode. For serial interface implementations, all transfers are in synchronous data transfer mode, and the nexus transfer phase is the only phase available for information transfer. When implementing the nexus transfer phases, there are additional requirements: 1) All SCSI devices shall implement an active initiator mode and an active target mode (i.e., dynamic switching of the SCSI port mode with each SELECTION or RESELECTION phase in parallel bus implementations). 2) All SCSI devices shall implement synchronous data transfer. For parallel interface implementations, each SCSI device port shall negotiate for and be granted synchronous data transfer mode. For serial implementations, synchronous data transfer mode is the only transfer mode on the SCSI bus. 3) Initiators shall respond correctly to asynchronous event notification. This permits dynamic changes to the logical system over time and earlier problem determination. 4) Targets shall implement asynchronous event notification. Events not occurring in the confines of an I/O process are reported when they occur. 5) A SCSI device port which normally acts as an initiator, when selected, shall declare itself as an appropriate device class in response to the INQUIRY command. Usually the device class is reported as processor to permit asynchronous event notification. 6) The target controller shall implement the initiator mode on each port so that it can select the initiators to acquire the INQUIRY data to determine its active initiators, provide asynchronous event notification, and declare itself a SCSI device which uses the nexus transfer phases. 5.1. Parallel Interface SCSI Bus Phases The SCSI architecture includes nine distinct phases: BUS FREE phase ARBITRATION phase SELECTION phase RESELECTION phase COMMAND phase \ DATA phase \ These phases are collectively termed the STATUS phase / information transfer phases. MESSAGE phase / NEXUS TRANSFER phase / The SCSI bus can never be in more than one phase at any given time. In the following descriptions, signals that are not mentioned shall not be asserted. The nexus transfer phase is mutually exclusive of the other information transfer phases. During a connect, if the first information transfer phase of a connection is not a nexus transfer phase, then it shall be an error to attempt to use a nexus transfer phase within the same connection or any subsequent connection for the I/O process. Conversely, if the first information transfer phase of a connect is a nexus transfer phase, it shall be an error to attempt to use any other phase within the same connection or a subsequent connection for the I/O process. Since targets control the selection of information transfer phases, the target must initiate a procedure, at power-on or after the reset condition, which declares that it is capable of operating with the nexus transfer phase. The first information packet transferred on a parallel interface, after power-on reset or after processing the reset condition by a target, shall contain a request to negotiate synchronous data transfer. Wide data transfer is negotiated separately, if implemented, and if the synchronous data transfer negotiation is successful. The initiator has one of three courses of action: 1) If it does not implement target mode, it will not respond to selection, and the target discovers that it may only operate in SCSI-2 mode with the initiator. 2) If it implements target mode and the nexus transfer phases it accepts the information packet and by so doing declares itself capable of handling the nexus transfer phases. 3) If it is an initiator which does not implement the nexus transfer phase, it shall signal ATN on the first assertion of REQ for the illegal phase and shall not assert the ACK signal. If ATN is asserted, the target controller disconnects allowing the bus to go to the BUS FREE phase. With the change to the BUS FREE phase, the initiator shall release its ATN signal. The target has detected that it is possible to operate with that initiator using only the SCSI-2 defined information transfer phases and shall not attempt to use the nexus transfer phases with that initiator until after a power-on reset, or a reset condition has been processed. The initiator detects an unexpected disconnect and reacts appropriately. See Section 5.1.1. 5.1.1. BUS FREE Phase The BUS FREE phase is used to indicate that no SCSI device is actively using the SCSI bus and that it is available. In some cases a target reverts to BUS FREE phase to indicate an error condition that it has no other way to handle. This is called as an unexpected disconnect. SCSI devices shall detect the BUS FREE phase after the SEL and BSY signals are both false for at least a bus settle delay. SCSI devices shall release all SCSI bus signals within a bus clear delay after the BSY and SEL signals become continuously false for a bus settle delay. If an SCSI device requires more than a bus settle delay to detect the BUS FREE phase then it shall release all SCSI bus signals within a bus clear delay minus the excess time to detect the BUS FREE phase. The total time to clear the SCSI bus shall not exceed a bus settle delay plus a bus clear delay. Initiators normally do not expect BUS FREE phase to begin, because of the target's release of the BSY signal, except after one of the following occurrences: (1) after a reset condition is detected. (2) after an ABORT message is successfully received by a target. (3) after a BUS DEVICE RESET message is successfully received by a target. (4) after a DISCONNECT message is successfully transmitted from a target (see 5.y.6) (5) after a COMMAND COMPLETE message is successfully transmitted from a target (see 5.y.5). (6) after a RELEASE RECOVERY message is successfully received by a target. (7) after an ABORT TAG message is successfully received by a target. (8) after a CLEAR QUEUE message is successfully received by a target. (9) after the transfer of an information packet in the nexus transfer phase. (10) after failure of a target to transfer an information packet using the NEXUS TRANSFER IN phase. The BUS FREE phase may also be entered after an unsuccessful selection or reselection, although in this case it is the release of the SEL signal rather than the release of the BSY signal that first establishes the BUS FREE phase. This is not treated as an unexpected disconnect. If an initiator detects the release of the BSY signal by the target at any other time, the target is indicating an error condition to the initiator. The target may perform this transition to the BUS FREE phase independent of the state of the ATN signal. The initiator shall manage this condition as an unsuccessful I/O process termination. The target may 1) terminate the I/O process by clearing all pending data and status information for the affected logical unit or target routine. 2) terminate the I/O process by clearing all pending data and prepare sense data that may be retrieved by a REQUEST SENSE command. When an initiator detects an unexpected disconnect, it is recommended that a REQUEST SENSE command be attempted to obtain any valid sense data that may be available. 5.1.2. ARBITRATION Phase The ARBITRATION phase allows one SCSI device to gain control of the SCSI bus so that it can initiate or resume an I/O process. The procedure for an SCSI device to obtain control of the SCSI bus is as follows: (1) The SCSI device shall first wait for the BUS FREE phase to occur. The BUS FREE phase is detected whenever both the BSY and SEL signals are simultaneously and continuously false for a minimum of a bus settle delay. IMPLEMENTORS NOTE: This bus settle delay is necessary because a transmission line phenomenon known as a "wired-OR glitch" may cause the BSY signal to briefly appear false, even though it is being driven true. (2) The SCSI device shall wait a minimum of a bus free delay after detection of the BUS FREE phase (i.e. after the BSY and SEL signals are both false for a bus settle delay) before driving any signal. (3) Following the bus free delay in Step (2), the SCSI device may arbitrate for the SCSI bus by asserting both the BSY signal and its own SCSI ID, however the SCSI device shall not arbitrate (i.e. assert the BSY signal and its SCSI ID) if more than a bus set delay has passed since the BUS FREE phase was last observed. IMPLEMENTORS NOTE: There is no maximum delay before asserting the BSY signal and the SCSI ID following the bus free delay in Step (2) as long as the bus remains in the BUS FREE phase. However, SCSI devices that delay longer than a bus settle delay plus a bus set delay from the time when the BSY and SEL signals first become false may fail to participate in arbitration when competing with faster SCSI devices. (4) After waiting at least an arbitration delay (measured from its assertion of the BSY signal) the SCSI device shall examine the DATA BUS. If a higher priority SCSI ID bit is true on the DATA BUS (DB(7) is the highest), then the SCSI device has lost the arbitration and the SCSI device may release its signals and return to Step (1). If no higher priority SCSI ID bit is true on the DATA BUS, then the SCSI device has won the arbitration and it shall assert the SEL signal. Any SCSI device other than the winner has lost the arbitration and shall release the BSY signal and its SCSI ID bit within a bus clear delay after the SEL signal becomes true. An SCSI device that loses arbitration may return to Step (1). IMPLEMENTORS NOTE: It is recommended that new implementations wait for the SEL signal to become true before releasing the BSY signal and SCSI ID bit when arbitration is lost. (5) The SCSI device that wins arbitration shall wait at least a bus clear delay plus a bus settle delay after asserting the SEL signal before changing any signals. NOTE: The SCSI ID bit is a single bit on the DATA BUS that corresponds to the SCSI device's unique SCSI address. All other DATA BUS bits shall be released by the SCSI device. Parity is not valid during the ARBITRATION phase. During the ARBITRATION phase, the data bus parity bits may be released or asserted, but shall not be actively driven false. 5.1.3. SELECTION Phase The SELECTION phase allows an initiator to select a target for the purpose of initiating some target function (e.g., READ or WRITE command). The SELECTION phase may also be used by an initiator to reconnect with a target after a disconnect. During the SELECTION phase the I/O signal is negated so that this phase can be distinguished from the RESELECTION phase. The SCSI device that won arbitration has both the BSY and SEL signals asserted and has delayed at least a bus clear delay plus a bus settle delay before ending the ARBITRATION phase. The SCSI device that won the arbitration becomes an initiator by not asserting the I/O signal. The initiator shall set the DATA BUS to a value which is the OR of its SCSI ID bit and the target's SCSI ID bit and it shall assert the ATN signal (indicating that a MESSAGE OUT phase is to follow the SELECTION phase). The initiator shall then wait at least two deskew delays and release the BSY signal. The initiator shall then wait at least a bus settle delay before looking for a response from the target. The target shall determine that it is selected when the SEL signal and its SCSI ID bit are true and the BSY and I/O signals are false for at least a bus settle delay. The selected target may examine the DATA BUS in order to determine the SCSI ID of the selecting initiator. The selected target shall then assert the BSY signal within a selection abort time of its most recent detection of being selected; this is required for correct operation of the selection time-out procedure. The target shall not respond to a selection if bad parity is detected. Also, if more than two SCSI ID bits are on the DATA BUS, the target shall not respond to selection. IMPLEMENTORS NOTE: If a target chooses to support the single initiator option of SCSI-1, it should not be an error to have only the target ID bit present during selection. In this case the target may respond as an SCSI-1 device. No less than two deskew delays after the initiator detects the BSY signal is true, it shall release the SEL signal and may change the DATA BUS. The target shall wait until the SEL signal is false before asserting the REQ signal to enter an information transfer phase. 5.1.3.1. SELECTION Time-out Procedure Two optional selection time-out procedures are specified for clearing the SCSI bus if the initiator waits a minimum of a selection time-out delay and there has been no BSY signal response from the target: (1) Optionally, the initiator shall assert the RST signal (see 5.2.2). (2) Optionally, the initiator shall continue asserting the SEL and ATN signals and shall release the DATA BUS. If the initiator has not detected the BSY signal to be true after at least a selection abort time plus two deskew delays, the initiator shall release the SEL and ATN signals allowing the SCSI bus to go to the BUS FREE phase. SCSI devices shall ensure that when responding to selection that the selection was still valid within a selection abort time of their assertion of the BSY signal. Failure to comply with this requirement could result in an improper selection (two targets connected to the same initiator, wrong target connected to an initiator, or a target connected to no initiator). 5.1.4. RESELECTION Phase RESELECTION is an optional phase that allows a target to reconnect to an initiator for the purpose of continuing some operation that was previously started by the initiator but was suspended by the target, (i.e., the target disconnected by allowing a BUS FREE phase to occur before the operation was complete). The RESELECTION phase is required to be supported in both the initiator and the target when the NEXUS TRANSFER phase is implemented. 5.1.4.1. RESELECTION Upon completing the ARBITRATION phase, the winning SCSI device has both the BSY and SEL signals asserted and has delayed at least a bus clear delay plus a bus settle delay. The winning SCSI device becomes a target by asserting the I/O signal. The winning SCSI device shall also set the DATA BUS to a value that is the logical OR of its SCSI ID bit and the initiator's SCSI ID bit. The target shall wait at least two deskew delays and release the BSY signal. The target shall then wait at least a bus settle delay before looking for a response from the initiator. The initiator shall determine that it is reselected when the SEL and I/O signals and its SCSI ID bit are true and the BSY signal is false for at least a bus settle delay. The reselected initiator may examine the DATA BUS in order to determine the SCSI ID of the target. The reselected initiator shall then assert the BSY signal within a selection abort time of its most recent detection of being reselected; this is required for correct operation of the time-out procedure. The initiator shall not respond to a RESELECTION phase if bad parity is detected. Also, the initiator shall not respond to a RESELECTION phase if other than two SCSI ID bits are on the DATA BUS. After the target detects the BSY signal is true, it shall also assert the BSY signal and wait at least two deskew delays and then release the SEL signal. The target may then change the I/O signal and the DATA BUS. After the reselected initiator detects the SEL signal is false, it shall release the BSY signal. The target shall continue asserting the BSY signal until it relinquishes the SCSI bus. NOTE: When the target is asserting the BSY signal, a transmission line phenomenon known as a "wired-OR glitch" may cause the BSY signal to appear false for up to a round-trip propagation delay following the release of the BSY signal by the initiator. This is the reason why the BUS FREE phase is recognized only after both the BSY and SEL signals are continuously false for a minimum of a bus settle delay. Cables longer than 25 meters should not be used even if the chosen driver, receiver, and cable provide adequate noise margins, because they increase the duration of the glitch and could cause SCSI devices to inadvertently detect the BUS FREE phase. 5.1.4.2. RESELECTION Time-out Procedure Two optional RESELECTION time-out procedures are specified for clearing the SCSI bus during a RESELECTION phase if the target waits a minimum of a selection time-out delay and there has been no BSY signal response from the initiator: (1) Optionally, the target shall assert the RST signal (see 5.2.2). (2) Optionally, the target shall continue asserting the SEL and I/O signals and shall release all DATA BUS signals. If the target has not detected the BSY signal to be true after at least a selection abort time plus two deskew delays, the target shall release the SEL and I/O signals allowing the SCSI bus to go to the BUS FREE phase. SCSI devices that respond to the RESELECTION phase shall ensure that the reselection was still valid within a selection abort time of their assertion of the BSY signal. Failure to comply with this requirement could result in an improper reselection (two initiators connected to the same target or the wrong initiator connected to a target). 5.1.5. Information Transfer Phases NOTE: The COMMAND, DATA, STATUS, MESSAGE, and NEXUS TRANSFER phases are all grouped together as the information transfer phases because they are all used to transfer data or control information via the DATA BUS. The actual content of the information is beyond the scope of this section. In SCSI-2, the MESSAGE, COMMAND, data phases, and STATUS phase were used to identify the type of data being transferred during a connection. The optional nexus transfer phases may be used for all transfers. If a nexus transfer phase is used at a connect, none of the other information transfer phases shall be used during any connection related to that I/O process. If the SCSI-2 phases are used at a connect, the nexus transfer phases shall not be used in any connection related to the I/O process. The C/D, I/O, and MSG signals are used to distinguish between the different information transfer phases (see Table 5-1). The target drives these three signals and therefore controls all changes from one phase to another. The initiator can request either a MESSAGE OUT phase or a NEXUS TRANSFER OUT phase by asserting the ATN signal, while the target can cause the BUS FREE phase by releasing the MSG, C/D, I/O, and BSY signals. The information transfer phases use one or more REQ/ACK handshakes to control the information transfer. Each REQ/ACK handshake allows the transfer of one byte of information on the A cable and up to 3 bytes of information on the B cable, or up to 2 bytes of information on the P cable. The data capable of being transferred on one handshake is further limited by the phase in which the transfer is attempted. During the information transfer phases the BSY signal shall remain true and the SEL signal shall remain false. Additionally, during the information transfer phases, the target shall continuously envelope the REQ/ACK handshake(s) with the C/D, I/O, and MSG signals in such a manner that these control signals are valid for a bus settle delay before the assertion of the REQ signal of the first handshake and remain valid until after the negation of the ACK signal at the end of the handshake of the last transfer of the phase. An information transfer phase is defined as ending when the C/D, I/O, or MSG signals change after the negation of the ACK signal. The time between the end of a phase and the assertion of the REQ signal beginning a new phase is undefined. After the negation of the ACK signal of the last transfer of an information transfer phase, the target may prepare for a new phase by asserting or negating the C/D, I/O, and MSG signals. These signals may be changed together or individually. They may be changed in any order and may be changed more than once. It is desirable that each line change only once. A new phase does not begin until the REQ signal is asserted for the first byte of the new phase. An initiator is allowed to anticipate a new phase based on the previous phase, the expected new phase, and early information provided by changes in the C/D, I/O, and MSG signals. However, the actual phase is not valid until the REQ signal is asserted at the beginning of the next phase. Two or more phases of the same type may be processed back-to-back provided that there is a pause between the data bytes with both REQ and ACK false and the C/D, I/O, and MSG signals are changed and then set to the same phase as the previous phase. .kp on Table 5-1: Information Transfer Phases ============================================================================== Signal ----------- MSG C/D I/O Phase Name Direction Of Transfer Comment ------------------------------------------------------------------------------ 0 0 0 DATA OUT Initiator to target \ Data 0 0 1 DATA IN Initiator from target / Phase 0 1 0 COMMAND Initiator to target 0 1 1 STATUS Initiator from target 1 0 0 * NEXUS TRANSFER OUT Initiator to target \ Nexus 1 0 1 * NEXUS TRANSFER IN Initiator from target / Transfer Phase 1 1 0 MESSAGE OUT Initiator to target Message 1 1 1 MESSAGE IN Initiator from target Phase ============================================================================== Key: 0 = False, 1 = True, * = Optional. .kp off 5.1.5.1. Asynchronous Information Transfer The target shall control the direction of information transfer by means of the I/O signal. When the I/O signal is true, information shall be transferred from the target to the initiator. When the I/O signal is false, information shall be transferred from the initiator to the target. If the I/O signal is true (transfer to the initiator), the target shall first drive the DB(7-0,P) signals to their desired values, delay at least one deskew delay plus a cable skew delay, then assert the REQ signal. The DB(7- 0,P) signals shall remain valid until the ACK signal is true at the target. The initiator shall read the DB(7-0,P) signals after the REQ signal is true, then indicate its acceptance of the data by asserting the ACK signal. When the ACK signal becomes true at the target, the target may change or release the DB(7-0,P) signals and shall negate the REQ signal. After the REQ signal is false the initiator shall then negate the ACK signal. After the ACK signal is false the target may continue the transfer by driving the DB(7-0,P) signals and asserting the REQ signal, as described above. If the I/O signal is false (transfer to the target) the target shall request information by asserting the REQ signal. The initiator shall drive the DB(7- 0,P) signals to their desired values, delay at least one deskew delay plus a cable skew delay and assert the ACK signal. The initiator shall continue to drive the DB(7-0,P) signals until the REQ signal is false. When the ACK signal becomes true at the target, the target shall read the DB(7-0,P), signals then negate the REQ signal. When the REQ signal becomes false at the initiator, the initiator may change or release the DB(7-0,P) signals and shall negate the ACK signal. The target may continue the transfer by asserting the REQ signal, as described above. 5.1.5.2. Synchronous Data Transfer Synchronous data transfer is optional and is only used in data and nexus transfer phases. If the nexus transfer phase is implemented, synchronous data transfer shall be implemented in both the target and the initiator. It shall be used in these phases if a synchronous data transfer agreement has been established (see 5.y.21). The agreement specifies the REQ/ACK offset and the minimum transfer period. The REQ/ACK offset specifies the maximum number of REQ pulses that can be sent by the target in advance of the number of ACK pulses received from the initiator, establishing a pacing mechanism. If the number of REQ pulses exceeds the number of ACK pulses by the REQ/ACK offset, the target shall not assert the REQ signal until after the leading edge of the next ACK pulse is received. A requirement for successful completion of the data phase is that the number of ACK and REQ pulses be equal. The target shall assert the REQ signal for a minimum of an assertion period. The target shall then wait at least the greater of a transfer period from the last transition of the REQ signal to true or a minimum of a negation period from the last transition of the REQ signal to false before again asserting the REQ signal. The initiator shall send one pulse on the ACK signal for each REQ pulse received. The ACK signal may be asserted as soon as the leading edge of the corresponding REQ pulse has been received. The initiator shall assert the ACK signal for a minimum of an assertion period. The initiator shall wait at least the greater of a transfer period from the last transition of the ACK signal to true or for a minimum of a negation period from the last transition of the ACK signal to false before asserting the ACK signal. If the I/O signal is true (transfer to the initiator), the target shall first drive the DB(7-0,P) signals to their desired values, wait at least one deskew delay plus one cable skew delay, then assert the REQ signals. The DB(7-0,P) signals shall be held valid for a minimum of one deskew delay plus one cable skew delay plus one hold time after the assertion of the REQ signal. The target shall assert the REQ signal for a minimum of an assertion period. The target may then negate the REQ signal and change or release the DB(7-0,P) signals. The initiator shall read the value on the DB(7-0,P) signals within one hold time of the transition of the REQ signal to true. The initiator shall then respond with an ACK pulse. If the I/O signal is false (transfer to the target), the initiator shall transfer one byte for each REQ pulse received. After receiving the leading edge of a REQ pulse, the initiator shall first drive the DB(7-0,P) signals to their desired values, delay at least one deskew delay plus one cable skew delay, then assert the ACK signal. The initiator shall hold the DB(7-0,P) signals valid for at least one deskew delay plus one cable skew delay plus one hold time after the assertion of the ACK signal. The initiator shall assert the ACK signal for a minimum of an assertion period. The initiator may then negate the ACK signal and may change or release the DB(7-0,P) signals. The target shall read the value of the DB(7-0,P) signals within one hold time of the transition of the ACK signal to true. IMPLEMENTORS NOTE: The description in SCSI-1 allowed some implementors to presume that the leading edge of the first REQ pulse beyond the REQ/ACK offset agreement would not occur until after the trailing edge of the last ACK pulse within the agreement. Devices implemented with this understanding may be subject to data destruction when in synchronous data transfer mode with devices that issue the leading edge of the next REQ pulse, at the boundary of the agreement, as soon as the leading edge of the last ACK pulse within the agreement is received. Implementors using devices of the former type in initiator designs may insure data integrity by restricting the synchronous offset agreement to values smaller than the maximum nominally offered by their device. 5.1.5.3. Wide Data Transfer Wide data transfer is optional and may be used in the data phase and the nexus transfer phase only if a nonzero wide data transfer agreement is in effect (see WIDE DATA TRANSFER REQUEST message, 5.y.23). The messages determine the use of wide mode by both SCSI devices and establish a data path width to be used during the DATA phase. Wide data transfers of 16- or 32-bits may be established. Although not mandatory, it is recommended that targets and initiators that support 32-bit wide transfers also support 16-bit wide transfers as well. All SCSI devices shall support 8-bit data transfers. During 16-bit wide data transfers, the first logical data byte for each data phase shall be transferred across the DB(7-0,P) signals on the A cable and the second logical data byte shall be transferred across the DB(15-8,P1) signals on the B cable. Subsequent pairs of data bytes are likewise transferred in parallel across the A and B cables (see Figure 5-1). During 32-bit wide data transfers, the first logical data byte for each data phase shall be transferred across the DB(7-0,P) signals on the A cable and the second, third, and fourth logical data bytes shall be transferred across the DB(15-8,P1), DB(23-16,P2), and DB(31-24,P3) signals, respectively, on the B cable. Subsequent groups of four data bytes are likewise transferred in parallel across the A and B cables (see Figure 5-1). When transferring bytes W, X, Y and Z across the three bus widths, they are transferred as shown below: .kp on Hand- 8-bit 16-bit 32-bit shake # A Cable B Cable A Cable <------ B Cable ------> A Cable +-------+ +---------------+ +------------------------------- 1 | W | | X | W | | Z | Y | X | W | |-------| |-------|-------| +------------------------------- 2 | X | | Z | Y | 31...24 23...16 15....8 7....0 |-------| +---------------+ 3 | Y | 15....8 7.....0 Bit Number |-------| 4 | Z | Bit Number +-------+ 7.....0 Bit Number NOTE: This figure does not represent how these bytes are stored in the initiator's memory, which may be different. Figure 5-1: Wide SCSI Byte Ordering .kp off If the last data byte transferred for a command does not fall on the DB(15- 8,P1) signals for a 16-bit wide transfer or the DB(31-24,P3) signals for a 32- bit wide transfer, then the values of the remaining higher-numbered bits are undefined. However, parity bits for these undefined bytes shall be valid for whatever data is placed on the bus. To ensure proper data integrity, certain sequence requirements shall be met between the REQ/ACK handshakes on the A cable and the REQB/ACKB handshakes on the B cable: (1) The REQB and ACKB signals shall only be asserted during data phases while a nonzero wide data transfer agreement is in effect. These signals shall not be asserted during other phases. (2) The same information transfer mode (asynchronous or synchronous) shall be used for both the A cable and the B cable. If synchronous data transfer mode is in effect, the same REQ/ACK offset and transfer period shall be used for both cables. (3) The information transfer procedures defined in 5.1.5.1 and 5.1.5.2 for the A cable (the REQ, ACK, and DB(7-0,P) signals) shall also apply to the B cable (the REQB, ACKB, and DB(31-8,P1,P2,P3) signals). The only means available for a target to manage the timing relationship between the signals on the two cables is its management of the REQ and REQB signals. Similarly, the only means for the initiator to manage the timing between the two cables is its management of the ACK and ACKB signals. (4) The target shall ensure that the number of REQ/ACK handshakes and the number of REQB/ACKB handshakes in a data phase are equal before it changes to another phase. The target shall not change the phase until the ACK and ACKB signals have both become false for the last REQ/ACK handshake and the last REQB/ACKB handshake. IMPLEMENTORS NOTE: If any violations of these rules are detected by the target, the target may attempt to end the data phase and return CHECK CONDITION status. If it is impossible to correctly terminate the data phase, the target may abnormally terminate the I/O process by an unexpected disconnect. If any violations of these rules are detected by the initiator, the initiator may attempt to send an INITIATOR DETECTED ERROR message to the target. If the initiator is unable to terminate the I/O process normally, it may generate the reset condition. 5.1.6. COMMAND Phase The COMMAND phase allows the target to request command information from the initiator. Synchronous data transfer and wide data transfer shall not be used during this phase. The target shall assert the C/D signal and negate the I/O and MSG signals during the REQ/ACK handshake(s) of this phase. 5.1.7. Data Phase The data phase is a term that encompasses both the DATA IN phase and the DATA OUT phase. 5.1.7.1. DATA IN Phase The DATA IN phase allows the target to request that data be sent to the initiator from the target. Synchronous data transfer and wide data transfer may be used during this phase. The target shall assert the I/O signal and negate the C/D and MSG signals during the REQ/ACK handshake(s) of this phase. 5.1.7.2. DATA OUT Phase The DATA OUT phase allows the target to request that data be sent from the initiator to the target. Synchronous data transfer and wide data transfer may be used during this phase. The target shall negate the C/D, I/O, and MSG signals during the REQ/ACK handshake(s) of this phase. 5.1.8. STATUS Phase The STATUS phase allows the target to request that status information be sent from the target to the initiator. Synchronous data transfer and wide data transfer shall not be used during this phase. The target shall assert the C/D and I/O signals and negate the MSG signal during the REQ/ACK handshake of this phase. 5.1.9. Message Phase The message phase is a term that references either a MESSAGE IN, or a MESSAGE OUT phase. Multiple messages may be sent during either phase. The first byte transferred in either of these phases shall be either a single-byte message or the first byte of a multiple-byte message. For multiple-byte messages, all bytes of the message shall be transferred within a single message phase. An alternate procedure for handling message parity errors is outlined in Section 5.y.13. The alternate procedure is symmetrical for initiators and targets. 5.1.9.1. MESSAGE IN Phase The MESSAGE IN phase allows the target to request that message(s) be sent to the initiator from the target. Synchronous data transfer and wide data transfer shall not be used during this phase. The target shall assert the C/D, I/O, and MSG signals during the REQ/ACK handshake(s) of this phase. If the initiator detects one or more parity error(s) on the message byte(s) received, it may indicate its desire to retry the message(s) by asserting the the ATN signal, causing the target to transfer a MESSAGE PARITY ERROR message from the initiator in a MESSAGE OUT phase. The target, upon detecting this message, shall resend all of the previous message byte(s) in the same order as previously sent during this phase. The initiator may process a message as received as long as no parity error is detected in any byte of the message and may ignore all remaining messages sent after a parity error is detected. When a sequence of messages is resent by a target because of an initiator detected parity error, the initiator shall not reprocess any message which it has previously processed. If the initiator receives all of the message byte(s) successfully (i.e., no parity errors), it shall indicate that it does not wish to retry by not asserting ATN. The initiator may also indicate that it has successfully received and processed the message byte(s) by asserting the ATN signal and transferring any other message(s) (e.g., NO OPERATION). 5.1.9.2. MESSAGE OUT Phase The MESSAGE OUT phase allows the target to request that message(s) be sent from the initiator to the target. The target invokes this phase in response to the attention condition created by the initiator when not using the nexus transfer phases (see 5.2.1). Synchronous data transfer and wide data transfer shall not be used during this phase. The target shall assert the C/D and MSG signals and negate the I/O signal during the REQ/ACK handshake(s) of this phase. The target shall handshake byte(s) in this phase until the ATN signal is negated, except when rejecting a message. If the target detects one or more parity error(s) on the message byte(s) received, it may indicate its desire to retry the message(s) by asserting the REQ signal after detecting the ATN signal has gone false and prior to changing to any other phase. The initiator, upon detecting this condition, shall resend all of the previous message byte(s) in the same order as previously sent during this phase. When resending more than one message byte, the initiator shall assert the ATN signal at least two deskew delays prior to asserting the ACK signal on the first byte and shall maintain the ATN signal asserted until the last byte is sent as described in 5.2.1. The target may process messages as received as long as no parity error is detected in any byte of the message and shall ignore all remaining messages sent under one ATN condition after a parity error is detected. When a sequence of messages is resent by an initiator because of a target detected parity error, the target shall not reprocess any message which it has previously processed. If the target receives all of the message byte(s) successfully (i.e., no parity errors), it shall indicate that it does not wish to retry by changing to any information transfer phase other than the MESSAGE OUT phase and transfer at least one byte. The target may also indicate that it has successfully processed the message byte(s) by changing to the BUS FREE phase (e.g., ABORT or BUS DEVICE RESET messages). 5.1.10. Nexus Transfer Phase The nexus transfer phase is a term that encompasses the NEXUS TRANSFER IN phase and the NEXUS TRANSFER OUT phase. 5.1.10.1. NEXUS TRANSFER IN Phase The NEXUS TRANSFER IN phase allows the target to request that information packet(s) be sent to the initiator from the target. This phase may be used instead of the MESSAGE IN, STATUS, and DATA IN phases when the data are formed into information packets. The processing of messages is altered using this phase. Synchronous data transfer and wide data transfer may be used during this phase. The target shall assert the I/O, and MSG signals and negate the C/D signal during the REQ/ACK handshake(s) of this phase. 5.1.10.1. NEXUS TRANSFER OUT Phase The NEXUS TRANSFER OUT phase allows the target to request that information packet(s) be sent from the initiator to the target. This phase may be used instead of the MESSAGE OUT, COMMAND, and DATA OUT phases when the data are formed into information packets. The processing of messages is altered using this phase. Synchronous data transfer and wide data transfer may be used during this phase. The target shall assert the MSG signal and negate the C/D and I/O signals during the REQ/ACK handshake(s) of this phase. 5.1.11. Signal Restrictions Between Phases When the SCSI bus is between two information transfer phases, the following restrictions shall apply to the SCSI bus signals: (1) The BSY, SEL, REQ, REQB, ACK and ACKB signals shall not change. (2) The C/D, I/O, MSG, and DATA BUS signals may change. When switching the DATA BUS direction from out (initiator driving) to in (target driving), the target shall delay driving the DATA BUS by at least a data release delay plus a bus settle delay after asserting the I/O signal and the initiator shall release the DATA BUS no later than a data release delay after the transition of the I/O signal to true. When switching the DATA BUS direction from in (target driving) to out (initiator driving), the target shall release the DATA BUS no later than a deskew delay after negating the I/O signal. (3) The ATN and RST signals may change as defined under the descriptions for the attention condition (see 5.2.1) and reset condition (see 5.2.2). 5.2. Parallel Interface SCSI Bus Conditions The SCSI bus has two asynchronous conditions; the attention condition and the reset condition. These conditions cause the SCSI device to perform certain actions and can alter the phase sequence. Furthermore, an SCSI device may not all be powered on at the same time. This standard does not address power sequencing issues. However, each SCSI device, as it is powered on, should perform appropriate internal reset operations and internal test operations. It is recommended that following a power-on to selection time after power is applied, SCSI targets be able to respond with appropriate status and sense data to the TEST UNIT READY, INQUIRY, and REQUEST SENSE commands. 5.2.1. Attention Condition When not using the nexus transfer phase, the attention condition allows an initiator to inform a target during a connection that the initiator has a message ready. The target may get this message by performing a MESSAGE OUT phase. When using the nexus transfer phase, the attention condition allows the initiator to inform the target during a connection that it has an information packet to send. The target gets this information packet by performing a NEXUS TRANSFER OUT phase. When not using the nexus transfer phase, the initiator creates the attention condition by asserting ATN at any time except during the ARBITRATION or BUS FREE phases. When using the nexus transfer phase, the initiator creates the attention condition by asserting ATN at any time except during the BUS FREE phase or during the transfer of the first byte of each information transfer packet when using the NEXUS TRANSFER IN phase. The use of ATN for the first byte of a NEXUS TRANSFER IN phase is to inform a target that the initiator does not implement the nexus transfer phases. That is, the initiator has detected an illegal phase. 5.2.1.1. ATN Signal and the Message Phase The initiator shall assert the ATN signal at least two deskew delays before negating the ACK signal for the last byte transferred in a bus phase for the attention condition to be honored before transition to a new bus phase. Asserting the ATN signal later might not be honored until a later bus phase and then may not result in the expected action. The initiator shall negate the ATN signal at least two deskew delays before asserting the ACK signal while transferring the last byte of the messages indicated with a "Yes" in Table 5-2 under the column heading "Negate ATN Before Last ACK." If the target detects that the initiator failed to meet this requirement, then the target shall go to BUS FREE phase (see unexpected disconnect, 5.1.1). A target shall respond with MESSAGE OUT phase as follows: (1) If the ATN signal becomes true during a COMMAND phase, the target shall enter MESSAGE OUT phase after transferring part or all of the command descriptor block bytes. (2) If the ATN signal becomes true during a DATA phase, the target shall enter MESSAGE OUT phase at the target's earliest convenience (often, but not necessarily on a logical block boundary). The initiator shall continue REQ/ACK handshakes with valid data until it detects the phase change. (3) If the ATN signal becomes true during a STATUS phase, the target shall enter MESSAGE OUT phase after the status byte has been acknowledged by the initiator. (4) If the ATN signal becomes true during a SELECTION phase and before the initiator releases the BSY signal, the target shall enter MESSAGE OUT phase immediately after that SELECTION phase. (5) If the ATN signal becomes true during a RESELECTION phase, the target shall enter MESSAGE OUT phase after the target has sent its IDENTIFY message for that RESELECTION phase. The initiator shall keep the ATN signal asserted if more than one byte is to be transferred. The initiator may negate the ATN signal at any time except it shall not negate the ATN signal while the ACK signal is asserted during a MESSAGE OUT phase. Normally, the initiator negates the ATN signal while the REQ signal is true and the ACK signal is false during the last REQ/ACK handshake of the MESSAGE OUT phase. 5.2.1.2. ATN Signal and the Nexus Transfer Phase The initiator shall assert the ATN signal at least two deskew delays before negating the ACK signal for the last byte transferred in a bus phase for the attention condition to be honored before transition to the BUS FREE phase or a new nexus transfer phase. Asserting the ATN signal later might not be honored until a later information packet in the same or a new connection and then may not result in the expected action. The initiator shall not assert the ATN signal on the first byte of a NEXUS TRANSFER IN phase, except to indicate that it does not support the nexus transfer phases. A target shall respond with NEXUS TRANSFER OUT phase as follows: (1) If the ATN signal becomes true during a DATA phase, the target shall enter NEXUS TRANSFER OUT phase at the target's earliest convenience (often, but not necessarily on a logical block boundary). The initiator shall continue REQ/ACK handshakes with valid data until it detects the phase change. (2) If the ATN signal becomes true during a nexus transfer phase, the target shall enter NEXUS TRANSFER OUT phase at the target's earliest convenience (often, but not necessarily on a logical block boundary). The initiator shall continue REQ/ACK handshakes with valid data until it detects the phase change. (3) If the ATN signal becomes true during a SELECTION phase and before the initiator releases the BSY signal, the target shall enter NEXUS TRANSFER OUT phase immediately after that SELECTION phase. (4) If the ATN signal becomes true during a RESELECTION phase, the target shall enter NEXUS TRANSFER OUT phase immediately following that RESELECTION phase. 5.2.2. Reset Condition The reset condition is used to immediately clear all SCSI devices from the bus. This condition shall take precedence over all other phases and conditions. Any SCSI device may create the reset condition by asserting the RST signal for a minimum of a reset hold time. During the reset condition, the state of all SCSI bus signals other than the RST signal is not defined. All SCSI devices shall release all SCSI bus signals (except the RST signal) within a bus clear delay of the transition of the RST signal to true. The BUS FREE phase always follows the reset condition. The effect of the reset condition on I/O processes which have not completed, SCSI device reservations, and SCSI device operating modes is determined by whether the SCSI device has implemented the hard reset alternative or the soft reset alternative (one of which shall be implemented) as defined in 5.2.2.1 and 5.2.2.2. The hard and soft reset alternatives are mutually exclusive within a system. A facility for targets to report which reset alternative is implemented is provided in the SftRe bit of the INQUIRY data (7.2.5). IMPLEMENTORS NOTE: Environmental conditions (e.g., static discharge) may generate brief glitches on the RST signal. It is recommended that SCSI devices not react to these glitches. The manner of rejecting glitches is vendor specific. The bus clear delay following a RST signal transition to true is measured from the original transition of the RST signal, not from the time that the signal has been confirmed. This limits the time to confirm the RST signal to a maximum of a bus clear delay. 5.2.2.1. Hard Reset Alternative NOTE: The hard reset alternative is left in SCSI-3 for backward compatibility to SCSI-2. It is recommended that all SCSI-3 devices implement the soft reset alternative. Soft reset is mutually exclusive with the hard reset alternative in a logical system in SCSI-2. SCSI devices that implement the hard reset alternative, upon detection of the reset condition, shall: (1) Clear all I/O processes including queued I/O processes. (2) Release all SCSI device reservations. (3) Return any SCSI device operating modes to their appropriate initial conditions, similar to those conditions that would be found after a normal power-on reset. MODE SELECT conditions shall be restored to their last saved values if saved values have been established. MODE SELECT conditions for which no values have been saved shall be returned to their default values. (4) Unit attention condition shall be set (See 6.9). It is recommended that following a reset to selection time after a hard reset condition ends, SCSI targets be able to respond with appropriate status and sense data to the TEST UNIT READY, INQUIRY, and REQUEST SENSE commands. 5.2.2.2. Soft Reset Alternative SCSI devices that implement the soft reset alternative, upon detection of the reset condition, shall: (1) Attempt to complete any I/O processes which have not completed and that were fully identified (2) Preserve all SCSI device reservations (3) Preserve any SCSI device operating modes (MODE SELECT, PREVENT/ALLOW MEDIUM REMOVAL commands, etc.) (4) Preserve all the information required to continue normal dispatching of I/O processes queued prior to the reset condition. The soft reset alternative allows an initiator to reset the SCSI bus with minimum disruption to the operation of other initiators in a multiple initiator system. To ensure proper operation the following conditions shall be met: (1) An initiator shall not consider an I/O process to be fully identified until a) when not using the nexus transfer phase, the IDENTIFY message (and queue tag message, if any) is sent to the target and the target responds by changing to any other information transfer phase and requests that at least one byte be transferred. b) when using the nexus transfer phase, during the next connection with the target for the same I/O process, the target provides no response in the information packet to indicate an error in the last information packet received. (2) A target shall consider an I/O process to be fully identified when a) when not using the nexus transfer phase, it successfully receives the IDENTIFY message and any queue tag message and the initiator negates the ATN signal. b) when using the nexus transfer phase, during the next connection with the same initiator for the same I/O process, the target reports no error in the last information packet received. (3) If an initiator attempts a connection with a logical unit for which there already is an active I/O process with the same queue tag (if any) for the same initiator, the target shall clear the original I/O process and perform the new I/O process. (4) If a target attempts a reconnection with an initiator to continue an I/O process for which the initiator has no saved pointers, the initiator shall abort that unknown I/O process by sending the ABORT or ABORT TAG message, depending on whether the I/O process is a tagged I/O process. When using the nexus transfer phase, the message is contained in an information packet. (5) An initiator shall consider an I/O process to be completed a) when not using the nexus transfer phase, it negates ACK for a successfully received COMMAND COMPLETE message. b) when using the nexus transfer phase, no error is detected in the transfer of an information packet containing the COMMAND COMPLETE message. (6) A target shall consider an I/O process to be completed a) when not using the nexus transfer phase, it detects the transition of ACK to false for the COMMAND COMPLETE message with the ATN signal false. b) when using the nexus transfer phase, it detects the end of the information packet transfer with the ATN signal false. (7) a) When not using the nexus transfer phase, an initiator shall not negate the ACK signal for the SAVE DATA POINTER message until it has actually saved the data pointer for the I/O process. b) When using the nexus transfer phase, an initiator shall not negate the ACK signal for an information packet until it has actually saved the active pointers for the current I/O process. The saved pointers must be updated before the initiator responds to another nexus transfer phase for the same I/O process. (8) a) When not using the nexus transfer phase, a target shall consider the data pointer saved when it detects the transition of the ACK signal to false for the SAVE DATA POINTER message with the ATN signal false. b) When using the nexus transfer phase, a target shall consider the data pointer saved when it detects the transition of the ACK signal to false for each information packet. (9) a) When not using the nexus transfer phase, if the reset condition occurs between the time that the target asserts the REQ signal for the SAVE DATA POINTER message and it detects the transition of the ACK signal to false, the target shall terminate the I/O process with CHECK CONDITION status. The target shall set the sense key to ABORTED COMMAND. This is necessary because the target cannot determine whether the data pointer has actually been saved. b) When using the nexus transfer phase, if the reset condition occurs during the transfer of an information packet, the target shall terminate the I/O process with CHECK CONDITION status. The target shall set the sense key to ABORTED COMMAND. This is necessary because the target cannot determine whether the data pointer has actually been saved. NOTE: If the ATN signal is true in conditions (6) or (8), the target would normally switch to MESSAGE OUT phase or NEXUS TRANSFER OUT phase and attempt to transfer a message byte or an information packet. If the reset condition occurs before the target successfully receives the message, it may assume that the initiator has not successfully received the COMMAND COMPLETE message or the SAVE DATA POINTER message. In the case of COMMAND COMPLETE message, the target may reselect the initiator and attempt to send the COMMAND COMPLETE message again. In the case of the SAVE DATA POINTER message, the target may reselect the initiator and terminate the I/O process as described in condition (9). 5.3. Parallel Interface SCSI Bus Phase Sequences The order in which phases are used on the SCSI bus follows a prescribed sequence. The reset condition can abort any phase, except a BUS FREE phase, and is always followed by the BUS FREE phase. Also any other phase can be followed by the BUS FREE phase but many such instances are error conditions (see unexpected disconnect, 5.1.1). If the bus is not in the BUS FREE phase after the reset condition, then further operation with the SCSI bus is impossible. Another reset may be attempted. The additional allowable sequences shall be as shown in Figure 5-2. The normal progression is from the BUS FREE phase to ARBITRATION, from ARBITRATION to SELECTION or RESELECTION, and from SELECTION or RESELECTION to one or more of the information transfer phases. When not using the nexus transfer phase, the final information transfer phase is normally the MESSAGE IN phase where a DISCONNECT, or COMMAND COMPLETE message is transferred, followed by the BUS FREE phase. When using the nexus transfer phase, each phase is followed by a BUS FREE phase or another execution of the nexus transfer phase. .kp on +---------------+ +--| NEXUS |<-+ +---------------------+ +->| TRANSFER | | | | Reset or | | IN or OUT |<-+----+---+ +--------V------+ protocol | +---------------+ | | | +----> |------+ error | | | | |+---> MESSAGE OUT |---+ | | V | | | || +-> | | | | +<--------------------+----+---+---++-+-| |--+| | | | | or | | || | +----A----------+ || | | | +---------------+ | || | +--------V------+ || | | | ------| | | || | | | || | | | | | SELECTION | | ||++-> COMMAND |--++-+| | | | | | | |||| | |-+|| || | | | | | | |||| | | ||| || | | | +-------A-------+ | |||| +---------------+ ||| || +--V----V----V--+ +---------------+ | |||| +--------V------+ ||| || | | | | | ||+--| | ||| || | BUS FREE |---> ARBITRATION | | |||+-> DATA IN or <-+++-++ | | | | | |||| | DATA OUT | ||| | | | | | | |||| | |-++++| +-------A----A--+ +---------------+ | |||| +---------------+ ||||| | | +-------V-------+ | |||| +--------V------+ ||||| | | | | | |||| | | ||||| | +------| RESELECTION | | |+++-| STATUS <-+|||| | | | | | || | | |||| | | | | | || | <--+||| | +---------------+ | | || +----A----------+ ||| | | | | | || +--------V------+ ||| | | or | | | |+-| <---+|| | | +-----+ | +--| MESSAGE IN <----+| | | +----| | | | | | <-----+ | | +--A------------+ | | | | | +----------------------+ | +-------------------------------------------------+ The word "or" in the figure indicates a mutually exclusive choice of phase sets during a connection. Figure 5-2: Phase Sequences .kp off 5.4. Parallel Interface SCSI Pointers Consider the system shown in Figure 5-3 in which a host system and a target controller communicate on the SCSI bus in order to execute an I/O process. .kp on ------------------------- ------------------------- | Function | | Initiator|-----------------| Target | | Function | | Origin | | SCSI Bus | SCSI BUS | SCSI Bus | | Execution| | | | Control |-----------------| Control | | | ------------------------- ------------------------- Initiator Target Figure 5-3: Simplified SCSI System .kp off The SCSI architecture provides for a set of three pointers in the initiator for each active I/O process, called the saved pointers. The set of three pointers consist of one for the command, one for the data, and one for the status. The saved pointers are a resource of the host system and may reside in the initiator when multiple port operations are not being performed or they may reside in an area common to each initiator in the path group where the connect was made for an I/O process. When multiple path operations are being performed during an I/O process, the saved pointers shall be in the common area. When multiple path operations are not implemented, are suspended, or the path group contains only one path, the saved pointers may reside in the initiator where the the connect for the I/O process was made. When an active I/O process becomes the current I/O process, its three saved pointers are automatically copied by the initiator into the initiator's set of three active pointers. There is only one set of active pointers in each initiator. The active pointers point to the next command, data, or status byte to be transferred between the initiator and the target for the current I/O process. The active pointers reside in the initiator. When the nexus transfer phase is used for an I/O process, only the data pointer is actively used since the other pointers are related to the command and status phases which are not used. The command and status pointer are managed by the initiator to keep track of the progress of an I/O process, but they are not useful in information transfers. The saved command pointer always points to the start of the current command descriptor block (see 6.2) for each active I/O process. The current command is defined as the command of the I/O process executing in the target controller. With the queued commands, this pointer only has meaning, for operation of the SCSI bus, during the connection in which the command descriptor block(s) is transferred using the COMMAND phase. With the nexus transfer phase, the command pointer has no meaning for the operation of the SCSI bus. The saved status pointer always points to the start of the status area for the current command of each active I/O process. The status pointer has no meaning for the operation of the SCSI bus when using the nexus transfer phase. The status pointer only has meaning for the operation of the SCSI bus when the STATUS phase is used. The initiator shall update the pointer as each status is transferred for use by the host system. The saved data pointer points to the start of the data area until the target sends a SAVE DATA POINTER message (see 5.y.20) for the current command of the current I/O process using the message phase or until disconnect in the nexus transfer phase and a data interface logical element was contained in the information packet. For either of these conditions, the data pointer is advanced to the next byte to be transferred for the current command of the I/O process during a subsequent data phase or nexus transfer phase. When using the message phase, to transfer a SAVE DATA POINTER message, the initiator stores the value of the active data pointer into the saved data pointer for the current I/O process. The target may restore the active pointers to the saved pointer values for the current I/O process by sending a RESTORE POINTERS message (see 5.y.19) to the initiator. The initiator then copies the set of saved pointers into the set of active pointers. When a target disconnects from the bus, only the set of saved pointers for the active I/O process are retained. The set of active pointers is restored from the set of saved pointers automatically upon reconnection which changes an active I/O process to the current I/O process. No RESTORE POINTERS message needs to be sent from the target to cause the pointers to be restored after RESELECTION. When using the nexus transfer phase, the initiator stores the value of the active data pointer into the saved data pointer for the current I/O process at the end of each nexus transfer phase or at disconnect. The correct saved pointers are automatically restored at the beginning of each new nexus transfer phase. The target may modify the active data pointer by sending a MODIFY DATA POINTER message (see 5.y.15) to the initiator as part of an information packet. The initiator then adjusts the data pointer in the set of active pointers. When a target disconnects or changes phases, only the set of saved pointers, copied from the active pointers for the active I/O process, is retained. The set of active pointers is restored from the set of saved pointers automatically upon reconnection, which changes an active I/O process to the current I/O process. The data pointer value may be modified by the target before the I/O process ends and, therefore, it should not be used to test for actual transfer length. 5.5. Serial Interface SCSI Bus Phases The SCSI architecture includes two distinct phases: BUS FREE phase NEXUS TRANSFER phase The SCSI bus, as determined at a SCSI port, can never be in more than one phase at any given time. Since there is no direct signal protocol exchange between SCSI device ports, traditional signal protocols are not applicable, and the nexus and connection concepts of the parallel interface must be modified. An active serial interface consists of a continuous stream of encoded bytes transmitted along one conductor between a source and a destination. Since there are two conductors for each SCSI device port, the other conductor is transmitting a continuous stream of encoded byte values from the destination to the source. The receiving device port may not be aware that it is about to receive an information packet. The sending SCSI device port may not be aware of the present state of the destination SCSI device port. For point-to-point implementations without switches, the source has complete control of when an information packet is placed into this stream of encoded bytes. The destination also has complete control of when an information packet is placed into the stream of encoded bytes on the reverse conductor. All switches, including string switches, control the point when an information packet is placed into the stream of encoded byte on one of its send conductors. The switch must first detect the BUS FREE phase for the appropriate conductor. When the BUS FREE phase is detected, the switch may then place a pending information packet into the send conductor encoded byte stream of the appropriate SCSI bus. Because of the two independent conductors in the serial interface for an SCSI device port, the discussions below apply independently to each conductor. For each information packet successfully received, the receiving SCSI port shall acknowledge receipt by sending an acknowledge information packet on the reverse conductor. This acknowledgement is normally transmitted by the SCSI port hardware. For each information packet received which contains a logical error, but which is otherwise received error free, the receiving SCSI port shall send an acknowledge with error information packet on the reverse conductor. The receiving SCSI port shall not process this information packet further and shall not retain it. This acknowledgement with error is normally transmitted by the SCSI port hardware. For each information packet received with a physical error, such as a CRC error, the receiving SCSI port shall not acknowledge receipt of the information packet and shall neither process the information packet further nor retain it. 5.5.1. BUS FREE Phase The BUS FREE phase is used to indicate that no SCSI device is actively using the SCSI bus and that it is available. SCSI devices shall detect the BUS FREE phase when the idle encoded byte character has been detected for at least xx bytes. SCSI ports normally do not expect BUS FREE phase to begin except after one of the following occurrences: (1) after the transfer of a complete information packet in the nexus transfer phase. If a receiving SCSI port detects the BUS FREE phase at any other time, the sending SCSI port may have no idea that an error has occurred in the transmission of the information packet. the receiving SCSI port. The information packet is not acknowledged. Upon detecting the missing information packet, the sending SCSI port shall manage this condition as an unsuccessful information packet transfer. The sending SCSI port: 1) may attempt to retransmit the information packet in error some sending SCSI port determined number of retries. 2) if it is operating in target mode for the I/O process, shall terminate the I/O process after the specified number of retries by clearing all pending data and shall prepare sense data. 3) if it is operating in initiator mode for the I/O process, shall abort the I/O process. It is recommended that the initiator then request sense information from the target. 5.5.2. Information Transfer Phase The NEXUS TRANSFER phases are known as the information transfer phases because they are all used to transfer data or control information via the SCSI bus. The actual content of the information is beyond the scope of this section. In parallel interfaces and in SCSI-2, the MESSAGE, COMMAND, DATA phases, and STATUS phase were used to identify the type of data being transferred at different points during a connection. In the serial interface the nexus transfer phases are used for all transfers. Two phases of the same type may be processed back-to-back provided that there is a pause containing encoded idle characters between the information packets of at least xx bytes. .kp on Table 5-1: Serial Interface Information Transfer Phases ================================================================= Phase Name Direction Of Transfer Comment ----------------------------------------------------------------- NEXUS TRANSFER OUT Initiator to target Nexus NEXUS TRANSFER IN Initiator from target Transfer Phase ================================================================= .kp off 5.5.3. Synchronous Data Transfer The nexus transfer phase, by virtue of the manner in which it is transmitted, is always in the form of synchronous data transfer. Synchronous data transfer is the only mode of operation for the serial SCSI port. The offset between source and destination is logically controlled by the number of information packets outstanding, rather than the number of bytes, as for the parallel interface. 5.5.4. Nexus Transfer Phase The nexus transfer phase is a term that encompasses the NEXUS TRANSFER IN phase and the NEXUS TRANSFER OUT phase. 5.5.4.1. NEXUS TRANSFER IN Phase The NEXUS TRANSFER IN phase allows the target to send information packet(s) to the initiator. The processing of messages in the message system is altered using this phase. Synchronous data transfer is always used during this phase. No SDTR negotiation is possible or defined. The target shall insert an information packet on its inbound/send conductor when it has an information packet pending and the idle encoded character has been detected for xx bytes. 5.5.4.2. NEXUS TRANSFER OUT Phase The NEXUS TRANSFER OUT phase allows the initiator to send information packet(s) to a target. The processing of messages in the message system is altered using this phase. Synchronous data transfer is always used during this phase. No SDTR negotiation is possible or defined. The initiator shall insert an information packet on its outbound or send conductor when it has an information packet pending and the idle encoded character has been detected for xx bytes. 5.5.5. Signal Restrictions Between Phases When the SCSI bus is between two information transfer phases, the following restrictions shall apply: (1) The sending SCSI port shall wait until xx idle encoded characters have been transferred on the conductor before attempting to send another information packet. 5.6. Serial Interface SCSI Bus Conditions The SCSI bus has one asynchronous condition; the reset condition. This condition causes the SCSI device to perform certain actions. SCSI devices may not all be powered on at the same time. This standard does not address power sequencing issues. However, each SCSI device, as it is powered on, should perform appropriate internal reset operations and internal test operations. It is recommended that, following power-on sequence or a reset condition, SCSI devices be able to respond with appropriate status and sense data to the TEST UNIT READY, INQUIRY, and REQUEST SENSE commands within xx seconds. 5.6.1. Reset Condition The reset condition is used to immediately clear all SCSI devices from the bus. This condition shall take precedence over all other phases and conditions. Any SCSI device may create the reset condition by broadcasting a reset information packet. Upon receipt of the reset information packet, all SCSI devices shall perform an unexpected disconnect on their send conductors if they are actively sending an information packet. The BUS FREE phase always follows the reset condition. The effect of the reset condition on I/O processes which have not completed, path groups, assignments, reservations, and SCSI device operating modes is determined in the following section. 5.6.2. Reset Condition Actions by SCSI Devices SCSI devices shall: (1) Attempt to complete any I/O processes which have not completed and that were fully identified (2) Preserve all SCSI device path groups, path group status, assignments, passwords and reservations, as appropriate (3) Preserve any SCSI device operating modes (MODE SELECT, PREVENT/ALLOW MEDIUM REMOVAL commands, etc.) (4) Preserve all the information required to continue normal dispatching of I/O processes queued prior to the reset condition. The SCSI bus may be reset with minimum disruption to the operation of the logical system. To ensure proper operation the following conditions shall be met: (1) An initiator shall not consider an I/O process to be fully identified until it receive an acknowledgement information packet from the target. (2) A target shall consider an I/O process to be fully identified when the target detects no error in the information packet containing the identify information (3) If an initiator attempts a connection with a logical unit for which there already is an active I/O process with the same queue tag (if any) for the same initiator, the target shall clear the original I/O process and perform the new I/O process. (4) If a target attempts a reconnection with an initiator to continue an I/O process for which the initiator has no saved pointers, the initiator shall abort that unknown I/O process by sending the ABORT or ABORT TAG message, depending on whether the I/O process is a tagged I/O process. The message is contained in an information packet. (5) An initiator shall consider an I/O process to be completed when no error is detected in the transfer of an information packet containing the COMMAND COMPLETE message. (6) A target shall consider an I/O process to be completed when it detects the acknowledge information packet for the information packet containing the COMMAND COMPLETE message. (7) When using the nexus transfer phase, an initiator shall not transmit an acknowledge information packet for an information packet until it has actually saved the pointers for the current I/O process. (8) A target shall consider the pointers saved when it detects the acknowledgement packet for each information packet. (9) If the reset condition occurs before the acknowledgement information packet is received for an information packet containing a data interface logical element, the target shall terminate the I/O process with CHECK CONDITION status. The target shall set the sense key to ABORTED COMMAND. This is necessary because the target cannot determine whether the data pointer has actually been saved. If the reset condition occurs during transfer of an information packet, the packet is retransmitted and the I/O process continues. 5.7. Serial Interface SCSI Bus Phase Sequences The order in which phases are used on the SCSI bus follows a prescribed sequence. The reset condition can abort a nexus transfer phase, and it is always followed by the BUS FREE phase. Also any nexus transfer phase can be followed by the BUS FREE phase. If the bus is not in the BUS FREE phase after the reset condition, further operation of the I/O process on an SCSI port attached to that bus shall not be attempted. The allowable sequences shall be as shown in Figure 5-x. The normal progression is from the BUS FREE phase to one of the nexus transfer phases for each conductor. The nexus transfer phase used is determined by whether the SCSI port is in initiator mode or target mode. For initiator mode, the phase used is NEXUS TRANSFER OUT. For target mode, the phase is NEXUS TRANSFER IN. The SCSI port shall use only the BUS FREE phase and one of the nexus transfer phases, as appropriate, until the mode of the SCSI port is changed. Each phase is followed by a BUS FREE phase or another execution of a nexus transfer phase. .kp on +---------------+ +--| NEXUS | | | TRANSFER |<-+ Reset or +->| IN or OUT | | protocol | +---------------+ | error | | | | | | | | | | +---------------+ | | | | | | | +->| BUS FREE |--+ +-------->| | | | +---------------+ Figure 5-x: Serial Interface Phase Sequences .kp off 5.8. Serial Interface SCSI Pointers Consider the system shown in Figure 5-y in which an initiator and target communicate on the SCSI bus to execute an I/O process. .kp on ------------------------- ------------------------- | Function | | Initiator|<----------------| Target | | Function | | Origin | | SCSI Bus | SCSI BUS | SCSI Bus | | Execution| | | | Control |---------------->| Control | | | ------------------------- ------------------------- Initiator Target Figure 5-y: Simplified SCSI System .kp off The SCSI architecture provides for a set of three pointers for each active I/O process when the SCSI port is operating in initiator mode, called the saved pointers. The pointers are not used when the same port is in target mode and they shall not be changed while the port is in target mode. The saved pointers are a resource of the host system, and they may reside in an initiator, or they may reside in an area available to the ports managing an established path group where the connect was made for an the I/O process. If multiple path operations are implemented, the saved pointers must reside in a common area shared by the initiators for the path group where the connect for each I/O process is made. If multiple path operations are not implemented, are suspended, or the path group consists of only one path, the saved pointers may reside in either place. The set of three saved pointers consists of one for the current command, one for the data associated with the current command, and one for the status for the current command. The current command is the one executing in the target. The pointers move through the various parts of an I/O process based on actions taken by the target as it executes the I/O process. The data pointer is the only pointer which actively changes during the execution of a command in a target. The command and status pointers are reset to the next command or status area as status for each command as it is completed. Commands, status, and data are transmitted on information packet boundaries and therefore the pointers cannot follow in a byte-by-byte fashion, as in the parallel interface. There is only one set of active pointers in each initiator. The active pointers reside in the SCSI port and are used during a connection when the port is in initiator mode. Of the active pointers, only the data pointer is used during a connection to point to the next position where a data interface logical element may be read into or transferred from between the initiator and the target for the current I/O process. When an active I/O process becomes the current I/O process, its saved pointers are automatically transferred into the initiator's set of active pointers. The saved command pointer always points to the start of the current command descriptor block (see 6.2) for each active I/O process. With queued commands and information packets, this pointer only has meaning to the initiator and the host system. The pointer is updated by the initiator for the host system as the I/O process executes. The saved status pointer always points to the start of the status area for the current command of each active I/O process. The saved data pointer points to the start of the data area for the current command until the acknowledgement information packet is received for an information packet which contained a data interface logical element sent to a target. The saved data pointer points to the start of the data area for the current command until an information packet which contains a data interface logical element sent from a target is received without error. The data pointer is automatically saved at the end of either of these two operations. The correct saved pointers pointers are automatically restored at the beginning of each new nexus transfer phase. The target may modify the active data pointer by sending a MODIFY DATA POINTER message (see 5.y.15) to the initiator as part of an information packet. The initiator then adjusts the data pointer in the set of active pointers. Data can then be retransmitted to replace data already transmitted to the initiator or the target. To cause the pointer to be saved, the information packet must contain a data logical interface element. When each information packet is processed, only the set of saved pointers for the active I/O process is retained. The set of active pointers is restored from the set of saved pointers automatically upon reconnection. Reconnection changes an active I/O process to the current I/O process. The data pointer value may be modified by the target at any time before the command status is transferred and, therefore, it should not be used to test for actual transfer length. The queue of commands for the I/O process in the host system must be managed according to which ones have been executed, which ones have been transferred to the target if queued I/O processes are being used, and which ones are yet to be transferred to the target for immediate execution or for execution based on the queue tags. The mechanism for management of the status of an I/O process other than the saved and active pointers, described above, is beyond the scope of this standard. 5.9. Logical Operation Model See document X3T9.2/89-133R1. 5.10. Information Packet Structure An information packet is an ordered set of self-describing interface logical elements surrounded by the appropriate interface control fields necessary to transmit the logical content of the packet on the physical bus (Table 5-x). For the serial bus, the interface control fields are yy bytes in length. For the parallel bus, the interface control fields are xx bytes in length. .kp on Table 5-x: Information Packet Structure =================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | =================================================================== 0-m| Interface Control Prefix Fields | -----|------------------------------------------------------------| m+1-n| Message Interface Logical Element | -----|------------------------------------------------------------| n+1-p| Zero or more Interface Logical Elements | -----|------------------------------------------------------------| p+1-q| Interface Control Suffix Fields | =================================================================== .kp off 5.10.a. Interface Control Fields 5.10.a.1. Interface Control Fields (Parallel) The reasons for the parallel bus interface control fields being of different length and make up than the serial bus interface control fields are: that the two SCSI ports, the source and destination of the information packet, are in direct contact on the SCSI bus; the connection established between the two SCSI ports indicates that the source and destination addresses are valid; CRC is not required on the parallel bus; and parity is checked as the transfer occurs. .kp on Table 5-x: Interface Control Prefix Fields (Parallel) =================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | =================================================================== 0 | (MSB) | -----|--- ---| 1 | | -----|--- Packet Length ---| 2 | | -----|--- ---| 3 | (LSB) | -----|------------------------------------------------------------| 4 | Packet Type | -----|------------------------------------------------------------| 5 |LUNTAR|MltPath|QNexus| Reserved | -----|------------------------------------------------------------| 6 | Original Initiator SCSI Address | -----|------------------------------------------------------------| 7 | Original Target SCSI Address | -----|------------------------------------------------------------| 8 | LUNTRNID | -----|------------------------------------------------------------| 9 | Target Port Number | -----|------------------------------------------------------------| 10 | Queue tag | -----|------------------------------------------------------------| 11 | Reserved | -----|------------------------------------------------------------| 12-n| TBD | =================================================================== .kp off The packet length field indicates the total length of the information packet in bytes, including the interface control prefix fields and the interface control suffix fields. The actual usable maximum packet length is a function of the selected physical interface and may be further restricted by burst length negotiations. The packet type field identifies the general content of an information packet. A packet type code of 00h indicates a host system initiated information packet to start a new nexus. A packet type code of 01h indicates a target initiated packet to terminate an I/O process. A packet type code of 02h indicates an intermediate information packet from a host system to continue an I/O process established with an information packet of type 00h. A packet type code of 03h indicates an intermediate information packet from a target controller to continue an I/O process established with an information packet of type 00h. A packet type code of 05h indicates that a nexus is requested to be established in the host system by the target controller because of an asynchronous event notification condition or a unit attention condition. Packet type code of 05h through FFh are reserved. A logical unit target (LUNTAR) bit of zero specifies that the I/O process is directed to or from a logical unit. A LUNTAR bit of one specifies that the I/O process is directed to or from a target routine. The logical unit or target routine is identified in the LUNTRNID field. When sent by a target during a reconnection, the value of this bit shall be the same as the most recent value received for this I/O process. The value supplied in this field with the connect shall not change during the information packet exchange related to the nexus from the value transferred in the information packet with packet code 00h. A multiple path (MltPath) bit of one specifies that the host system is capable of multiple path operation. The effect is to form an H_C nexus. Multiple path operation is interpreted as active for each nexus when the bit is set to 1. The type of nexus may be overridden by the INFORMATION PACKET IDENTIFY message within the information packet, in which case, the target controller converts the H_C nexus to an H_I_T_C nexus. The setting has no effect on any other active or queued I/O process in the target controller. When the bit is set to zero, the target controller forms an H_I_T_C nexus immediately and ignores the SuspMpth bit in the INFORMATION PACKET IDENTIFY message. The queue nexus (QNexus) bit when one indicates that the nexus will be of the form H_C_L_Q or H_I_T_C_Q. When the queue nexus bit is zero, the nexus formed will be of the form H_C_L, H_C_R, H_I_T_C_L, or H_I_T_C_R. The next five fields identify the path on which the connect was made for the nexus. The LUNTAR bit identifies whether the nexus is directed toward a logical unit or a target routine. These five fields shall not change in any information packet of any type transferred for the nexus once established as specified below. These five fields and the LUNTAR bit, permit the host system to identify the nexus to be reestablished in any subsequent connection on any path for the nexus, and likewise in the target controller, when operating in a multiple path environment. The original initiator SCSI address identifies the port on the host system where the connect was made using an information packet packet type code of 00h. The original target SCSI address identifies the port, from the host system perspective, where the connect was made using an information packet packet type code of 00h. The target port number identifies the physical port number assigned by the target controller to the target SCSI address. This field shall be zero when the packet type code is 00h. The target shall supply its unique port value in any subsequent information packet sent to the host system. Once an information packet has been received by the host system for the nexus, all subsequent information packets from the host system and the target controller shall have the reported value placed in this field. If the disconnect privilege is not granted to a target controller, the host system may not receive the target port number until the information packet with a packet type of 01h is received at the host system. The logical unit number target routine number (LUNTRNID) field specifies a logical unit number if the LUNTAR bit is zero. The LUNTRNID field specifies a target routine number if the LUNTAR bit is one. The response to an invalid value in the LUNTRNID field is described in 6.5.3. The queue tag field is identical to the queue tag supplied in any queue tag messages transferred during the nexus. This field has meaning only when the QNexus bit is set to 1. If the QNexus bit is set to zero, the host system shall set this field to 00h. If the target controller detects any value, other than 00h, it shall indicate the error to the host system by sending an information packet with an INVALID INFORMATION PACKET message. There are no interface control suffix fields for the parallel bus. .kp on 5.10.a.2. Interface Control Fields (Serial) Table 5-x: Interface Control Prefix Fields (Serial) =================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | =================================================================== 0-n | TBD | =================================================================== .kp off The format of the interface control prefix fields are subject to standardization in other ANSI committees and will be added or referred to at a later time. .kp on Table 5-x: Interface Control Suffix Fields (Serial) =================================================================== Byte | Description | =================================================================== 0-n | TBD | =================================================================== .kp off The format of the interface control suffix fields are subject to standardization in other ANSI committees and will be added or referred to at a later time. The interface control suffix fields are not permitted on the parallel bus and mandatory on the serial bus. 5.10.b. Interface Logical Elements The logical interface elements are messages, command descriptor blocks, command parameter data, command response data, logical blocks, and status as described in Sections 5 though 17 of this standard. A self-describing set of fields surrounds the data, called interface control fields, to permit the information packet to be correctly identified and checked at the receiving SCSI port. The information packet does not remove any functional capability from the SCSI interface. Some functions are no longer required, or there is a substitute way of accomplishing the same function when using information packets. A self-describing logical interface element is composed of four fields: the element length, the element type, a reserved field, and the logical element bytes. .kp on Table 5-x: Self-Describing Interface Logical Element =================================================================== Byte | Description | =================================================================== 0 | | ----------|--- Element Length ---| 1 | | ----------|-------------------------------------------------------| 2 | Element Type | ----------|-------------------------------------------------------| 3 | Reserved | ----------|-------------------------------------------------------| 4-n | Element Bytes | =================================================================== .kp off The element length is a two-byte binary field. The value range is from 4 to 65535. If the element length value is 4, the logical element contains only an element type field and is to be ignored by the receiver of the information packet. The value is 4 plus the number of element bytes included up to the maximum value. The maximum length for any one interface logical element must be with respect to the physical bus requirements for the maximum packet length. For the parallel interface using the nexus transfer phase, the maximum information packet length is 2**32 - 1 bytes. The element type is a one-byte binary field. The value range is 0 through 5. The valid value are defined below. .kp on ELEMENT TYPE VALUE INTERFACE LOGICAL ELEMENT 0 Message 1 CDB 2 Command Parameter Data 3 Command Response Data 4 Logical Block 5 Status 6-255 Reserved .kp off The reserved field is a one-byte field. The sender shall set the field to zero. If the receiver of an information packet detects a value other than zero it shall not process the logical element or any logical elements which follow in the same information packet. The logical element bytes field is a 0 to 65535 byte variable length field composed of the information relative to the element type declared in the element type field. The maximum length which may be used for this field may vary by the physical interface implemented. 5.10.b.1. Message Interface Logical Element The message logical interface element includes all messages defined in the message system and applicable to the physical bus and protocol implemented. The logical element bytes are filled in with the message bytes in the order which they would be transferred on a single byte wide bus. See sections 5.x and 5.y for the message descriptions and their use. 5.10.b.2. Command Descriptor Block Interface Logical Element The command descriptor block interface logical element is composed of the set of variable length CDBs for commands defined in Sections 7 through 17 of this standard. Command parameter data is transferred in its own interface logical element. The logical element bytes are filled in with the CDB bytes in the order which they would be transferred on a single byte wide bus. 5.10.b.3. Command Parameter Data Interface Logical Element The command parameter data interface logical element is a burst of data transferred for a command which is sent as an addendum to the command descriptor block. The CDB identifies the total length of the command parameter data in the parameter length fields, etc. The logical element bytes are filled in with the command parameter data bytes in the order which they would be transferred on a single byte wide bus. 5.10.b.4. Command Response Data Interface Logical Element The command response data interface logical element is a burst of data transferred from a target to an initiator for a command which is not taken from the logical blocks of the LUN. Sense data and MODE SENSE pages are examples of command response data. The CDB identifies the maximum length of the command response data in the allocation length fields, etc. The logical element bytes are filled in with the command response data bytes in the order which they would be transferred on a single byte wide bus. 5.10.b.5. Logical Block Interface Logical Element The logical block interface logical element consists of a burst of data from the logical blocks requested for transfer between an initiator and a target. The logical block interface logical element is roughly equivalent to a burst of bytes in a data phase. The logical element bytes are filled in with the bytes from a burst of data for one or more logical blocks in the order which they would be transferred on a single byte wide bus. The element length may have the same variable nature as if the data were being transferred using the data phase. 5.10.b.6. Status Interface Logical Element The status interface logical element is the status as defined in Section 6 of this standard. The logical element bytes are filled in with status in the order which they would be transferred on a single byte wide bus. 5.10.c. Information Packet Layout 5.10.c.1. Parallel Bus The parallel bus information packet layout consists of the following minimum structures: one information control prefix structure and one message interface logical element immediately following the interface control prefix structure are mandatory. The message interface logical element shall messages following the rules of the message system (5.x and 5.y). There is no interface control suffix structure on for the parallel bus information packet (Table 5-x). The remainder of the information packet is made up of zero or more interface logical elements, as required to perform the operations for the I/O process. .kp on Table 5-x: Information Packet Structure (Parallel) =================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | =================================================================== 0-m| Interface Control Prefix Fields (Parallel) | -----|------------------------------------------------------------| m+1-n| Message Interface Logical Element | -----|------------------------------------------------------------| n+1-p| Zero or more Interface Logical Elements | =================================================================== .kp off 5.10.c.2. Serial Bus TBD .kp on Table 5-x: Information Packet Structure (Serial) =================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | =================================================================== 0-m| Interface Control Prefix Fields (Serial) | -----|------------------------------------------------------------| m+1-n| Message Interface Logical Element | -----|------------------------------------------------------------| n+1-p| Zero or more Interface Logical Elements | -----|------------------------------------------------------------| p+1-q| Interface Control Suffix Fields (Serial) | =================================================================== .kp off 5.10.d. Information Packet Examples The following two information packets comprise a complete nexus for causing a rewind command to be executed in a sequential access device. The first information packet is a request for a sequential device to perform a rewind operation while the initiator waits with no disconnect permitted. The total exchange requires 68 bytes to be transferred. Each information packet is 34 bytes long. The SCSI-2 protocol requires 9 bytes total: 7 bytes from the host system and 2 bytes from the target controller. If disconnect were allowed the total would be 10 bytes with the target controller transferring 3 bytes. The percent of bytes for overhead is reduced as data transfer commands are mapped into the new protocol. This structure, in properly configured systems permits reconnection on any path in an established path group for the host system on which the connect was made. The new capability is almost mandatory when using the serial bus since multiple path configurations happen as a matter of course with the point-to-point switches. The SCSI-2 protocol cannot be extended, easily, to accommodate the new requirements. .kp on Table 5-x: Initial Information Packet Example (Parallel) =================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | =================================================================== 0 | (MSB) | -----|--- ---| 1 | | -----|--- Packet Length ---| 2 | 00000022h | -----|--- ---| 3 | (LSB) | -----|------------------------------------------------------------| 4 | Packet Type | | 00H (Initiate I/O Process) | -----|------------------------------------------------------------| 5 |LUNTAR|MltPath|QNexus| Reserved | | 0 0 0 00000 | -----|------------------------------------------------------------| 6 | Original Initiator SCSI Address | | 07h | -----|------------------------------------------------------------| 7 | Original Target SCSI Address | | 01h | -----|------------------------------------------------------------| 8 | LUNTRNID | | 00h | -----|------------------------------------------------------------| 9 | Target Port Number | | 00h | -----|------------------------------------------------------------| 10 | Queue tag | | 00h | -----|------------------------------------------------------------| 11 | Reserved | | 00h | =================================================================== .kp off .kp on Table 5-x: Initial Information Packet Example Cont'd (Parallel) =================================================================== Byte | Message Interface Logical Element | =================================================================== 0 | | ----------|--- Element Length ---| 1 | 000Ch | ----------|-------------------------------------------------------| 2 | Element Type | | 00h | ----------|-------------------------------------------------------| 3 | Reserved | | 00h | ----------|-------------------------------------------------------| 4-11 | Element Bytes | | 01h | | 08h | | 05h | | 00h | | 00h | | 07h | | 01h | | 00h | =================================================================== .kp off .kp on Table 5-x: Initial Information Packet Example Cont'd (Parallel) =================================================================== Byte | CDB Interface Logical Element | =================================================================== 0 | | ----------|--- Element Length ---| 1 | 000Ah | ----------|-------------------------------------------------------| 2 | Element Type | | 01h | ----------|-------------------------------------------------------| 3 | Reserved | | 001h | ----------|-------------------------------------------------------| 4-9 | Element Bytes | | 01h (Sequential Rewind) | | 00h | | 00h | | 00h | | 00h | | 00h | =================================================================== .kp off The sequential device performs the rewind operation without disconnecting and then sends the following information packet to the host system during the initial connection. The information packet is 34 bytes long. and includes the interface control prefix fields, the INFORMATION PACKET IDENTIFY message interface logical element, the status interface logical element and the COMMAND complete message interface logical element. .kp on Table 5-x: Response Information Packet Example (Parallel) =================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | =================================================================== 0 | (MSB) | -----|--- ---| 1 | | -----|--- Packet Length ---| 2 | 00000022h | -----|--- ---| 3 | (LSB) | -----|------------------------------------------------------------| 4 | Packet Type | | 01h (Terminate I/O Process) | -----|------------------------------------------------------------| 5 |LUNTAR|MltPath|QNexus| Reserved | | 0 0 0 00000 | -----|------------------------------------------------------------| 6 | Original Initiator SCSI Address | | 07h | -----|------------------------------------------------------------| 7 | Original Target SCSI Address | | 01h | -----|------------------------------------------------------------| 8 | LUNTRNID | | 00h | -----|------------------------------------------------------------| 9 | Target Port Number | | 04h (Internal Port Number) | -----|------------------------------------------------------------| 10 | Queue tag | | 00h | -----|------------------------------------------------------------| 11 | Reserved | | 00h | =================================================================== .kp off .kp on Table 5-x: Response Information Packet Example Cont'd (Parallel) =================================================================== Byte | Message Interface Logical Element | =================================================================== 0 | | ----------|--- Element Length ---| 1 | 000Ch | ----------|-------------------------------------------------------| 2 | Element Type | | 00h | ----------|-------------------------------------------------------| 3 | Reserved | | 00h | ----------|-------------------------------------------------------| 4-11 | Element Bytes | | 01h | | 08h | | 05h | | 00h | | 00h | | 07h | | 01h | | 00h | =================================================================== .kp off .kp on Table 5-x: Response Information Packet Example Cont'd (Parallel) =================================================================== Byte | Status Interface Logical Element | =================================================================== 0 | | ----------|--- Element Length ---| 1 | 0005h | ----------|-------------------------------------------------------| 2 | Element Type | | 05h | ----------|-------------------------------------------------------| 3 | Reserved | | 00h | ----------|-------------------------------------------------------| 4-9 | Element Bytes | | 00h (Good) | =================================================================== .kp off .kp on Table 5-x: Response Information Packet Example Cont'd (Parallel) =================================================================== Byte | Message Interface Logical Element | =================================================================== 0 | | ----------|--- Element Length ---| 1 | 0005h | ----------|-------------------------------------------------------| 2 | Element Type | | 00h | ----------|-------------------------------------------------------| 3 | Reserved | | 00h | ----------|-------------------------------------------------------| 4-11 | Element Bytes | | 00h (Command Complete) | =================================================================== .kp off 5.x. Message System Description The message system allows communication between an initiator and target of information not contained in the other interface logical elements (e.g., commands). A message may be one, two, or multiple bytes in length. When the initiator and target are using the MESSAGE phase, One or more messages may be sent during a single MESSAGE phase. A multiple-byte message may not be split over MESSAGE phases. The initiator is required, when using the message phase, to end the MESSAGE OUT phase (by negating ATN) when it sends certain messages as identified in Table 5-2. When using the nexus transfer phase, one or more messages may be transferred along with other interface logical elements in a single information packet. A multiple-byte message may not be split over information packets or between message interface logical elements in one information packet. The initiator is required to control the length of the message logical interface elements in an information packet when it sends certain messages as identified in Table 5-2. Such information packets shall not contain any other interface logical elements. One-byte, Two-byte, and extended message formats are defined. The first byte of the message determines the format as follows: .kp on Value Message Format --------- ----------------------------------- 00h One-Byte Message (COMMAND COMPLETE) 01h Extended Messages 02h - 1Fh One-Byte Messages 20h - 2Fh Two-Byte Messages 30h - 7Fh Reserved 80h - FFh One-Byte Message (IDENTIFY) .kp off All initiators shall implement the mandatory messages tabulated in the "Init" column of Table 5-2 for nexus transfer phase operations. All targets shall implement the mandatory messages tabulated in the "Targ" column of Table 5-2 for nexus transfer operations. This is modified by the presence of the "+" and "-" symbols before each message name with the meanings defined in Table 5-2. .kp on Table 5-2: Message Codes ========================================================================= Negate ATN Code Support Message Name Direction Before Init Targ Last ACK ------------------------------------------------------------------------- 06h O M ABORT Out Yes 0Dh O O ABORT TAG (Note 1) Out Yes 0Ch O M BUS DEVICE RESET Out Yes 0Eh O O CLEAR QUEUE (Note 1) Out Yes 00h M M COMMAND COMPLETE In --- 04h O O -DISCONNECT In --- 04h O O -DISCONNECT Out Yes *** O O +EXTENDED MESSAGE REJECT In Out Yes 80h+ M O -IDENTIFY In --- 80h+ M M -IDENTIFY Out No 23h O O IGNORE WIDE RESIDUE (Two Bytes) In --- *** O O +INFORMATION PACKET IDENTIFY In Out --- 0Fh O O INITIATE RECOVERY In --- 0Fh O O INITIATE RECOVERY (Note 2) Out Yes 05h M M INITIATOR DETECTED ERROR Out Yes 25h O O INVALID BUS PHASE DETECTED (Two Bytes) In Out Yes *** O O +INVALID INFORMATION PACKET In Out --- 0Ah O O LINKED COMMAND COMPLETE In --- 0Bh O O LINKED COMMAND COMPLETE (WITH FLAG) In --- 09h M M -MESSAGE PARITY ERROR In --- 09h M M -MESSAGE PARITY ERROR Out Yes 07h M M -MESSAGE REJECT In Out Yes *** O O MODIFY DATA POINTER In --- 08h M M NO OPERATION Out Yes 24h O O PARITY ERROR (Two Bytes) In Out Yes Queue Tag Messages (Two Bytes) 21h O O HEAD OF QUEUE TAG Out No 22h O O ORDERED QUEUE TAG Out No 20h O O SIMPLE QUEUE TAG In Out No 10h O O RELEASE RECOVERY Out Yes 26h O O +RESEND PREVIOUS INFORMATION PACKET In Out Yes 03h O O -RESTORE POINTERS In --- 02h O O -SAVE DATA POINTER In --- *** O O SYNCHRONOUS DATA TRANSFER REQUEST In Out Yes *** O O +SYNCHRONOUS PACKET TRANSFER REQUEST In Out Yes 11h O O TERMINATE I/O PROCESS Out Yes *** O O WIDE DATA TRANSFER REQUEST In Out Yes 12h - 1Fh Reserved 27h - 2FH Reserved for two-byte messages 30h - 7Fh Reserved ========================================================================= .kp off .kp on Key: M = Mandatory support, O = Optional support. In = Target to initiator, Out = Initiator to target. Yes = Initiator shall negate ATN before last ACK of message. No = Initiator may or may not negate ACK before last ACK of message. (see attention condition, 5.2.1.) + = Used only with NEXUS TRANSFER phase protocol - = Not used with NEXUS TRANSFER phase protocol --- = Not Applicable *** = Extended message (see Tables 5-3 and 5-4) 80h+ = Codes 80h through FFh are used for IDENTIFY messages (see Table 5-7). NOTES: (1) The ABORT TAG and CLEAR QUEUE messages are required if tagged queuing is implemented. (2) Outbound INITIATE RECOVERY messages are only valid during the asynchronous event notification protocol. ------------------------------------------------------------------------------ .kp off One-byte messages consist of a single byte where the value of the byte determines which function is to be performed as defined in Table 5-2. Two byte messages consist of a message code followed by a parameter byte. The message code determines which function is to be performed using the value in the parameter byte. A value of one in the first byte of a message indicates the beginning of a multiple-byte extended message. The minimum number of bytes sent for an extended message is three. The extended message format and the extended message codes are shown in Tables 5-3 and 5-4, respectively. For extended messages, the message code is followed by a variable length set of parameter bytes. .kp on Table 5-3: Extended Message Format ============================================================================== Byte | Value | Description | ============================================================================== 0 | 01h | Extended message | ----------|----------|-------------------------------------------------------| 1 | n | Extended message length | ----------|----------|-------------------------------------------------------| 2 | y | Extended message code | ----------|----------|-------------------------------------------------------| 3 - n+1 | x | Extended message arguments | ============================================================================== .kp off The extended message length specifies the length in bytes of the extended message code plus the extended message arguments to follow. Therefore, the total length of the message is equal to the extended message length plus two. A value of zero for the extended message length indicates 256 bytes follow. The extended message codes are listed in Table 5-4. The extended message arguments are specified within the extended message descriptions. .kp on Table 5-4: Extended Message Codes ============================================================================== Code (y) Description ------------------------------------------------------------------------------ 02h Reserved (See Note) 00h MODIFY DATA POINTER 01h SYNCHRONOUS DATA TRANSFER REQUEST 03h WIDE DATA TRANSFER REQUEST 04h EXTENDED MESSAGE REJECT 05h INFORMATION PACKET IDENTIFY 06h INVALID INFORMATION PACKET 07h SYNCHRONOUS PACKET TRANSFER REQUEST 08h - 7Fh Reserved 80h - FFh Vendor Unique ============================================================================== NOTE: Extended message code 02h was used for the EXTENDED IDENTIFY message in SCSI-1. .kp off 5.x.1. Message Use with the Message Phase The first message sent by the initiator after the SELECTION phase shall be an IDENTIFY, ABORT, or BUS DEVICE RESET message. If a target receives any other message it shall go to BUS FREE phase (see unexpected disconnect, 5.1.1). If the first message is an IDENTIFY message, then it may be immediately followed by other messages, such as the first of a pair of SYNCHRONOUS DATA TRANSFER REQUEST messages. If tagged queuing is used the queue tag message immediately follows the IDENTIFY message (see 5.y.7). The IDENTIFY message establishes a logical connection between the initiator and the specified logical unit or target routine within the target known as an I_T_L nexus or I_T_R nexus. After the RESELECTION phase, the target's first message shall be IDENTIFY. This allows the I_T_L nexus or I_T_R nexus to be re-established. Only one logical unit or target routine shall be identified for any connection; if a target receives a second IDENTIFY message with a different logical unit number or target routine number during a connection, it shall go to BUS FREE phase (see unexpected disconnect, 5.1.1). The treatment of other logical unit addressing errors is described in 6.5. All initiators shall implement the mandatory messages tabulated in the "Init" column of Table 5-2. All targets shall implement the mandatory messages tabulated in the "Targ" column of Table 5-2. Whenever an I_T_L nexus or I_T_R nexus is established by an initiator that is allowing disconnection, the initiator shall ensure that the active pointers are equal to the saved pointers for that particular logical unit or target routine. An implied restore pointers operation shall occur as a result of a reconnection. 5.x.2. Message Use with the Nexus Transfer Phase The first interface logical element in each information packet shall be a message interface logical element with the first or only message being INFORMATION PACKET IDENTIFY, ABORT, or BUS DEVICE RESET message. If a target receives any other interface logical element before a message interface logical element, it shall not process the contents of the information packet and shall enter the NEXUS TRANSFER IN phase and transfer an information packet containing an an INVALID INFORMATION PACKET message. If the target receives any other message before one of the named messages in the first message interface logical element, it shall not process the contents of the information packet and shall enter the NEXUS TRANSFER IN phase and transfer an information packet containing an EXTENDED MESSAGE REJECT message. If the first interface logical element is a message group and the first message is an INFORMATION PACKET IDENTIFY message, then it may be immediately followed by other messages, such as a SYNCHRONOUS PACKET TRANSFER REQUEST messages. If tagged queuing is used the queue tag message immediately follows the INFORMATION PACKET IDENTIFY message (see 5.y.7). The INFORMATION PACKET IDENTIFY message establishes a logical connection between the initiator and the specified logical unit or target routine within the target known as an H_C_L nexus, an H_C_R nexus, an I_T_L nexus or I_T_R nexus. Only one logical unit or target routine shall be identified for any one information packet; if a target receives a second IDENTIFY message with a different logical unit number or target routine number in one information packet, it shall not process the remainder of the information packet beyond the point of the invalid INFORMATION PACKET IDENTIFY message. The treatment of other logical unit addressing errors is described in 6.5. 5.x.2.1. Message Use with the Nexus Transfer Phase (Parallel) After the RESELECTION phase, the target's first information transfer phase shall be a NEXUS TRANSFER IN phase with an information packet containing as the first interface logical element an INFORMATION PACKET IDENTIFY message. This allows the H_C_L nexus, H_C_R nexus, I_T_L nexus or I_T_R nexus to be re-established. Additional messages may follow the INFORMATION PACKET IDENTIFY message in the interface logical element. Whenever an H_C_L nexus, an H_C_R nexus, an I_T_L nexus, or I_T_R nexus is established by an initiator that is allowing disconnection, the initiator shall ensure that the active pointers are equal to the saved pointers for that particular logical unit or target routine. An automatic implied restore pointers operation shall occur in the initiator as a result of a new information packet for the same I/O process or a reconnection to the same I/O process. 5.x.2.2. Message Use with the Nexus Transfer Phase (Serial) Each target sent information packet shall contain, as the first interface logical element, an INFORMATION PACKET IDENTIFY message. This allows the H_C_L nexus, H_C_R nexus, I_T_L nexus or I_T_R nexus to be re-established. Additional messages may follow the INFORMATION PACKET IDENTIFY message in the interface logical element. Whenever an H_C_L nexus, an H_C_R nexus, an I_T_L nexus, or I_T_R nexus is reestablished by a target the initiator shall ensure that the active pointers are equal to the saved pointers for that particular logical unit or target routine. An automatic implied restore pointers operation shall occur in the initiator as a result of each new information packet for the same I/O process or a reconnection to the same I/O process. 5.y. Message Descriptions The SCSI messages are defined in this section. The requirements for implementation are given in Table 5-2. 5.y.1. ABORT The ABORT message is sent from the initiator to the target to clear the active I/O process plus any queued I/O process for the H_C_x nexus or I_T_x nexus. Pending data, status, and queued I/O processes for any other H_C_X nexus or I_T_x nexus shall not be cleared. When this messages is received during a message phase, the target shall go to the BUS FREE phase following successful processing of this message. When this message is received as a result of a nexus transfer phase, there is no change to the physical interface as a result of successful processing. If only an H_C nexus or I_T nexus has been established, the target shall go to the BUS FREE phase if the MESSAGE OUT phase is used to transmit the message. No status or message shall be sent for the current I/O process and no other I/O process shall be affected. It is not an error to issue this message to an H_C_x nexus or I_T_x nexus that does not have an active or queued I/O process. Previously established conditions, including MODE SELECT parameters, reservations, and extended contingent allegiance shall not be changed by the ABORT message. IMPLEMENTORS NOTES: The BUS DEVICE RESET, CLEAR QUEUE, ABORT, and ABORT TAG messages provide a means to clear one or more I/O processes prior to normal termination. The BUS DEVICE RESET message clears all I/O processes for all initiators on all logical units and all target routines of the target. The CLEAR QUEUE message clears all I/O processes for all initiators on the specified logical unit or target routine of the target. The ABORT message clears all I/O processes for the selecting initiator on the specified logical unit or target routine of the target. The ABORT TAG message clears the active I/O process only. 5.y.2. ABORT TAG The ABORT TAG message shall be implemented if tagged queuing is implemented. The target shall go to the BUS FREE phase following successful receipt of this message if the MESSAGE OUT phase is used to transfer the message. The target shall clear the I/O process identified. If the target has already started execution of the I/O process, the execution shall be halted. The medium contents may have been modified before the execution was halted. In either case, any pending status or data for the I/O process shall be cleared and no status or ending message shall be sent to the initiator. Pending status, data, and commands for other active or queued I/O processes shall not be affected. Execution of other I/O processes queued for the H_C_x nexus or I_T_x nexus shall not be aborted. Previously established conditions, including MODE SELECT parameters, reservations, and extended contingent allegiance shall not be changed by the ABORT TAG message. 5.y.3. BUS DEVICE RESET The BUS DEVICE RESET message is sent from an initiator to direct a target to clear all I/O processes on that SCSI device. This message forces a reset condition to the selected SCSI device. The target shall go to the BUS FREE phase following successful receipt of this message if this message is transferred using the MESSAGE OUT phase . The target shall create a unit attention condition for all initiators (see 6.9). 5.y.4. CLEAR QUEUE The CLEAR QUEUE message shall be implemented if tagged queuing is implemented and may be implemented if untagged queuing is implemented. The target shall go to the BUS FREE phase following successful receipt of this message if the message is transferred using the MESSAGE OUT phase. The target shall perform an action equivalent to receiving a series of ABORT messages from each initiator. All I/O processes, from all initiators, in the queue for the specified logical unit or target routine shall be cleared from the queue. All active I/O processes shall be terminated. The medium may have been altered by partially executed commands. All pending status and data for that logical unit or target routine for all initiators shall be cleared. No status or message shall be sent for any of the I/O processes. A unit attention condition shall be generated for all other initiators with I/O processes that either were active or were queued for that logical unit or target routine. When reporting the unit attention condition the additional sense code shall be set to COMMANDS CLEARED BY ANOTHER INITIATOR. Previously established conditions, including MODE SELECT parameters, reservations, and extended contingent allegiance shall not be changed by the CLEAR QUEUE message. 5.y.5. COMMAND COMPLETE The COMMAND COMPLETE message is sent from a target to an initiator to indicate that the execution of an I/O process has completed and that valid status has been sent to the initiator. The I/O process may have completed successfully or unsuccessfully as indicated in the status. After successfully sending this message, the target shall go to the BUS FREE phase, when using the MESSAGE IN phase. The target shall consider the message transmission to be successful, during the MESSAGE IN phase, when it detects the negation of ACK for the COMMAND COMPLETE message with the ATN signal false. When using the nexus transfer phase with a serial bus, the target shall consider the message transmission to be successful when an acknowledgement information packet is received for the information packet containing the COMMAND COMPLETE MESSAGE, 5.y.6. DISCONNECT The DISCONNECT message is sent from a target using the MESSAGE IN phase to inform an initiator that the present connection is going to be broken (the target plans to disconnect by releasing the BSY signal), but that a later reconnect will be required in order to complete the current I/O process. This message shall not cause the initiator to save the data pointer. After successfully sending this message, the target shall go to the BUS FREE phase by releasing the BSY signal. The target shall consider the message transmission to be successful when it detects the negation of the ACK signal for the DISCONNECT message with the ATN signal false. Targets which break data transfers into bursts using multiple connections shall end each successful connection (except possibly the last) with a SAVE DATA POINTER - DISCONNECT message sequence. This message may also be sent from an initiator to a target using the MESSAGE OUT phase to instruct the target to disconnect from the SCSI bus. If this option is supported in the target, and after the DISCONNECT message is received, the target shall switch to MESSAGE IN phase, send the DISCONNECT message to the initiator (possibly preceded by SAVE DATA POINTER message), and then disconnect by releasing BSY. After releasing the BSY signal, the target shall not participate in another ARBITRATION phase for at least a disconnection delay. If this option is not supported, or the initiator has identified the I/O process with disconnection disallowed, or the target cannot disconnect at the time when it receives the DISCONNECT message from the initiator, the target shall respond by sending a MESSAGE REJECT message to the initiator. 5.y.x. EXTENDED MESSAGE REJECT This message shall be supported if the nexus transfer phase is supported. This message shall not be transmitted using the message phase. The EXTENDED MESSAGE REJECT message (Table 5-x) is sent from either the initiator or target to indicate that a portion of a message in a message interface logical element in the last information packet was inappropriate or has not been implemented. For parallel interfaces, to indicate its intentions of sending an information packet containing this message, the initiator shall assert the ATN signal. The target enters the NEXUS TRANSFER OUT phase at the next appropriate point in a data phase or at the end of the current nexus transfer phase. If the target receives this message in an information packet under any other circumstance, it shall reject this message. When a target sends this message, it shall use to NEXUS TRANSFER IN phase and send an information packet containing this message. The content of the extended message identifies the message group and the message byte within the group. In addition, the message also indicates whether the reason for the rejection. This provides a logical interlock so that the sender of the message can determine which message byte is in error. .kp on Table 5-x: EXTENDED MESSAGE REJECT Message Format ============================================================================== Byte | Value | Description | ============================================================================== 0 | 01h | Extended message | ----------|----------|-------------------------------------------------------| 1 | 04h | Extended message length | ----------|----------|-------------------------------------------------------| 2 | 04h | Extended message code | ----------|----------|-------------------------------------------------------| 3 | x | ILE Position | ----------|----------|-------------------------------------------------------| 4 | x | Position in ILE | ----------|----------|-------------------------------------------------------| 5 | x | Reject Reason Code | ============================================================================== .kp off The ILE Position is the position of the message interface logical element within the information packet containing the error. The ILE Position is a value in the range of 1 to 255. There may be more than one message interface logical element in one information packet. The Position in ILE is the byte position of the byte in error within the element bytes. The Reject Reason Code identifies the reason for sending the message. A code of 00h indicates that the message code in a one-byte, two-byte, or extended message is not implemented. A code of 01h indicates that the message is inappropriate. A code of 02h indicates that the length byte in an extended message is invalid for the message code. A code of 03h indicates that a parameter byte within two-byte and extended messages is invalid. Codes 04h-FFh are reserved. 5.y.7. IDENTIFY The IDENTIFY message (Table 5-5) is sent by either the initiator or the target using the message phase to establish an I_T_L nexus or an I_T_R nexus. IMPLEMENTORS NOTE: Use of the IDENTIFY message to establish an I_T_R nexus allows connection to one of up to eight target routines or functions in the target itself. These target routines are expected to be used for maintenance and diagnostic purposes. .kp on Table 5-5: IDENTIFY Message Format ============================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | ============================================================================== 0 |Identify|DiscPriv| LUNTAR |Reserved|Reserved| LUNTRN | ============================================================================== .kp off The identify bit shall be set to one to specify that this is an IDENTIFY message. A disconnect privilege (DiscPriv) bit of one specifies that the initiator has granted the target the privilege of disconnecting. A DiscPriv bit of zero specifies that the target shall not disconnect. This bit is not defined and shall be set to zero when an IDENTIFY message is sent by a target. A logical unit target (LUNTAR) bit of zero specifies that the I/O process is directed to or from a logical unit. A LUNTAR bit of one specifies that the I/O process is directed to or from a target routine. The logical unit number target routine number (LUNTRN) field specifies a logical unit number if the LUNTAR bit is zero. The LUNTRN field specifies a target routine number if the LUNTAR bit is one. The response to an invalid value in the LUNTRN field is described in 6.5.3. Only the INQUIRY and REQUEST SENSE commands are valid for target routines. If a target receives any other command for a target routine, it shall return CHECK CONDITION status and shall set the sense key to ILLEGAL REQUEST. An IDENTIFY message is invalid if a reserved bit is set to one or if the LUNTAR bit is set to one and the target does not implement target routines. A device may respond to an invalid IDENTIFY message by immediately sending a MESSAGE REJECT message or by returning CHECK CONDITION status. If a CHECK CONDITION status is returned, the sense key shall be set to ILLEGAL REQUEST and the additional sense code shall be set to INVALID BITS IN IDENTIFY MESSAGE FIELD. Only one logical unit number or target routine number shall be identified per I/O process. The initiator may send one or more IDENTIFY messages during a connection. A second IDENTIFY message with a different value in either the LUNTAR bit or LUNTRN field shall not be issued before a BUS FREE phase has occurred; if a target receives a second IDENTIFY message with a different value in either of these fields, it shall go to BUS FREE phase (see unexpected disconnect, 5.1.1). Thus an initiator may change the DiscPriv bit, but may not attempt to switch to another I/O process. (See the DTDC field of the disconnect-reconnect page (7.3.3.2) for additional controls over disconnection.) An implied RESTORE POINTERS message shall be performed by the initiator prior to the assertion of the ACK signal on the next phase for an inbound IDENTIFY message sent during reconnection. .kp on 5.y.8. IGNORE WIDE RESIDUE Table 5-6: IGNORE WIDE RESIDUE Message Format ============================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | ============================================================================== 0 | Message Code (23h) | -----|-----------------------------------------------------------------------| 1 | Ignore | ============================================================================== .kp off The IGNORE WIDE RESIDUE message (Table 5-6) shall be sent by a target or an initiator to indicate that the number of valid bytes sent during the last REQ/ACK handshake and REQB/ACKB handshake of a data phase or nexus transfer phase is less than the negotiated transfer width. The ignore field indicates the number of invalid data bytes transferred. This message shall be sent immediately following the DATA IN phase by the target and prior to any other messages. The initiator shall indicate its intent to send this message by asserting the ATN signal before asserting ACK for the last transfer of a REQ/ACK-REQB/ACKB handshake of a data or nexus transfer phase. The ignore field is defined as follows: .kp on Invalid Data Bits Ignore 32-bit Transfers 16-bit Transfers ---------- ---------------- ---------------- 00h Reserved Reserved 01h DB(31-24) DB(15-8) 02h DB(31-16) Reserved 03h DB(31-8) Reserved 04h to FFh Reserved Reserved .kp off Even though a byte is invalid its corresponding parity bit shall be valid for the value transferred. For 16-bit transfers, DB(31-16) are always invalid and the corresponding parity bits are also invalid. 5.y.x. INFORMATION PACKET IDENTIFY This message shall be supported if the nexus transfer phase is supported. This message shall not be transmitted using the message phase. The INFORMATION PACKET IDENTIFY message (Table 5-x) is sent by either the initiator or the target to establish an H_C_L nexus, an H_C_R nexus, an I_T_L nexus or an I_T_R nexus. The message is also used to specify certain options about the connection. In configurations which support multiple path operations, this message is used to permit or prevent the two types of nexus which are possible. In addition, the message is used to enable the target controller to execute supervisor commands. .kp on Table 5-x: INFORMATION PACKET IDENTIFY Message Format ============================================================================== Byte | Value | Description | ============================================================================== 0 | 01h | Extended message | ----------|----------|-------------------------------------------------------| 1 | 08h | Extended message length | ----------|----------|-------------------------------------------------------| 2 | 05h | Extended message code | ----------|----------|-------------------------------------------------------| 3 | x | Connection Conditions (See Table 5-x) | ----------|----------|-------------------------------------------------------| 4 | x | LUNTRNID (See Table 5-x) | ----------|----------|-------------------------------------------------------| 5 | x | Initiator SCSI Address | ----------|----------|-------------------------------------------------------| 6 | x | Target SCSI Address | ----------|----------|-------------------------------------------------------| 7 | 00h | Reserved | ============================================================================== .kp off .kp on Table 5-x: Connection Conditions ============================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | ============================================================================== 0 |DiscPriv| LUNTAR |SuspMpth|EnbSpvr |Reserved|Reserved|Reserved|Reserved| ============================================================================== .kp off A disconnect privilege (DiscPriv) bit of one specifies that the initiator has granted the target the privilege of disconnecting. A DiscPriv bit of zero specifies that the target shall not disconnect. When sent by a target during a reconnection, the value of this bit shall be the same as the most recent value received for this I/O process. For serial bus implementations, the initiator shall always set this bit to 1. A logical unit target (LUNTAR) bit of zero specifies that the I/O process is directed to or from a logical unit. A LUNTAR bit of one specifies that the I/O process is directed to or from a target routine. The logical unit or target routine is identified in the LUNTRNID field. When sent by a target during a reconnection, the value of this bit shall be the same as the most recent value received for this I/O process. A suspend multiple path (SuspMpth) bit of one specifies that the initiator requires the target controller to override multiple path operation. The effect is to form an H_I_T_C nexus from the H_C nexus. The multiple path operation is interpreted for each nexus. The setting has no effect on any other active or queued I/O process in the target controller. A enable supervisor command (EnbSpvr) bit of one specifies that the initiator has granted the target the privilege of executing any valid supervisor command received during the I/O process in which the enable supervisor command bit is set to 1. If the bit is set to zero and a supervisor command is present in the I/O process, the target controller shall terminate the I/O process with CHECK CONDITION status and prepare sense data. The sense key shall be set to ILLEGAL REQUEST and the additional sense code shall be set to SUPERVISOR COMMANDS NOT ENABLED. The enable supervisor command bit setting is interpreted for each nexus. The setting has no effect on any other active or queued I/O process in the target controller. .kp on Table 5-x: LUNTAR ID ============================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | ============================================================================== 0 | LUNTRNID | ============================================================================== .kp off The logical unit number target routine number (LUNTRNID) field specifies a logical unit number if the LUNTAR bit is zero. The LUNTRNID field specifies a target routine number if the LUNTAR bit is one. The response to an invalid value in the LUNTRNID field is described in 6.5.3. The Initiator SCSI Address is a number in the range of 0 to 15 which specifies the SCSI Address assigned to the SCSI device initiating an I/O process. Values 16 through 255 are reserved. The Target SCSI Address is a number in the range of 0 to 15 which specifies the SCSI Address assigned to the SCSI device selected to perform an I/O process. Values 16 through 255 are reserved. An INFORMATION PACKET IDENTIFY message is invalid if a reserved bit is set to one, or if the LUNTAR bit is set to one and the target does not implement target routines, or on any subsequent connection after the connect for either the initiator or target to change the value of the SuspMpth or EnbSpvr bits. A target may respond to an invalid INFORMATION PACKET IDENTIFY message by sending an EXTENDED MESSAGE REJECT message in an information packet or by returning CHECK CONDITION status and sense data in an information packet. The sense key shall be set to ILLEGAL REQUEST and the additional sense code shall be set to INVALID BITS IN INFORMATION PACKET IDENTIFY MESSAGE FIELD. An initiator shall respond with an appropriate abort message in an information packet. The target aborts the I/O process and prepares sense data. Only one logical unit number or target routine number shall be identified per information packet. A second INFORMATION PACKET IDENTIFY message with a different value in either the LUNTAR bit or LUNTRNID field shall not be issued within the same information packet. If a target receives a second INFORMATION PACKET IDENTIFY message in one information packet with a different value in either of these fields, it shall not process the content of an information packet beyond the point of the invalid INFORMATION PACKET IDENTIFY message. Thus, for parallel interfaces, an initiator may change the DiscPriv bit, but may not attempt to switch to another I/O process. (See the DTDC field of the disconnect-reconnect page (7.3.3.2) for additional controls over disconnection.) Different information packets during a connection may have different logical units and/or target routines identified. An implied RESTORE POINTERS message shall be performed by the initiator for each inbound information packet. 5.y.9. INITIATE RECOVERY A target that supports extended contingent allegiance shall inform the initiator it is entering this condition by sending an INITIATE RECOVERY message immediately following a CHECK CONDITION or COMMAND TERMINATED status. The extended contingent allegiance condition remains in effect until terminated as described in 6.7. If an asynchronous event occurs, the target may enter an extended contingent allegiance condition by becoming a temporary initiator and sending the INITIATE RECOVERY message following the IDENTIFY message or INFORMATION PACKET IDENTIFY message, as appropriate, followed by any queue tag message and then the SEND command that is used to perform asynchronous event notification (see 6.5.5). The successful transmission of this message establishes the extended contingent allegiance condition which remains in effect until terminated as described in 6.7. If the target notifies multiple initiators of the asynchronous event, it may include the INITIATE RECOVERY message in each notification, depending on the target controllers ability to manage recovery by multiple initiators (e.g., a buffered mode setting of 2 for sequential access devices). A MESSAGE REJECT response to an INITIATE RECOVERY message indicates that an extended contingent allegiance condition shall not be established. The enabled or disabled state of an extended contingent allegiance (see the DQue bit of the control mode page, 7.3.3.1) is not changed by the rejection of an INITIATE RECOVERY message. 5.y.10. INITIATOR DETECTED ERROR The INITIATOR DETECTED ERROR message is sent from an initiator to inform a target that an error has occurred that does not preclude the target from retrying the operation. The source of the error may either be related to previous activities on the SCSI bus or may be internal to the initiator and unrelated to any previous SCSI bus activity. Although present pointer integrity is not assured, a RESTORE POINTERS message or a disconnect followed by a reconnect, shall cause the pointers to be restored to their defined prior state. See the INVALID BUS PHASE DETECTED, MESSAGE PARITY ERROR, PARITY ERROR, and RESEND LAST INFORMATION PACKET messages for specific conditions which shall be reported using these messages. .kp on 5.y.xx. INVALID BUS PHASE DETECTED Table 5-x: INVALID BUS PHASE DETECTED Message Format ============================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | ============================================================================== 0 | Message Code (25h) | -----|-----------------------------------------------------------------------| 1 | RESERVED | Msg | C/D | I/O | ============================================================================== .kp off The INVALID BUS PHASE DETECTED message is sent from an initiator to inform a target that an illegal or reserved bus phase was detected. Table 5-x defines the format for the INVALID BUS PHASE DETECTED message. If a SCSI device does not implement INVALID BUS PHASE DETECTED message, it shall respond with a MESSAGE REJECT message. The Msg bit shall contain 1 if the phase where the phase error was detected has the MSG signal set to true. Otherwise, the Msg bit shall be set to zero. The C/D bit shall contain 1 if the phase where the phase error was detected has the C/D signal set to true. Otherwise, the C/D bit shall be set to zero. The I/O bit shall contain 1 if the phase where the phase error was detected has the I/O signal set to true. Otherwise, the I/O bit shall be set to zero. The three bits identify the phase code which was detected in error. 5.y.x. INVALID INFORMATION PACKET This message shall be supported if the nexus transfer phase is supported. This message shall not be transmitted using the message phase. The INVALID INFORMATION PACKET message (Table 5-x) is sent from either the initiator or target in an information packet to indicate that all or a portion of the last information packet transferred was invalid. The format of the information packet does not conform to the rules for information packet construction. In order to indicate its intentions of sending an information packet containing this message, the initiator shall assert the ATN signal. The target enters the NEXUS TRANSFER OUT phase at the end of the current nexus transfer phase. If the target receives this message in an information packet under any other circumstance, it shall reject this message. When a target sends this message, it shall change to NEXUS TRANSFER IN phase and send an information packet containing this message the initiator. .kp on Table 5-x: INVALID INFORMATION PACKET Message Format ============================================================================== Byte | Value | Description | ============================================================================== 0 | 01h | Extended message | ----------|----------|-------------------------------------------------------| 1 | 04h | Extended message length | ----------|----------|-------------------------------------------------------| 2 | 06h | Extended message code | ----------|----------|-------------------------------------------------------| 3 | x | ILE Number | ----------|----------|-------------------------------------------------------| 4 | x | Reason Code | ============================================================================== .kp off The ILE Number is the position of the interface logical element group within the information packet containing the error. The ILE number is a value in the range of 1 to 255. There may be more than one message interface logical element in each information packet. The Reason Code identifies the reason for sending the message. A code of 00h indicates the first interface logical element is not a message type. A code of 01h indicates that the interface logical element type in a descriptor is invalid. Reason code 00h is used to specifically identify an error in the first interface logical element. A code of 02h indicates that the interface logical element length field is invalid. Codes 03h-FFh are reserved. 5.y.11. LINKED COMMAND COMPLETE The LINKED COMMAND COMPLETE message is sent from a target to an initiator to indicate that the execution of a linked command has completed and that status has been sent. The initiator shall then set the pointers to the initial state for the next linked command. 5.y.12. LINKED COMMAND COMPLETE (WITH FLAG) The LINKED COMMAND COMPLETE (WITH FLAG) message is sent from a target to an initiator to indicate that the execution of a linked command (with the flag bit set to one) has completed and that status has been sent. The initiator shall then set the pointers to the initial state of the next linked command. Typically this message would be used to cause an interrupt in the initiator between two linked commands. 5.y.13. MESSAGE PARITY ERROR This message is retained for backward compatibility with SCSI-2. SCSI-3 implementations of initiators and targets which implement the nexus transfer phase shall use the PARITY ERROR message when operating with that phase. The MESSAGE PARITY ERROR message is sent by an initiator or a target to indicate that a message byte it received had a parity error. The procedures outlined below replace those described in Section 5.1.9.2 with a symmetrical procedure for both initiators and targets. 5.y.13.1 Initiator Detected Parity Errors In order to indicate its intentions of sending this message, the initiator shall assert the ATN signal prior to its release of the ACK signal for the REQ/ACK handshake of the message byte that has the parity error. This provides an interlock so that the target can determine, before the end of the MESSAGE IN phase, that the messages must be kept until the ATN signal has been responded to. If the target receives this message under any other circumstance, it shall signal a catastrophic error condition by switching to the MESSAGE IN phase and sending the MESSAGE REJECT message. The target shall return to the MESSAGE IN phase before switching to some other phase, after receiving the MESSAGE PARITY ERROR message, and the target shall resend the entire set of messages that had at least one parity error. 5.y.13.2 Target Detected Parity Errors In order to indicate its intentions of sending this message, the target shall switch to the MESSAGE IN phase after the ATN signal has gone false for the last REQ/ACK handshake of the MESSAGE OUT phase where the parity error was detected, but before changing to any other phase. This provides an interlock so that the initiator can determine before it loses access to the messages that they must be kept until the MESSAGE IN phase has been responded to. If the initiator receives this message under any other circumstance, it shall signal a catastrophic error condition by asserting the ATN signal and transferring a MESSAGE REJECT message. The target shall return to the MESSAGE OUT phase before switching to some other phase, after sending the MESSAGE PARITY ERROR message, and the initiator shall resend the entire set of messages that had at least one parity error. 5.y.14. MESSAGE REJECT This message is retained for backward compatibility with SCSI-2. SCSI-3 implementations of initiators and targets which implement the nexus transfer phase shall use the EXTENDED MESSAGE REJECT message when operating with that phase. The MESSAGE REJECT message is sent from either the initiator or target using the message phases to indicate that the last message or message byte it received was inappropriate or has not been implemented. See also the EXTENDED MESSAGE REJECT message. In order to indicate its intentions of sending this message, the initiator shall assert the ATN signal prior to its release of the ACK signal for the REQ/ACK handshake of the message byte that is to be rejected. If the target receives this message under any other circumstance, it shall reject this message. When a target sends this message, it shall change to MESSAGE IN phase and send this message prior to requesting additional message bytes from the initiator. This provides an interlock so that the initiator can determine which message byte is rejected. After a target sends a MESSAGE REJECT message and if the ATN signal is still asserted, then it shall return to the MESSAGE OUT phase. The subsequent MESSAGE OUT phase shall begin with the first byte of a message. .kp on 5.y.15. MODIFY DATA POINTER Message Table 5-7: MODIFY DATA POINTER ============================================================================== Byte | Value | Description | ============================================================================== 0 | 01h | Extended message | -----|---------|-------------------------------------------------------------| 1 | 05h | Extended message length | -----|---------|-------------------------------------------------------------| 2 | 00h | MODIFY DATA POINTER code | -----|---------|-------------------------------------------------------------| 3 | x | Argument (Most Significant Byte) | -----|---------|-------------------------------------------------------------| 4 | x | Argument | -----|---------|-------------------------------------------------------------| 5 | x | Argument | -----|---------|-------------------------------------------------------------| 6 | x | Argument (Least Significant Byte) | ============================================================================== .kp off The MODIFY DATA POINTER message (Table 5-7) is sent from the target to the initiator and requests that the signed argument be added (two's complement) to the value of the current data pointer. This message shall be used with the nexus transfer phase instead of the SAVE DATA POINTER, RESTORE POINTERS, and DISCONNECT messages to control or adjust the data pointer value for a current I/O process. 5.y.16. NO OPERATION The NO OPERATION message is sent from an initiator in response to a target's request for a message using the MESSAGE OUT phase when the initiator does not currently have any other valid message to send. For example, if the target does not respond to the attention condition until a later phase and at that time the original message is no longer valid the initiator may send the NO OPERATION message when the target enters the MESSAGE OUT phase. .kp on 5.y.xx. PARITY ERROR Table 5-x: PARITY ERROR Message Format ============================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | ============================================================================== 0 | Message Code (24h) | -----|-----------------------------------------------------------------------| 1 | RESERVED | Msg | C/D | I/O | ============================================================================== .kp off Table 5-x defines the format for the parity error message. If a SCSI device does not implement PARITY ERROR message, it shall respond with a MESSAGE REJECT message. The Msg bit shall contain 1 if the invalid phase detected has the MSG signal set to true. Otherwise, the Msg bit shall be set to zero. The C/D bit shall contain 1 if the invalid phase detected has the C/D signal set to true. Otherwise, the C/D bit shall be set to zero. The I/O bit shall contain 1 if the invalid phase detected has the I/O signal set to true. Otherwise, the I/O bit shall be set to zero. The three bits identify the phase in which the parity error was detected. 5.y.xx.1. Initiator Detected Parity Errors for MESSAGE Phase In order to indicate its intentions of sending this message, the initiator shall assert the ATN signal prior to its release of the ACK signal for the REQ/ACK handshake of the message byte that has the parity error. This provides an interlock so that the target can determine, before the end of the MESSAGE IN phase, that the messages must be kept until the ATN signal has been responded to. If the target receives this message under any other circumstance, it shall signal a catastrophic error condition by switching to the MESSAGE IN phase and sending the MESSAGE REJECT message. The target shall return to the MESSAGE IN phase before switching to some other phase, after receiving the PARITY ERROR message, and the target shall resend the entire set of messages that had at least one parity error. 5.y.xx.2. Target Detected Parity Errors for MESSAGE Phase In order to indicate its intentions of sending this message, the target shall switch to the MESSAGE IN phase after the ATN signal has gone false for the last REQ/ACK handshake of the MESSAGE OUT phase where the parity error was detected, but before changing to any other phase. This provides an interlock so that the initiator can determine before it loses access to the messages that they must be kept until the MESSAGE IN phase has been responded to. If the initiator receives this message under any other circumstance, it shall signal a catastrophic error condition by asserting the ATN signal and transferring a MESSAGE REJECT message. The target shall return to the MESSAGE OUT phase before switching to some other phase, after sending the PARITY ERROR message, and the initiator shall resend the entire set of messages that had at least one parity error. .kp on 5.y.17. Queue Tag Messages Table 5-8: Queue Tag Message Format ============================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | ============================================================================== 0 | Message Code (20h or 21h or 22h) | -----|-----------------------------------------------------------------------| 1 | Queue Tag | ============================================================================== .kp off Table 5-8 defines the format for the queue tag messages. If the target implements tagged queuing, all of the queue tag messages are mandatory: HEAD OF QUEUE TAG, ORDERED QUEUE TAG, and SIMPLE QUEUE TAG. Tagged queuing is only defined for logical units, not target routines. If a target does not implement tagged queuing and a queue tag message is received or if a queue tag message is received for a target routine, it shall respond with a MESSAGE REJECT message and accept the I/O process as if it were untagged. The queue tag messages are used to specify an identifier, called a queue tag, for an I/O process which establishes an H_C_L_Q nexus or an I_T_L_Q nexus. The queue tag field is an 8-bit unsigned integer assigned by the initiator during an initial connection. The queue tag for every I/O process for each should be unique. If the target receives a queue tag from a host system that is currently in use, then it shall respond as defined in 6.5.2. A queue tag becomes available for re-assignment when the I/O process ends. The numeric value of a queue tag has no effect on the order of execution. IMPLEMENTORS NOTE: For each logical unit on each target, each initiator has up to 256 queue tags to assign to I/O processes. Thus a target with eight logical units could have up to 14336 I/O processes concurrently in existence if there were seven initiators on the bus. Whenever an initiator connects to a target, the appropriate queue tag message shall be sent immediately following the IDENTIFY message and within the same message interface logical element or MESSAGE OUT phase to establish the H_C_L_Q nexus or I_T_L_Q nexus for the I/O process. Only one H_C_L_Q nexus or I_T_L_Q nexus may be established during a connection. If a queue tag message is not sent, then only an H_C_L nexus or I_T_x nexus is established for the I/O process (untagged command). Whenever a target reconnects to an initiator to continue a tagged I/O process, the SIMPLE QUEUE TAG message shall be sent immediately following the IDENTIFY message and within the same MESSAGE IN phase to revive the H_C_L_Q nexus or I_T_L_Q nexus for the I/O process. Only one H_C_L_Q nexus or I_T_L_Q nexus may be revived during a reconnection. If the SIMPLE QUEUE TAG message is not sent, then only an H_C_L nexus or an I_T_x nexus is revived for the I/O process (untagged command). If a target attempts to reconnect using an invalid queue tag, then the initiator should respond with an ABORT TAG message. 5.y.17.1. HEAD OF QUEUE TAG The HEAD OF QUEUE TAG message specifies that the I/O process be placed first in that logical unit's command queue. An I/O process already being executed by the target shall not be preempted. A subsequent I/O process received with a HEAD OF QUEUE TAG message shall be placed at the head of the command queue for execution in last-in, first-out order. 5.y.17.2. ORDERED QUEUE TAG The ORDERED QUEUE TAG message specifies that the I/O process be placed in that logical unit's command queue for execution in the order received. All queued I/O processes for the logical unit received prior to this I/O process shall be executed before this I/O process is executed. All queued I/O processes received after this I/O process shall be executed after this I/O process, except for I/O processes received with a HEAD OF QUEUE TAG message. 5.y.17.3. SIMPLE QUEUE TAG The SIMPLE QUEUE TAG message specifies that the I/O process be placed in that logical unit's command queue. The order of execution is described in 6.8. 5.y.18. RELEASE RECOVERY The RELEASE RECOVERY message is sent from an initiator to a target to terminate an extended contingent allegiance condition previously established by an INITIATE RECOVERY message. This message shall be sent immediately following the IDENTIFY message in the same MESSAGE OUT phase or interface logical element in an information packet. The extended contingent allegiance condition ends upon successful receipt of the RELEASE RECOVERY message. The target shall go to the BUS FREE phase following successful receipt of this message using the MESSAGE OUT phase. If a RELEASE RECOVERY message is received by a target that implements extended contingent allegiance when no extended contingent allegiance condition is active, the message shall not be rejected and the target shall go to the BUS FREE phase. .kp on 5.y.xx. RESEND PREVIOUS INFORMATION PACKET Table 5-8: Resend Previous Information Packet Message Format ============================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | ============================================================================== 0 | Message Code (26h) | -----|-----------------------------------------------------------------------| 1 | Previous Packet number | ============================================================================== .kp off This message shall be supported if the nexus transfer phase is supported. This message shall not be transmitted using the MESSAGE phase. The RESEND PREVIOUS INFORMATION PACKET message is sent by an initiator or a target to indicate that a previous information packet must be resent. The synchronous packet transfer request negotiation has produced an agreement on the maximum number of packets to be retained by both the host system and the target controller. A value of zero in the previous packet number field causes the device to resend the last information packet transferred. Values of 1 through 255 represent the 2nd to 256th most recent packets transmitted. It shall be an error for a device to transmit a value in this field which is larger than the limit negotiated using the SYNCHRONOUS PACKET TRANSFER REQUEST message (5.y.xx). 5.y.19. RESTORE POINTERS The RESTORE POINTERS message is sent from a target using the MESSAGE IN phase to direct the initiator to copy the most recently saved command, data, and status pointers for the I/O process to the corresponding active pointers. (See 5.4 for a definition of pointers.) The command and status pointers shall be restored to the beginning of the current command and status areas. The data pointer shall be restored to the value at the beginning of the data area in the absence of a SAVE DATA POINTER message or to the value at the point at which the last SAVE DATA POINTER message occurred for that nexus. This message shall not be sent using the NEXUS TRANSFER IN phase. 5.y.20. SAVE DATA POINTER The SAVE DATA POINTER message is sent from a target using a MESSAGE IN phase to direct the initiator to copy the active data pointer to the saved data pointer for the current I/O process. (See 5.4 for a definition of pointers.) This message shall not be sent using the NEXUS TRANSFER IN phase. .kp on 5.y.21. SYNCHRONOUS DATA TRANSFER REQUEST Message Table 5-9: SYNCHRONOUS DATA TRANSFER REQUEST ============================================================================== Byte | Value | Description | ============================================================================== 0 | 01h | Extended message | -----|---------|-------------------------------------------------------------| 1 | 03h | Extended message length | -----|---------|-------------------------------------------------------------| 2 | 01h | SYNCHRONOUS DATA TRANSFER REQUEST code | -----|---------|-------------------------------------------------------------| 3 | m | Transfer period (m times 4 nanoseconds) | -----|---------|-------------------------------------------------------------| 4 | x | REQ/ACK offset | ============================================================================== .kp off A SYNCHRONOUS DATA TRANSFER REQUEST (SDTR) message (Table 5-9) exchange shall be initiated by an SCSI device whenever a previously-arranged data transfer agreement may have become invalid. The agreement becomes invalid after any condition which may leave the data transfer agreement in an indeterminate state such as: (1) after a hard reset condition (2) after a BUS DEVICE RESET message and (3) after a power cycle. In addition, an SCSI device may initiate an SDTR message exchange whenever it is appropriate to negotiate a new data transfer agreement (either synchronous or asynchronous). SCSI devices that are capable of synchronous data transfers shall not respond to an SDTR message with a MESSAGE REJECT message. The SDTR message exchange establishes the permissible transfer periods and the REQ/ACK offsets for all logical units and target routines on the two devices. This agreement only applies to data phases. The transfer period is the minimum time allowed between leading edges of successive REQ pulses and of successive ACK pulses to meet the device requirements for successful reception of data. The REQ/ACK offset is the maximum number of REQ pulses allowed to be outstanding before the leading edge of its corresponding ACK pulse is received at the target. This value is chosen to prevent overflow conditions in the device's reception buffer and offset counter. A REQ/ACK offset value of zero shall indicate asynchronous data transfer mode; a value of FFh shall indicate unlimited REQ/ACK offset. The originating device (the device that sends the first of the pair of SDTR messages) sets its values according to the rules above to permit it to receive data successfully. If the responding device can also receive data successfully with these values (or smaller transfer periods or larger REQ/ACK offsets or both), it returns the same values in its SDTR message. If it requires a larger transfer period, a smaller REQ/ACK offset, or both in order to receive data successfully, it substitutes values in its SDTR message as required, returning unchanged any value not required to be changed. Each device when transmitting data shall respect the limits set by the other's SDTR message, but it is permitted to transfer data with larger transfer periods, smaller REQ/ACK offsets, or both than specified in the other's SDTR message. The successful completion of an exchange of SDTR messages implies an agreement as follows: .kp on Responding Device SDTR response Implied Agreement ------------------------------- ------------------------------------------- (1) Non-zero REQ/ACK offset Each device transmits data with a transfer period equal to or greater than and a REQ/ACK offset equal to or less than the values received in the other device's SDTR message. (2) REQ/ACK offset equal to zero Asynchronous transfer (3) MESSAGE REJECT message Asynchronous transfer .kp off If the initiator recognizes that negotiation is required, it asserts the ATN signal and sends a SDTR message to begin the negotiating process. After successfully completing the MESSAGE OUT phase, the target shall respond with the proper SDTR message. If an abnormal condition prevents the target from returning an appropriate response, both devices shall go to asynchronous data transfer mode for data transfers between the two devices. Following target response (1) above, the implied agreement for synchronous operation shall be considered to be negated by both the initiator and the target if the initiator asserts the ATN signal and the first message out is either MESSAGE PARITY ERROR or MESSAGE REJECT. In this case, both devices shall go to asynchronous data transfer mode for data transfers between the two devices. For the MESSAGE PARITY ERROR case, the implied agreement shall be reinstated if a re-transmittal of the second of the pair of messages is successfully accomplished. After a vendor-specific number of retry attempts (greater than zero), if the target receives a MESSAGE PARITY ERROR message, it shall terminate the retry activity. This may be done either by changing to any other information transfer phase and transferring at least one byte of information or by going to the BUS FREE phase (see 5.1.1). The initiator shall accept such action as aborting the negotiation, and both devices shall go to asynchronous data transfer mode for data transfers between the two devices. If the target recognizes that negotiation is required, it sends an SDTR message to the initiator. Prior to releasing the ACK signal on the last byte of the SDTR message from the target, the initiator shall assert the ATN signal and respond with its SDTR message or with a MESSAGE REJECT message. If an abnormal condition prevents the initiator from returning an appropriate response, both devices shall go to asynchronous data transfer mode for data transfers between the two devices. Following an initiator's responding SDTR message, an implied agreement for synchronous operation shall not be considered to exist until the target leaves the MESSAGE OUT phase, indicating that the target has accepted the negotiation. After a vendor-specific number of retry attempts (greater than zero), if the target has not received the initiator's responding SDTR message, it shall go to the BUS FREE phase without any further information transfer attempt (see 5.1.1). This indicates that a catastrophic error condition has occurred. Both devices shall go to asynchronous data transfer mode for data transfers between the two devices. If, following an initiator's responding SDTR message, the target shifts to MESSAGE IN phase and the first message in is MESSAGE REJECT, the implied agreement shall be considered to be negated and both devices shall go to asynchronous data transfer mode for data transfers between the two devices. For initiators and targets using the nexus transfer phases, the appropriately formatted messages are sent in information packets rather than using the message phases. The logical outcome is the same. The implied synchronous agreement shall remain in effect until a BUS DEVICE RESET message is received, until a hard reset condition occurs, or until one of the two SCSI devices elects to modify the agreement. The default data transfer mode is asynchronous data transfer mode. The default data transfer mode is entered at power on, after a BUS DEVICE RESET message, or after a hard reset condition. IMPLEMENTORS NOTES: (1) Re-negotiation at every selection is not recommended, since a significant performance impact is likely. (2) Due to historical problems with early host adapters that could not accept an SDTR message, some targets may not initiate synchronous negotiation after a power cycle as required by this standard. Host adapters that support synchronous mode may avoid the ensuing failure modes when the target is independently power cycled by initiating a synchronous negotiation on each REQUEST SENSE and INQUIRY command. .kp on 5.y.xx. SYNCHRONOUS PACKET TRANSFER REQUEST Message Table 5-x. SYNCHRONOUS PACKET TRANSFER REQUEST ============================================================================== Byte | Value | Description | ============================================================================== 0 | 01h | Extended message | -----|---------|-------------------------------------------------------------| 1 | 03h | Extended message length | -----|---------|-------------------------------------------------------------| 2 | 07h | SYNCHRONOUS PACKET TRANSFER REQUEST code | -----|---------|-------------------------------------------------------------| 3 | 00h | Reserved | -----|---------|-------------------------------------------------------------| 4 | m | Packet Offset count | ============================================================================== .kp off A SYNCHRONOUS PACKET TRANSFER REQUEST (SPTR) message (Table 5-x) exchange shall be initiated by an SCSI device whenever a previously arranged packet transfer agreement may have become invalid. This message shall be implemented if the nexus transfer phase is implemented. This message shall not be transmitted using the MESSAGE phase. Each device shall be able to retain at minimum one information packet per I/O process. In the absence of an explicit agreement for value larger than one, the implied agreement shall be 1 for both initiators and targets. At the end of an exchange, both the host system and target controller agree to maintain, for retransmitting only, a minimum number of information packets (greater than or equal to one). The packet offset count represents n+1 information packets that the host system or target controller declares that it can retain at maximum or has agreed upon with another SCSI device. A maximum of 256 information packets may be retained per I/O process at the end of an SPTR negotiation. The synchronous packet transfer agreement becomes invalid after any condition which may leave the packet transfer agreement in an indeterminate state such as: (1) after a hard reset condition (??? GRS) (2) after a BUS DEVICE RESET message and (3) after a power cycle. In addition, an SCSI device may initiate an SPTR message exchange whenever it is appropriate to negotiate a new packet transfer agreement. The SPTR message exchange establishes the minimum number of information packets that the host system and target controller shall maintain to permit retransmitting in case of physical or logical errors in information packets. This agreement only applies to nexus transfer phases. See the RESENT PREVIOUS INFORMATION PACKET message. The originating device (the device that sends the first of the pair of SDTR messages) sets its values according to its capabilities to retain information packets on a per I/O process basis. If the responding device can also retain information packets at this level, it returns the same values in its SPTR message. If it requires a smaller retention count, it substitutes a lower value in its SPTR message. The originating device analyzes the response and may initiate another SPTR message with the same or a still lower value. The negotiation shall end when both devices exchange the same value or the value reaches 1, whichever occurs first. Each device, when transferring information packets, shall retain the number of information packets for retransmitting, as agreed upon in the most recent SPTR exchange or one, whichever is larger. IMPLEMENTORS NOTE: Re-negotiation at every selection is not recommended, since a significant performance impact is likely. 5.y.22. TERMINATE I/O PROCESS The TERMINATE I/O PROCESS message is sent from the initiator to the target to advise the target to terminate the current I/O process without corrupting the medium. Upon successful receipt of this message the target shall terminate the current I/O process as soon as possible and return COMMAND TERMINATED status. The sense key shall be set to NO SENSE and the additional sense code and qualifier shall be set to I/O PROCESS TERMINATED. The TERMINATE I/O PROCESS message shall not affect pending status, data, and commands for other queued or executing I/O processes. However, continued execution and status of other I/O processes queued for the H_C_x nexus or I_T_x nexus may be affected by the queue error recovery option specified in the control mode page (see 7.3.3.1). If the I/O process that is being terminated has a data transfer associated with it (i.e., DATA IN or DATA OUT phase or nexus transfer phases ), the valid bit in the sense data shall be set to one and the information field shall be set as follows: (1) If the command descriptor block specifies an allocation length or parameter list length in bytes, the information field shall be set to the difference (residue) between the transfer length and the number of bytes successfully transferred. (2) If the command descriptor block specifies a transfer length field, the information field shall be set as defined in the REQUEST SENSE command (see 7.2.14). If the I/O process being terminated has no data transfer associated with it the target shall set the valid bit in the sense data to zero and terminate the I/O process with COMMAND TERMINATED status. The sense key shall be set to NO SENSE and the additional sense code and qualifier shall be set to I/O PROCESS TERMINATED. When any error condition is detected for an I/O process the target shall ignore the TERMINATE I/O PROCESS message and terminate the I/O process with the appropriate error status and sense data for the error condition. If the target completes all processing for a command (i.e., all data has been read, written, or processed) and a TERMINATE I/O PROCESS message is received before the I/O process is terminated, the target shall ignore the TERMINATE I/O PROCESS message and terminate the I/O process in the normal manner. If the target receives a TERMINATE I/O PROCESS message before the command descriptor block is transferred (e.g., before the COMMAND phase) or the message is issued to an H_C_x nexus or an I_T_x nexus that does not have an active or queued I/O process, the target shall set the valid bit in the sense data to zero and terminate the I/O process with COMMAND TERMINATED status. The sense key shall be set to NO SENSE and the additional sense code and qualifier shall be set to I/O PROCESS TERMINATED. If the current I/O process is in the command queue (an H_C_x nexus or I_T_x nexus for untagged queuing or an H_C_L_Q nexus or I_T_L_Q nexus for tagged queuing) and has not started execution, the target shall either terminate the I/O process immediately or disconnect and wait until the command is at the head of the queue (started executing) then terminate the I/O process. In either case, the target shall terminate the I/O process with COMMAND TERMINATED status. The sense key shall be set to NO SENSE and the additional sense code and qualifier shall be set to I/O PROCESS TERMINATED. The valid bit shall be set to zero. If the target does not support this message or is unable to stop the current I/O process for the H_C_x nexus or I_T_x nexus, it shall respond by sending a MESSAGE REJECT message to the initiator and continuing the I/O process in a normal manner. IMPLEMENTORS NOTE: The TERMINATE I/O PROCESS message provides a means for the initiator to request the target to reduce the transfer length of the current command to the amount that has already been transferred. The initiator can use the sense data to determine the actual number of bytes or blocks that have been transferred. This message is normally used by the initiator to stop a lengthy read, write, or verify operation when a higher priority command is available to be executed. It is up to the initiator to complete the terminated command at a later time, if required. .kp on 5.y.23. WIDE DATA TRANSFER REQUEST Message Table 5-10: WIDE DATA TRANSFER MESSAGE ============================================================================== Byte | Value | Description | ============================================================================== 0 | 01h | Extended message | -----|---------|-------------------------------------------------------------| 1 | 02h | Extended message length | -----|---------|-------------------------------------------------------------| 2 | 03h | WIDE DATA TRANSFER REQUEST code | -----|---------|-------------------------------------------------------------| 3 | m | Transfer Width (2**m bytes) | ============================================================================== .kp off A WIDE DATA TRANSFER REQUEST (WDTR) message (Table 5-10) exchange shall be initiated by an SCSI device whenever a previously-arranged transfer width agreement may have become invalid. The agreement becomes invalid after any condition which may leave the data transfer agreement in an indeterminate state such as: (1) after a hard reset condition (2) after a BUS DEVICE RESET message and (3) after a power cycle. In addition, an SCSI device may initiate an WDTR message exchange whenever it is appropriate to negotiate a new transfer width agreement. SCSI devices that are capable of wide data transfers (greater than eight bits) shall not respond to an WDTR message with a MESSAGE REJECT message. IMPLEMENTORS NOTE: Re-negotiation at every selection is not recommended, since a significant performance impact is likely. The WDTR message exchange establishes an agreement between two SCSI devices on the width of the data path to be used for DATA phase transfers between the two devices. This agreement applies to DATA IN and DATA OUT phases only. All other information transfer phases shall use an eight-bit data path. If an SCSI device implements both wide data transfer option and synchronous data transfer option, then it shall negotiate the wide data transfer agreement prior to negotiating the synchronous data transfer agreement. If a synchronous data transfer agreement is in effect, then an SCSI device that accepts a WDTR message shall reset the synchronous agreement to asynchronous mode. The transfer width that is established applies to all logical units on both SCSI devices. Valid transfer widths are 8 bits (m = 00h), 16 bits (m = 01h), and 32 bits (m = 02h). Values of m greater than 02h are reserved. The originating SCSI device (the SCSI device that sends the first of the pair of WDTR messages) sets its transfer width value to the maximum data path width it elects to accommodate. If the responding SCSI device can also accommodate this transfer width, it returns the same value in its WDTR message. If it requires a smaller transfer width, it substitutes the smaller value in its WDTR message. The successful completion of an exchange of WDTR messages implies an agreement as follows: .kp on Responding Device WDTR Response Implied Agreement -------------------------------- ------------------------------------------- (1) Non-zero transfer width Each device transmits and receives data with a transfer width equal to the responding SCSI device's transfer width. (2) Transfer width equal to zero Eight-bit Data Transfer (3) MESSAGE REJECT message Eight-bit Data Transfer .kp off If the initiator recognizes that negotiation is required, it asserts the ATN signal and sends a WDTR message to begin the negotiating process. After successfully completing the MESSAGE OUT phase, the target shall respond with the proper WDTR message. If an abnormal condition prevents the target from returning an appropriate response, both devices shall go to eight-bit data transfer mode for data transfers between the two devices. Following target response (1) above, the implied agreement for wide data transfers shall be considered to be negated by both the initiator and the target if the initiator asserts ATN and the first message out is either MESSAGE PARITY ERROR or MESSAGE REJECT. In this case, both devices shall go to eight-bit data transfer mode for data transfers between the two devices. For the MESSAGE PARITY ERROR case, the implied agreement shall be reinstated if a re-transmittal of the second of the pair of messages is successfully accomplished. After a vendor-specific number of retry attempts (greater than zero), if the target receives a MESSAGE PARITY ERROR message, it shall terminate the retry activity. This may be done either by changing to any other information transfer phase and transferring at least one byte of information or by going to the BUS FREE phase (see 5.1.1). The initiator shall accept such action as aborting the negotiation, and both devices shall go to eight-bit data transfer mode for data transfers between the two devices. If the target recognizes that negotiation is required, it sends a WDTR message to the initiator. Prior to releasing the ACK signal on the last byte of the WDTR message from the target, the initiator shall assert the ATN signal and respond with its WDTR message or with a MESSAGE REJECT message. If an abnormal condition prevents the initiator from returning an appropriate response, both devices shall go to eight-bit data transfer mode for data transfers between the two devices. Following an initiator's responding WDTR message, an implied agreement for wide data transfer operation shall not be considered to exist until the target leaves the MESSAGE OUT phase, indicating that the target has accepted the negotiation. After a vendor-specific number of retry attempts (greater than zero), if the target has not received the initiator's responding WDTR message, it shall go to the BUS FREE phase without any further information transfer attempt (see 5.1.1). This indicates that a catastrophic error condition has occurred. Both devices shall go to eight-bit data transfer mode for data transfers between the two devices. If, following an initiator's responding WDTR message, the target shifts to MESSAGE IN phase and the first message in is MESSAGE REJECT, the implied agreement shall be considered to be negated and both devices shall go to eight-bit data transfer mode for data transfers between the two devices. For initiators and targets using the nexus transfer phases, the appropriately formatted messages are sent in information packets rather than using the message phases. The logical outcome is the same. The implied transfer width agreement shall remain in effect until a BUS DEVICE RESET message is received, until a hard reset condition occurs, or until one of the two SCSI devices elects to modify the agreement. The default data transfer width is eight-bit data transfer mode. The default data transfer mode is entered at power on, after a BUS DEVICE RESET message, or after a hard reset condition. 6. SCSI Commands and Status This section defines the SCSI command structure, the status structure, status content, the contingent allegiance condition, the extended contingent allegiance condition, and the unit attention condition; gives information on processing and exception conditions, and command queueing; and provides several examples. By keeping to a minimum the functions essential to communicate via this protocol, a wide range of peripheral devices of varying capability can operate in the same environment. Because subsets of the full architecture may be implemented, optional functions are noted. A device class is defined as a group of devices that implement the mandatory commands and functions in Sections 5 through 7 and the mandatory commands and functions defined in one of the sections, 8 through 17. Multiple device class implementations are .... (??? GRS) A device type is defined as a specific implementation within a device class. Each device type may implement different optional features of its device class, but it implements the mandatory commands and functions in Sections 5 through 7 and the mandatory commands and functions in the appropriate section for its device class. 6.1. Command Implementation Requirements The first byte of all SCSI commands shall contain an operation code as defined in this standard. All SCSI devices which implement target mode shall implement all commands with a mandatory operation code (see 6.1.2) both in section 7 and in the appropriate section for their device class. 6.1.1. Reserved Reserved bits, fields, bytes, and code values are set aside for future standardization. Their use and interpretation may be specified by future extensions to this standard. A reserved bit, field, or byte shall be set to zero, or in accordance with a future extension to this standard. A target that receives a reserved bit, field, or byte that is not zero or receives a reserved code value shall terminate the command with CHECK CONDITION status and the sense key shall be set to ILLEGAL REQUEST. It shall also be acceptable for a target to interpret a bit, field, byte, or code value in accordance with a future extension to this standard. 6.1.2. Operation Code Types Operation Code Type Description --------- ------------------------------------------------------------------- M Mandatory - Commands so designated shall be implemented in order to meet the minimum requirement of this standard. O Optional - Commands so designated, if implemented, shall be implemented as defined in this standard. V Vendor specific - Operation codes so designated are available for vendor defined commands. See the vendor specifications where compatibility is desired. R Reserved - Operation codes so designated shall not be used. They are reserved for future extensions to this standard. 6.2. Command Descriptor Block A command is communicated by sending a command descriptor block to the target. For several commands, the command descriptor block is accompanied by command parameter data. See the specific commands for detailed information about which commands require command parameter data. Command parameter data is sent either during the DATA OUT phase when the COMMAND phase is used to send the command descriptor block or as an additional interface logical element in the same information packet, in a separate information packet, or split across several information packets. (See 6.2.5.) The command descriptor block shall have the operation code as its first byte and a control byte as its last byte (6.1 and 6.2.7). A parameter is defined as the value of a field. For all commands, if there is an invalid parameter in the command descriptor block, the target shall terminate the command and the I/O process without altering the medium. .kp on Table 6-1: Typical Command Descriptor Block for Six-byte Commands ============================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | ============================================================================== 0 | Operation Code | -----|-----------------------------------------------------------------------| 1 | Reserved | (MSB) | -----|------------------------------ ---| 2 | Logical Block Address (if required) | -----|--- ---| 3 | (LSB) | -----|-----------------------------------------------------------------------| | Transfer Length (if required) | 4 | Command Parameter Data Length(if required) | | Command Response Data Length (if required) | -----|-----------------------------------------------------------------------| 5 | Control | ============================================================================== .kp off .kp on Table 6-2: Typical Command Descriptor Block for Ten-byte Commands ============================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | ============================================================================== 0 | Operation Code | -----|-----------------------------------------------------------------------| 1 | Reserved | Reserved | -----|-----------------------------------------------------------------------| 2 | (MSB) | -----|--- ---| 3 | | -----|--- Logical Block Address (if required) ---| 4 | | -----|--- ---| 5 | (LSB) | -----|-----------------------------------------------------------------------| 6 | Reserved | -----|-----------------------------------------------------------------------| 7 | (MSB) Transfer Length (if required) | -----|--- Command Parameter Data Length(if required) ---| 8 | Command Response Data Length (if required) (LSB) | -----|-----------------------------------------------------------------------| 9 | Control | ============================================================================== .kp off .kp on Table 6-3: Typical Command Descriptor Block for Twelve-byte Commands ============================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | Byte | | | | | | | | | ============================================================================== 0 | Operation Code | -----|-----------------------------------------------------------------------| 1 | Reserved | Reserved | -----|-----------------------------------------------------------------------| 2 | (MSB) | -----|--- ---| 3 | | -----|--- Logical Block Address (if required) ---| 4 | | -----|--- ---| 5 | (LSB) | -----|-----------------------------------------------------------------------| 6 | (MSB) | -----|--- ---| 7 | Transfer Length (if required) | -----|--- Command Parameter Data Length(if required) ---| 8 | Command Response Data Length (if required) | -----|--- ---| 9 | (LSB) | -----|-----------------------------------------------------------------------| 10 | Reserved | -----|-----------------------------------------------------------------------| 11 | Control | ============================================================================== .kp off 6.2.1. Operation Code The operation code (Table 6-4) of the command descriptor block has a group code field and a command code field. The three-bit group code field provides for eight groups of command codes. The five-bit command code field provides for thirty-two command codes in each group. Thus, a total of 256 possible operation codes exist. Operation codes are defined in the subsequent Sections of this document. .sa .fo off .kp on The group code is defined as follows: Group 0 - six-byte commands (see Table 6-1) Group 1 - ten-byte commands (see Table 6-2) Group 2 - ten-byte commands (see Table 6-2) Group 3 - reserved Group 4 - reserved Group 5 - twelve-byte commands (see Table 6-3) Group 6 - vendor specific Group 7 - vendor specific .kp off .re .kp on Table 6-4: Operation Code ============================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ============================================================================== | Group Code | Command Code | ============================================================================== .kp off 6.2.2. Logical Unit Number (Reclaimed Field, Byte 1, bits 7-5) The Logical Unit Number field was defined in all Command Descriptor Blocks through SCSI-2. The field function was replaced by a similar field in the mandatory IDENTIFY message in SCSI-2 to identify logical units and target routines. The field space is reclaimed in the CDB, and made reserved. The logical unit number is transferred in the IDENTIFY message (5.6.7) when the message phase is used for message transfer. When the nexus transfer phase is used, the logical unit number is transferred in the INFORMATION PACKET IDENTIFY message (5.6.xx), which provides for extended addressing of logical units and target routines. 6.2.3. Logical Block Address The logical block address on logical units or within a partition on device volumes shall begin with block zero and be contiguous up to the last logical block on that logical unit or within that partition. Not all device classes support logical block addressing. For those commands providing logical block addresses: a six-byte command descriptor block contains a 21-bit logical block address; a ten-byte or twelve-byte command descriptor block contains a 32-bit logical block address. Logical block addresses in command parameter data have their length specified for each occurrence. See the specific command descriptions. 6.2.4. Transfer Length The transfer length field specifies the amount of data to be transferred, usually the number of blocks. Not all commands provide a transfer length field. For several commands the transfer length indicates the requested number of bytes to be sent as defined in the command description. For these commands the transfer length field may be identified by a different name. See the following descriptions and the individual command descriptions for further information. Commands that use one byte for the transfer length allow up to 256 blocks or bytes of data to be transferred by one command. A transfer length value of 1 to 255 indicates the number of blocks or bytes that shall be transferred. A value of zero indicates 256 blocks or bytes. In commands that use multiple bytes for the transfer length, a transfer length of zero indicates that no data transfer shall take place. A value of one or greater indicates the maximum number of blocks or bytes that shall be transferred. Refer to the specific command descriptions for further information. 6.2.5. Command Parameter Data Length The command parameter data length field is used to specify the maximum number of bytes to be transferred by a target during the data phase after the command descriptor block has been transferred using the COMMAND phase. When the command descriptor block is transferred using the nexus transfer phase, the command parameter data may be included as a subsequent interface logical element in the same information packet, a separate information packet, or split across multiple information packets. This field is typically used in command descriptor blocks for command parameter data that are sent to a target (e.g., mode parameters, diagnostic parameters, log parameters, etc.). A command parameter data length field of zero indicates that no data shall be transferred. This condition shall not be considered as an error. 6.2.6. Command Response Data Length The command response data length field specifies the maximum number of bytes that a target may transfer as command response data. The command response data length is used to limit the amount of command response data (e.g., sense data, mode data, log data, diagnostic data, etc.) returned to an initiator by a target. A command response data length of zero indicates that no data shall be transferred. This condition shall not be considered as an error. When using the data phase to transfer the command response data, the target shall terminate transfer when command response data length bytes have been transferred or when all available data have been transferred to the initiator, whichever is less. When the nexus transfer phase is used to transfer the command response data, the target may place all data in a single information packet, or split the command response data over multiple information packets. 6.2.7. Control Field The control field is the last byte of every command descriptor block (6.2). The control field is defined in Table 6-5. .kp on Table 6-5: Control Field ============================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ============================================================================== | Vendor specific | Reserved | Flag | Link | ============================================================================== .kp off The flag bit specifies which message the target shall return to the initiator if the link bit is one and the command completes without error. Implementation of the flag bit is optional. The flag bit should be set to zero if the link bit is zero. If link bit is zero and the flag bit is one, the target shall return CHECK CONDITION status. The sense key shall be set to ILLEGAL REQUEST. If the flag bit is zero and the link bit is one, and if the command completes successfully, the target shall send the LINKED COMMAND COMPLETE message. If the flag bit is one and the link bit is one, and if the command completes successfully, the target shall send the LINKED COMMAND COMPLETE (WITH FLAG) message. IMPLEMENTORS NOTE: The flag bit is typically used to cause an interrupt in the initiator between linked commands. The link bit is used to continue an I/O process across multiple commands. Implementation of the link bit is optional. A link bit of one indicates that the initiator requests a continuation of the I/O process and that the target should continue using the command queue for the I/O process, or request a new command upon successful completion of the current command. If the link bit is one, and if the command completes successfully, the target shall return INTERMEDIATE or INTERMEDIATE-CONDITION MET status and shall then send one of the two messages defined by the flag bit. If either of the link and flag bits are set to one, and the target does not implement linked commands, it shall return CHECK CONDITION status. The sense key shall be set to ILLEGAL REQUEST. 6.3. Status The status byte and status byte code are specified in Tables 6-6 and 6-7, respectively. A status byte shall be sent from the target to the initiator at the completion of each command unless the command is terminated by one of the following events: (1) an ABORT message (2) an ABORT TAG message (3) a BUS DEVICE RESET message (4) a CLEAR QUEUE message (5) a hard reset condition (6) an unexpected disconnect (see 5.1.1) Status transfer occurs at the end of a command. In some cases, status transfer may occur prior to transferring the command descriptor block. .kp on Table 6-6: Status Byte ============================================================================== Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ============================================================================== | Reserved | Status Byte Code |Reserved| ============================================================================== .kp off .kp on Table 6-7: Status Byte Code ============================================================================== Bits of Status Byte ----------------------------- 7 6 5 4 3 2 1 0 Status ------------------------------------------------------------------------------ R R 0 0 0 0 0 R GOOD R R 0 0 0 0 1 R CHECK CONDITION R R 0 0 0 1 0 R CONDITION MET R R 0 0 1 0 0 R BUSY R R 0 1 0 0 0 R INTERMEDIATE R R 0 1 0 1 0 R INTERMEDIATE-CONDITION MET R R 0 1 1 0 0 R RESERVATION CONFLICT R R 1 0 0 0 1 R COMMAND TERMINATED R R 1 0 1 0 0 R QUEUE FULL All Other Codes Reserved ============================================================================== Key: R - Reserved bit .kp off The definition of the status byte codes is given below. GOOD. This status indicates that the target has successfully completed the command. CHECK CONDITION. This status indicates that a contingent allegiance condition has occurred (see 6.6). CONDITION MET. This status or INTERMEDIATE-CONDITION MET is returned whenever the requested operation is satisfied (see the SEARCH DATA and PREFETCH commands). BUSY. This status indicates that the target is busy. This status shall be returned whenever a target is unable to accept the command from an otherwise acceptable initiator (i.e., no reservation conflicts). The recommended initiator recovery action is to issue the command again at a later time. If a reservation conflict exists, that status shall be presented before a BUSY status is presented to correctly inform the host system of conditions in the target controller. INTERMEDIATE. This status or INTERMEDIATE-CONDITION MET shall be returned for every successfully completed command in a series of linked commands (except the last command), unless the command is terminated with CHECK CONDITION, RESERVATION CONFLICT, or COMMAND TERMINATED status. If INTERMEDIATE or INTERMEDIATE-CONDITION MET status is not returned, the series of linked commands is terminated and the I/O process is ended. INTERMEDIATE-CONDITION MET. This status is the combination of the CONDITION MET and INTERMEDIATE statuses. RESERVATION CONFLICT. This status shall be returned whenever an initiator attempts to access a logical unit or an extent within a logical unit that is reserved with a conflicting reservation type. The recommended initiator recovery action is to issue the command again at a later time. COMMAND TERMINATED. This status shall be returned whenever the target terminates the current I/O process after receiving a TERMINATE I/O PROCESS message (see 5.6.22). This status also indicates that a contingent allegiance condition exists (see 6.6). QUEUE FULL. This status shall be implemented if tagged queuing is implemented. This status is returned when a SIMPLE QUEUE TAG, ORDERED QUEUE TAG, or HEAD OF QUEUE TAG message is received and the command queue is full. The I/O process is not placed in the command queue. 6.4. Command Examples The following sections give examples of typical command processing in the SCSI environment. Multiple path operation is not described in these examples. An alternative method for processing commands is defined which uses only the nexus transfer phase. The examples below will describe both methods of operation. 6.4.1. Single Command Example An I/O process containing one untagged READ command is used in this section to illustrate a simple I/O process on the SCSI bus. This example does not include error or exception conditions. The initiator has one set of active pointers that includes a command pointer, a data pointer, and a status pointer. In addition, the initiator has one set of saved pointers for each I/O process that it is able to concurrently manage. The initiator sets up the saved pointers to point to the appropriate bytes for the I/O process and copies the saved pointers to the active pointers. It then arbitrates for the SCSI bus, and upon winning arbitration, selects the target. Once the target is selected, the target assumes control of the I/O process. The initiator does not grant the target the privilege of disconnecting from the SCSI bus. 6.4.1.1. Using SCSI-2 Information Transfer Phases During the SELECTION phase, the initiator asserts the ATN signal to inform the target that the initiator wishes to send a message. The target enters the MESSAGE OUT phase and transfers the IDENTIFY message from the initiator. This message informs the target of which logical unit is to be used. At this point, an I_T_L nexus has been established for the I/O process. This nexus associates the initiator's pointers with the I/O process. The target switches to the COMMAND phase and transfers the command descriptor block from the initiator. In this case, the command descriptor block contains a READ command. The target interprets the command and switches to the DATA IN phase, transfers the data, switches to STATUS phase, sends GOOD status, switches to MESSAGE IN phase, and transfers a COMMAND COMPLETE message. After successfully sending the COMMAND COMPLETE message, the target goes to the BUS FREE phase by releasing the BSY signal and the I/O process ends. 6.4.1.2. Using Nexus Transfer Information Transfer Phases (Parallel) During the SELECTION phase, the initiator asserts the ATN signal to inform the target that the initiator wishes to send an information packet using the NEXUS TRANSFER OUT phase. The target enters the NEXUS TRANSFER OUT phase and transfers an information packet from the initiator. The first interface logical element in the information packet is a message group with the first message being an INFORMATION PACKET IDENTIFY message. This message informs the target which logical unit is to be used. At this point, an H_I_T_C_L nexus has been established for the I/O process, since the disconnect privilege is not granted. This nexus associates the initiator's pointers with the I/O process. The second interface logical element in the information packet is a command descriptor block for the READ command. The target interprets the command. The target prepares an information packet with the data read from the logical unit. The target then switches to the NEXUS TRANSFER IN phase and transmits the information packet containing the data. This information packet also contains, after the data interface logical element, interface logical elements for status and messages. The message interface logical element contains the COMMAND COMPLETE message. After successfully sending the information packet, the target goes to the BUS FREE phase. 6.4.2. Disconnect Example In the above single command example, the length of time necessary to obtain the data may require a time-consuming physical positioning operation. In order to improve SCSI bus performance, the target may be permitted to disconnect from the initiator, thereby freeing the SCSI bus to allow other I/O processes to use the SCSI bus. In this case, the initiator grants the target the privilege of disconnecting from the SCSI bus. The INFORMATION PACKET IDENTIFY has the SuspMpth bit set to 1 to force an H_I_T_C_L nexus. 6.4.2.1. Using SCSI-2 Information Transfer Phases After the target has received the READ command (and has determined that there will be a delay), it disconnects from the SCSI bus by sending a DISCONNECT message and by going to the BUS FREE phase. After the target retrieves the requested data from the peripheral device it arbitrates for the SCSI bus. Upon winning arbitration, it reselects the initiator and sends an IDENTIFY message to the initiator via the MESSAGE IN phase. This revives the I_T_L nexus so that the initiator can retrieve the correct set of pointers for the I/O process. The initiator restores the active pointers to their most recent saved values (which, in this case, are the initial values) and the target continues (as in the single command example) to finish the I/O process. If target wishes to disconnect after transferring part of the data (e.g., while crossing a cylinder boundary), it may do so by sending a SAVE DATA POINTER message and a DISCONNECT message to the initiator and then disconnecting. When reconnection is completed, the current data pointer is restored to its value immediately prior to the SAVE DATA POINTER message. On those occasions when an error or exception condition occurs and the target elects to repeat the information transfer, the target may repeat the transfer by either issuing a RESTORE POINTERS message or by disconnecting without issuing a SAVE DATA POINTER message. When reconnection is completed, the most recent saved pointer values are restored. 6.4.2.2. Using Nexus Transfer Information Transfer Phases (Parallel) After the target has received information packet with INFORMATION PACKET IDENTIFY message and the READ command the target automatically disconnects from the SCSI bus. This is not an unexpected BUS FREE condition since the disconnect privilege was granted to the target. After the target retrieves the requested data from the peripheral device it prepares an information packet with a message interface logical element containing an INFORMATION PACKET IDENTIFY message followed by a data interface logical element and then arbitrates using the same SCSI bus on which the connect was made. This information packet also contains, after the data, interface logical elements for status and messages. The message interface logical element contains the COMMAND COMPLETE message. Upon winning arbitration, it reselects the initiator and sends the information packet using the NEXUS TRANSFER IN phase. This revives the H_I_T_C_L nexus so that the initiator can retrieve the correct set of pointers for the I/O process. The initiator sets the active pointers to the most recently saved values for the I/O process (which, in this case, are the initial values) and the target continues (as in the single command example) to finish the I/O process. After successfully sending the information packet, the target goes to the BUS FREE phase. If target wishes to disconnect after transferring part of the data (e.g., while crossing a cylinder boundary), it may do so by placing only part of the data in the information packet above and omitting the status and message interface logical elements following the data. After successfully sending the information packet, the target goes to the BUS FREE phase. The initiator automatically saves the data pointers. One or more additional information packets containing the message and data interface logical elements is prepared and sent using the procedure described for the first information packet. Each reconnection causes the initiator to automatically restore the I/O process pointers to the active pointers. The last information packet may contain data, but it must contain the status and message interface logical elements in addition to the required message elements to reestablish the nexus. On those occasions when an error or exception condition occurs and the target elects to repeat the information transfer, the target may repeat the transfer by preparing an information packet containing a MODIFY DATA POINTERS message in the message interface logical element before the data element. At the end of the information packet transfer the pointers are once again automatically saved. 6.4.3. Linked Command Example In this example there is no difference in the logical actions taken by either the initiator or the target whether the SCSI-2 information transfer phases or the nexus transfer information transfer phases are used. The physical difference is that the initiator and target either use an explicit sequence of information transfer phases followed by the appropriate bytes or the initiator and target prepare information packets with the interface logical elements in the correct order and use only the nexus transfer phase. An I/O process may contain multiple commands "linked" together. Upon completing a linked command successfully, the target automatically proceeds to the next linked command for the I/O process. All commands in a series of linked commands are addressed to the same nexus and are part of a single I/O process. The commands are not entirely independent. When using the relative address bit (see 8.1.10), the address of the last logical block accessed by one of the commands is available to the next command. Thus one can search for a particular data pattern using a SEARCH DATA command and then read the logical block containing the data pattern with a READ command linked to the SEARCH DATA command. One can also read a logical block at a specified displacement from the block containing the data pattern. A LINKED COMMAND COMPLETE or LINKED COMMAND COMPLETE (WITH FLAG) message is sent from the target to the initiator to indicate that a linked command completed. The initiator then updates the saved pointers for the nexus so that subsequent transfers from the target reference the next command of the series. Command processing of linked and single commands is similar except that relative addressing is permitted in linked commands. For example, a successful completion of a SEARCH DATA EQUAL command causes the target to continue with the linked READ command from the initiator. If the relative address bit in the READ command has been set to one, and the address field of the READ command is set to zero, the target transfers the successfully searched block to the initiator. 6.5. Command Processing Considerations and Exception Conditions The following sections describe some exception conditions and errors associated with command processing and the sequencing of commands. 6.5.1. Programmable Operating Definition Some applications require that the operating definition of a logical unit be modified to meet the special requirements of a particular initiator. The program-controlled modification of the operating definition is typically provided to allow operating systems to change the operating definition of a more recently developed targets to one which is more compatible with the operating system. Invoking this function requires that the host system and its initiators comply with the low-level hardware definitions of SCSI-2. The parameters that can be changed by modifying the operating definition of a logical unit include the vendor identification, the device type, the device model, the SCSI compliance level, the SCSI specification level, the command set, and other parameters. The low-level hardware parameters including signal timing and parity definitions cannot be changed by modifying the operating definition. The present operating definition of a logical unit with respect to an initiator can be determined at any time by execution of an INQUIRY command. In some vendor-specific cases, it may also be necessary to perform other commands including MODE SENSE and READ CAPACITY. Each logical unit begins at a particular operating definition. If the logical unit supports the CHANGE DEFINITION command, the present operating definition can be changed to any other operating definition supported by the logical unit. The actual details of the operating definition of a logical unit are vendor-specific. If the operating definition is changed to one that does not include the CHANGE DEFINITION command, the target should continue to accept the CHANGE DEFINITION command. If an error occurs during execution of a CHANGE DEFINITION command, the original operating definition remains in effect after the command is executed. The new operating definition becomes active only after successful execution of the CHANGE DEFINITION command. Since new operating definitions may preclude the execution of I/O processes that are already in progress, the target may disconnect to allow completion of any I/O processes that are in progress. Operating definition changes that may cause conflicts with the normal operation from other initiators shall be indicated to those initiators by generating a unit attention condition for each other initiator. The additional sense code shall be set to CHANGED OPERATING DEFINITION. An initiator may request a list of the operating definitions that the target supports and descriptive text for each operating definition using the INQUIRY command. 6.5.2. Incorrect Initiator Connection An incorrect initiator connection occurs on a reconnection if: (1) an initiator attempts to reconnect to an I/O process, and (2) a soft reset condition has not occurred, and (3) the initiator does not send an ABORT, ABORT TAG, BUS DEVICE RESET, CLEAR QUEUE, or TERMINATE I/O PROCESS message during the same MESSAGE OUT phase as the IDENTIFY message or in the same information packet as the INFORMATION PACKET IDENTIFY message. An incorrect initiator connection also occurs on an initial connection when an initiator: (1) attempts to establish an I_T_L_Q nexus when an I_T_L nexus already exists from a previous connection for the same I, T, and L values, or (2) attempts to establish an I_T_L nexus when an I_T_L_Q nexus already exists unless there is a contingent allegiance or extended contingent allegiance condition present for the logical unit or target routine; or (3) attempts to establish an H_C_L_Q nexus when an H_C_L nexus already exists from a previous connection for the same H, C, and L values, or (4) attempts to establish an H_C_L nexus when an H_C_L_Q nexus already exists unless there is a contingent allegiance or extended contingent allegiance condition present for the logical unit or target routine. A target that detects an incorrect initiator connection shall abort all I/O processes for the initiator on the logical unit or target routine and shall return CHECK CONDITION status. The sense key shall be set to ABORTED COMMAND and the additional sense code shall be set to OVERLAPPED COMMANDS ATTEMPTED. If an initiator reconnects to an I/O process and a soft reset condition has occurred, the target shall meet the requirements of 5.2.2.2. IMPLEMENTORS NOTES: (1) An incorrect initiator connection may be indicative of a serious error and, if not detected, could result in an I/O process operating with a wrong set of pointers. This is considered a catastrophic failure on the part of the initiator. Therefore, vendor-specific error recovery procedures may be required to guarantee the data integrity on the medium. The target may return additional sense data to aid in this error recovery procedure (e.g., sequential-access devices may return the residue of blocks remaining to be written or read at the time the second command was received). (2) Some targets may not detect an incorrect initiator connection until after the command descriptor block has been received. 6.5.3. Selection of an Invalid Logical Unit The target's response to selection of a logical unit which is not valid is described in the following paragraphs. The logical unit may not be valid because: (1) the target does not support the logical unit (e.g., some targets support only one peripheral device). In response to an INQUIRY command the target shall return the INQUIRY data with the peripheral qualifier set to the value required in Table 7-16. In response to any other command except REQUEST SENSE the target shall terminate the command with CHECK CONDITION status. In response to a REQUEST SENSE command the target shall return sense data. The sense key shall be set to ILLEGAL REQUEST and the additional sense code shall be set to LOGICAL UNIT NOT SUPPORTED. (2) the target supports the logical unit, but the peripheral device is not currently attached to the target. In response to an INQUIRY command the target shall return the INQUIRY data with the peripheral qualifier set to the value required in Table 7-16. In response to any other command except REQUEST SENSE the target shall terminate the command with CHECK CONDITION status. In response to a REQUEST SENSE command the target shall return sense data. The sense key shall be set to ILLEGAL REQUEST and the additional sense code shall be set to LOGICAL UNIT NOT SUPPORTED. (3) the target supports the logical unit and the peripheral device is attached, but not operational. In response to an INQUIRY command the target shall return the INQUIRY data with the peripheral qualifier set to the value required in Table 7-16. The target's response to any command other than INQUIRY and REQUEST SENSE is vendor specific. (4) the target supports the logical unit but is incapable of determining if the peripheral device is attached or is not operational when it is not ready. In response to an INQUIRY command the target shall return the INQUIRY data with the peripheral qualifier set to the value required in Table 7-16. In response to a REQUEST SENSE command the target shall return the REQUEST SENSE data with a sense key of NO SENSE unless a prior error condition exists. The target's response to any other command is vendor specific. 6.5.4. Parameter Rounding Certain parameters sent to a target with various commands contain a range of values. Targets may choose to implement only selected values from this range. When the target receives a value that it does not support, it either rejects the command (CHECK CONDITION status with ILLEGAL REQUEST sense key) or it rounds the value received to a supported value. The target shall reject unsupported values unless rounding is permitted in the description of the parameter. Rounding of parameter values, when permitted, shall be performed as follows: A target that receives a parameter value that is not an exact supported value shall adjust the value to one that it supports and shall return CHECK CONDITION status with a sense key of RECOVERED ERROR. The additional sense code shall be set to ROUNDED PARAMETER. The initiator is responsible to issue an appropriate command to learn what value the target has selected. IMPLEMENTORS NOTE: Generally, the target should adjust maximum-value fields down to the next lower supported value than the one specified by the initiator. Minimum-value fields should be rounded up to the next higher supported value than the one specified by the initiator. In some cases, the type of rounding (up or down) is explicitly specified in the description of the parameter. 6.5.5. Asynchronous Event Notification Implementation of asynchronous event notification is optional protocol unless the SCSI device implements the nexus transfer phase; in that case it is mandatory. An asynchronous event is one which occurs in a target controller which affects the operation of the target controller with its host system(s), but which does not occur as a result of an active I/O process. An example of an asynchronous event is medium removal in a sequential access device or a removable optical device or a CD_ROM. An error condition or unit attention condition shall be reported once per occurrence of the event causing it (See contingent allegiance, Section 6.6.). The target may choose to use an asynchronous event notification or to return CHECK CONDITION status on a subsequent command, but not both. Notification of command-related error conditions shall be sent only to the host system where the connect was made for the I/O process. SCSI devices that implement target mode, respond to an INQUIRY command as a processor device class, and report asynchronous event notification capability (AENC bit is set to 1) may be notified of asynchronous events using this protocol. Such SCSI devices are normally initiators attached to a host system. Asynchronous event notification may not be used with a device that acts as a temporary initiator (e.g., devices executing COPY commands), unless the SCSI device implements an active target mode, and responds correctly to the INQUIRY command as required above. The INQUIRY command should be issued to logical unit zero of each SCSI device responding to selection. An SCSI device, which normally functions as a target controller, must implement initiator mode to be capable notifying a host system of an asynchronous event. Retrieval of the INQUIRY data by target controllers shall shall be performed prior to the first use of asynchronous event notification with a host system through an initiator. Each SCSI device that implements the required functions and responses for receiving asynchronous event notification shall be issued a TEST UNIT READY command to determine that the SCSI device is ready to receive an asynchronous event notification. An SCSI device returning CHECK CONDITION status is issued a REQUEST SENSE command. This clears any pending unit attention condition. (??? before each AEN is reported; what if it is something else??? GRS) An SCSI device which implements the required functions and responses for receiving asynchronous event notification, defined above, and which returns GOOD status when issued a TEST UNIT READY command shall accept a SEND command with an AEN bit of one. A SEND command with an AEN bit of one is interpreted as an asynchronous event by a host system. The information identifying the condition being reported shall be returned as a command parameter data of the the SEND command (see 11.2.2.). The data sent is shown in Table 11-4. The procedure to identify candidate host systems through their initiators shall be repeated whenever a target controller deems it appropriate or when an event occurs that may invalidate the current information. (See 5.6.21, SYNCHRONOUS DATA TRANSFER REQUEST message, for examples of these events.) This protocol is not intended to be used while an H_C_L nexus, an H_C_R nexus, an I_T_L nexus or I_T_L_Q nexus exists between an host system for the H_C nexus types or an initiator declared as a processor device class for the I_T nexus types. Asynchronous event notification is not intended for use with target routines (i.e., an H_C_R or I_T_R nexus) but its use is not prohibited. Parameters affecting the use of asynchronous event notification are contained in the control mode page (see 7.3.3.1). The four principal uses of asynchronous event notification are: (1) informing a processor of an error condition encountered after command completion; (2) informing all processor devices that a newly initialized device is available; (3) informing all processor devices of other unit attention conditions; and, (4) informing all processor devices of other asynchronous events. Other uses of asynchronous event notification are not prohibited. An example of the first case above is a device that implements a write cache. If the target is unable to write cached data to the medium, it may use an asynchronous event notification to inform the host system of the failure. An extended contingent allegiance condition may also be established during the same H_C_L or I_T_L nexus used for the asynchronous event notification (see 5.6.9). An example of the second case above is using the asynchronous event notification protocol to notify host systems that a system resource has become available. If a target chooses to use this method, the sense key in the sense data sent to the host system shall be set to UNIT ATTENTION. The alternative is to set a UNIT ATTENTION condition and then wait until selected. An example of the third case above is a device that supports removable media. Asynchronous event notification may be used to inform a host system of a not-ready-to-ready transition (medium changed) or of an operator initiated event (e.g., activating a write protect switch or activating a start or stop switch). An example of the fourth case above is a sequential-access device performing a REWIND command where the immediate bit had been set to one. Asynchronous event notification may be used to inform an initiator that the beginning of medium has been reached or that the rewind operation failed. Completion of a CD-ROM AUDIO PLAY command started in the immediate mode is another example of this case. IMPLEMENTORS NOTE: An SCSI device which can use asynchronous event notification at initialization time should provide means to defeat these notifications. This can be done with a switch or jumper wire. Devices which implement saved parameters may alternatively save the asynchronous event notification permissions either on a per SCSI device basis or as a system wide option. In any case, each target controller conducts a survey with INQUIRY commands to be sure that the devices on the SCSI bus are appropriate destinations for asynchronous event notification. (The devices on the bus or the SCSI ID assignments may have changed.) 6.6. Contingent Allegiance Condition Implementation of Contingent allegiance is a mandatory. The contingent allegiance condition shall exist following the return of CHECK CONDITION or COMMAND TERMINATED status and may optionally exist following an unexpected disconnect. The contingent allegiance condition shall be preserved for the H_C_x nexus or I_T_x nexus, on the H_I_T_C path where it is reported, until it is cleared. The type of nexus and conditions in effect for the nexus, established with the connect, determine which path is used to report the status leading to contingent allegiance. The contingent allegiance condition shall be cleared upon the generation of a hard reset condition, or by an ABORT message, a BUS DEVICE RESET message, or any subsequent command for the I_T_x nexus. If the subsequent command is a REQUEST SENSE command, the sense data is reported in response to the command and then cleared. While the contingent allegiance condition exists the target shall preserve the sense data. While the contingent allegiance condition exists, if the target is unable to maintain separate sense data, the target shall respond to any other requests for access to the logical unit or target routine from another initiator with a BUSY status. Execution of queued commands for the logical unit or target routine for which the contingent allegiance condition exists shall be suspended until the contingent allegiance condition is cleared. 6.7. Extended Contingent Allegiance Condition Implementation of extended contingent allegiance is optional. The extended contingent allegiance condition extends the contingent allegiance condition for an H_C_x nexus or an I_T_x nexus. This condition is generated by the target sending an INITIATE RECOVERY message on the same path as and following the CHECK CONDITION or COMMAND TERMINATED status and prior to the COMMAND COMPLETE message. This condition shall be preserved until it is cleared by a BUS DEVICE RESET message, a RELEASE RECOVERY message, or a hard reset condition. While the extended contingent allegiance condition exists, the target shall respond to any other request for access to the logical unit from any other path with BUSY status. Execution of queued commands for the logical unit for which the extended contingent allegiance condition exists shall be suspended until the extended contingent allegiance condition is reset. If the device wishes to generate an extended contingent allegiance condition during an asynchronous event notification (6.5.5), it shall send an INITIATE RECOVERY message following the IDENTIFY message (and following any queue tag message) and prior to the SEND command. An extended contingent allegiance condition can be generated for only one H_C_L or I_T_L nexus at a time. The extended contingent allegiance condition is cleared as defined above. when a RELEASE RECOVERY message is received from the device to which the INITIATE RECOVERY message was sent. During an extended contingent allegiance only untagged I/O processes from the eligible path shall be executed for the logical unit. If the initiator sends a queue tag message the target shall respond with QUEUE FULL status. After the extended contingent allegiance condition is cleared any commands remaining in the command queue shall be executed. IMPLEMENTORS NOTES: (1) It is not required to generate an extended contingent allegiance condition for every CHECK CONDITION or COMMAND TERMINATED status that occurs. Simple errors not requiring an extended recovery may be dealt with by using the contingent allegiance protocol. (2) During the existence of the extended contingent allegiance condition, appropriate error recovery sequences may be executed. Such commands can correct data, modify or delete queued commands, perform LOG SENSE commands and obtain diagnostic information. Extended contingent allegiance is recommended for error conditions that may require execution of multiple-step error-recovery protocols without interference from other initiators. 6.8. Queued I/O Processes The implementation of queuing for I/O processes is optional. Queuing of I/O processes allows a target to accept multiple I/O processes for execution at a later time. There are two methods for implementation of queuing, tagged and untagged. Tagged queuing allows a target to accept multiple I/O processes from each host system for each logical unit or target routine. Untagged queuing allows a target to accept one I/O process from each host system for each logical unit. A target may be capable of both methods queuing, but only one method may be used at a time. Untagged queuing may be supported by SCSI-1 devices or devices whose level is at least SCSI-2. Tagged queuing is first supported in SCSI-2 devices. In the text that follows when the nexus transfer phase is being used, substitute INFORMATION PACKET IDENTIFY message for IDENTIFY message and substitute EXTENDED MESSAGE REJECT message for MESSAGE REJECT message. References to data transfer imply data interface logical elements in information packet are used. 6.8.1. Untagged Queuing Untagged queuing allows a target to accept a command from a host system for a logical unit or target routine while a command from another host system is being executed. Only one command for each H_C_x nexus or I_T_x nexus shall be accepted at a time. An I/O process may be initiated any time the BUS FREE phase exists even if an I/O process from a different host system is active. If the disconnect privilege is not granted in the IDENTIFY message of the new I/O process, the target may either suspend the active I/O process or it may return BUSY status to the new I/O process. The H_C_x nexus or the I_T_x nexus sufficiently specifies the relationship so that the target can reconnect to the host system to restore the pointers for I/O process as long as only one I/O process per H_C_x nexus or I_T_x nexus is issued. It is the responsibility of the initiator to assure that only one such I/O process is issued at any time (see 6.5.2). 6.8.2. Tagged Queuing Tagged queuing allows a target to accept multiple I/O processes from the same or different host systems until the logical unit's command queue is full. If an I/O process is received and the command queue is full, the target shall terminate the I/O process with QUEUE FULL status. The command queue is setup by the target for each supported logical unit and target routine (??? GRS). Host systems may add or delete I/O processes to the queue. When adding an I/O process, the host system may specify fixed order of execution, allow the target to define the order of execution, or specify that the I/O process is to be executed next. If the disconnect privilege is not granted in the IDENTIFY message for a tagged I/O process the target shall return BUSY status. Optionally, since the initiator has made an error in the IDENTIFY message, the target may return CHECK CONDITION status and prepare the appropriate sense data. The queue tag messages (see 5.6.17) allow the host system to establish a unique H_C_L_Q nexus or I_T_L_Q nexus to identify each I/O process. The H_C_L_Q nexus or I_T_L_Q nexus allows the target to reconnect to a specific I/O process and allows the initiator for each connection to restore the set of pointers for that I/O process. A host system may have several I/O processes ongoing to the same or different logical units or target routines (??? GRS) as long as each has a unique nexus. If only SIMPLE QUEUE TAG messages are used, the target may execute the commands in any order that is deemed desirable within the constraints of the queue management algorithm specified in the control mode page (see 7.3.3.1). If ORDERED QUEUE TAG messages are used, the target shall execute the commands in the order received with respect to other commands received with ORDERED QUEUE TAG messages. All commands received with an SIMPLE QUEUE TAG message prior to a command received with an ORDERED QUEUE TAG message, regardless of host system, shall be executed before that command with the ORDERED QUEUE TAG message. All commands received with an SIMPLE QUEUE TAG message after a command received with an ORDERED QUEUE TAG message, regardless of host system, shall be executed after that command with the ORDERED QUEUE TAG message. A command received with a HEAD OF QUEUE TAG message is placed first in the queue, to be executed next. A command received with a HEAD OF QUEUE TAG message shall not suspend an active I/O process in the target. Consecutive commands received with HEAD OF QUEUE TAG messages are executed in a last-in-first-out order. An I/O process received without a queue tag message while there are any tagged I/O commands in the command queue is an incorrect connection (see 6.5.2) unless there is a contingent allegiance or extended contingent allegiance condition. A series of linked commands are a single I/O process, and are assigned the queue tag established in the initial connection. A command received with a HEAD OF QUEUE TAG message shall not suspend a series of linked commands for which the target has begun execution. When using information packets, the complete series of commands may be transferred in one information packet. The RESERVE and RELEASE commands should be sent with an ORDERED QUEUE TAG message. Use of the HEAD OF QUEUE TAG message with these commands could result in reservation conflicts with previously issued commands. The TEST UNIT READY and INQUIRY commands are often sent with a HEAD OF QUEUE TAG message, since the information returned has no effect on the condition of the logical unit. Two error recovery options are allowed. The error recovery option to be used is specified in the control mode page (see 7.3.3.1). The first post-recovery option is to continue execution of commands in the queue after the contingent allegiance or extended contingent allegiance condition has cleared. The target controller returns BUSY status to other host system connects while the contingent allegiance or extended contingent allegiance condition exists. During this time all commands in the queue are suspended. All commands used for recovery operations shall be untagged commands. The queue may be modified by removing all or selected commands in the queue as part of the recovery procedure. If commands are combined by the queuing algorithm such that the error affects more than one command, then a contingent allegiance condition shall be generated for all affected commands. The second recovery option clears the queue after the contingent allegiance or extended contingent allegiance condition has been cleared. When the queue is cleared because of this recovery option, a unit attention condition shall be generated for all other host systems and the additional sense code shall be set to COMMANDS CLEARED BY ANOTHER INITIATOR. Deferred errors are normally related to a command that has already completed. As such, there is no attempt to return the queue tag value assigned to the original command. A device that does not support tagged queuing for any reason (e.g., not implemented, disabled by the DQue bit in the control mode page, or it has been switched to an operating definition that does not include tagged queuing) shall respond to any queue tag message with a MESSAGE REJECT message. The target shall continue the I/O process as if it was an untagged I/O process. (??? How does this work without initiator modified connects??? GRS) Tagged queuing may also be temporarily disabled internal to the SCSI device during certain initialization periods or to control internal resource utilization. During these periods the target may elect to return QUEUE FULL status or it may respond to any queue tag message with a MESSAGE REJECT message. (??? why two choices? message reject implies lack of function rather than suspended function. If the target controller is indisposed it should not indicate inappropriate; it should indicate inappropriate AT THIS TIME by the QUEUE FULL message. GRS) Several messages may be used to clear part or all of the command queue. Refer to the ABORT, ABORT TAG, BUS DEVICE RESET, and CLEAR QUEUE messages in Section 5 for details. 6.8.3. Example of Queued I/O Process An example of I/O process queuing benefits from the consideration of the execution of a number of commands. After each command, the state of the queue kept in the target is shown to indicate the function actually performed by the queuing. All examples shown in this section assume that multiple path operation is not being used. 6.8.3.1. Typical Sequences for Tagged Queuing An I/O process using tagged queuing uses the following sequences for normal execution. The initiator first arbitrates for the SCSI bus, and after successfully obtaining the SCSI bus, selects the appropriate SCSI device. The ATN signal is asserted during the SELECTION phase to indicate that a MESSAGE OUT phase is requested by the initiator. The first message byte transferred is an IDENTIFY message. The ATN signal continues to be asserted during the MESSAGE OUT phase to indicate that the initiator has another message. The second message byte transferred is the first byte of the appropriate queue tag message, in this case a SIMPLE QUEUE TAG message. The third and last message byte is transmitted containing the second byte of the queue tag message, the queue tag. As it is transferred, the ATN signal is negated to indicate that no more message bytes are available. The target then transfers the command descriptor block. Assuming the command requires disconnection, the target transmits a DISCONNECT message to the initiator and then enters the BUS FREE phase. The target places the command, identified by the I_T_L_Q nexus, at the appropriate place in the command queue. When the target removes I/O processes from the queue for execution, a physical latency period may occur. At the end of this period, when the target is prepared to transfer the appropriate data, the target begins an ARBITRATION phase and, upon winning, enters a RESELECTION phase. After a successful reselection, the target sends the IDENTIFY message followed by a SIMPLE QUEUE TAG message with the queue tag value originally sent by the initiator. The initiator uses the I_T_L_Q nexus to identify the correct set of pointers and control blocks associated with the I/O process and to establish the necessary conditions for data transfer. The target begins data transfer. When the data transfer is successfully completed, the target returns GOOD status and terminates the I/O process with a COMMAND COMPLETE message. 6.8.3.2. Example of Tagged Queuing An example of the execution of five queued I/O processes is described to demonstrate how tagged queuing operates. All tagged I/O processes are from one initiator to a single logical unit of a single target. The five I/O processes are defined in Table 6-8. The target is a direct-access device. At the time the I/O processes are first being executed, it is assumed that the actuator is in position to access logical block 10000. .kp on Table 6-8: Commands in Order Received by Target Queue Logical Tag Block Transfer Command Queue Tag Message Value Address Length Status ------- ----------------- ----- ------- --------- --------- READ SIMPLE 01h 10000 1000 Queued READ SIMPLE 02h 100 1 Queued READ ORDERED 03h 1000 1000 Queued READ SIMPLE 04h 10000 1 Queued READ SIMPLE 05h 2000 1000 Queued .kp off The optimum order would require that those blocks close to the actuator position be the first blocks accessed, followed by those increasingly far from the actuator position. However, the command with queue tag 03h is an ordered I/O process, so that all simple I/O processes transferred previously must be executed before, while all simple I/O processes transferred after the ordered I/O process must be executed after the ordered I/O process. If a target supports an optimizing algorithm the actual order in which the I/O processes are executed could be as shown in Table 6-9. .kp on Table 6-9: Commands in Order of Execution Queue Logical Tag Block Transfer Command Queue Tag Message Value Address Length Status ------- ----------------- ----- ------- --------- --------- READ SIMPLE 01h 10000 1000 Queued READ SIMPLE 02h 100 1 Queued READ ORDERED 03h 1000 1000 Queued READ SIMPLE 05h 2000 1000 Queued READ SIMPLE 04h 10000 1 Queued .kp off I/O processes with queue tag values 01h and 02h are executed in the order received since the actuator is already in position to execute I/O process 01h. I/O process 02h must be executed before I/O process 04h or 05h because the ordered I/O process 03h was transmitted after I/O processes 01h and 02h but before I/O processes 04h and 05h. I/O process 03h is then executed after I/O process 02h. The I/O processes 04h and 05h are executed after the ordered I/O process 03h. I/O process 05h is executed before I/O process 04h because the actuator is in position to access block 2000 after executing I/O process 03h. I/O process 04h is executed last. As an example of the operation of the HEAD OF QUEUE TAG I/O process, consider that a new I/O process, identified by a HEAD OF QUEUE TAG message with a queue tag of 08h, is transmitted to the target while the ordered I/O process 03h is being executed. The I/O process 03h continues execution, but the new HEAD OF QUEUE TAG I/O process is placed in the queue for execution before all subsequent I/O processes. In this case, the queue for execution after the ordered I/O process 03h was executed would appear as shown in Table 6-10. .kp on Table 6-10: Modified by HEAD OF QUEUE TAG Message Queue Logical Tag Block Transfer Command Queue Tag Message Value Address Length Status ------- ----------------- ----- ------- --------- --------- READ ORDERED 03h 1000 1000 Executing READ HEAD OF QUEUE 08h 0 8 Queued READ SIMPLE 05h 2000 1000 Queued READ SIMPLE 04h 10000 1 Queued .kp off To obtain maximum performance gains using tagged queuing requires careful implementation of the queuing algorithms in the target. In addition, initiators should allow a maximum number of simple I/O processes to be executed with a minimum number of ordered I/O processes. RESERVE and RELEASE commands, SET LIMITS commands, and appropriate software locking conventions should be used to guarantee the proper relationship between the commands executed and the data stored on the peripheral devices. These conventions are not defined by this standard. 6.9. Unit Attention Condition The target shall generate a unit attention condition for each initiator on each valid logical unit whenever the target has been reset by a BUS DEVICE RESET message, a hard reset condition, or by a power-on reset. The target shall also generate a unit attention condition on the affected logical unit(s) for each host system whenever one of the following events occurs: (1) A removable medium may have been changed. (2) The mode parameters in effect for this host system have been changed by another host system. (3) The version or level of microcode has been changed. (4) Tagged commands queued for this host system were cleared by another host system. (5) INQUIRY data has been changed. (6) The mode parameters in effect for this host system have been restored from nonvolatile memory. (7) A change in the condition of a synchronized spindle. (8) Any other event occurs that requires the attention of the host system. The unit attention condition shall persist on the logical unit for each host system until that host system clears the condition as described in the following paragraphs. If an INQUIRY command is received from a host system to a logical unit with a pending unit attention condition (before the target generates the contingent allegiance condition), the target shall perform the INQUIRY command and shall not clear the unit attention condition. If the INQUIRY command is received after the target has generated the contingent allegiance condition for a pending unit attention condition, then the unit attention condition on the logical unit shall be cleared, and the target shall perform the INQUIRY command. If any other command is received after the target has generated the contingent allegiance condition for a pending unit attention condition, the unit attention condition on the logical unit shall be cleared, and if no other unit attention condition is pending the target shall perform the command. If another unit attention condition is pending the target shall not perform the command and shall generate another contingent allegiance condition. If a REQUEST SENSE command is received from an initiator with a pending unit attention condition (before the target generates the contingent allegiance condition), then the target may either: (1) report any pending sense data and preserve the unit attention condition on the logical unit, or (2) report the unit attention condition, may discard any pending sense data, and clear the unit attention condition on the logical unit for that initiator. If the target has already generated the contingent allegiance condition for the unit attention condition, the target shall perform the second action listed above. If an initiator issues a command other than INQUIRY or REQUEST SENSE while a unit attention condition exists for that initiator (prior to generating the contingent allegiance condition for the unit attention condition), the target shall not perform the command and shall report CHECK CONDITION status unless a higher priority status as defined by the target is also pending (e.g., BUSY or RESERVATION CONFLICT). If after generating the contingent allegiance condition for a pending unit attention condition, the next command received from that initiator on the logical unit is not REQUEST SENSE, then that command shall be performed and the unit attention condition shall be cleared for that initiator on the logical unit and the sense data is lost (see 6.6). If a target becomes a temporary initiator to issue a SEND command with an AEN bit of one, which informs the initiator (temporary target) of the unit attention condition, and the SEND command completes with GOOD status, then the target shall clear the unit attention condition for that initiator on the logical unit (see 6.5.5). IMPLEMENTORS NOTES: (1) Targets may queue unit attention conditions on logical units. After the first unit attention condition is cleared, another unit attention condition may exist (e.g., a power on condition followed by a microcode change condition). The host system can clear all pending unit attention conditions by repeatedly sending the REQUEST SENSE command until a sense key other than UNIT ATTENTION is returned by the target. (2) See 6.5.3 for requirements concerning selection of an invalid logical unit.