Intelligent input/output target device communication and exception handling

[0002] 1. Field of the Invention

[0003] This invention relates generally to communication between host computer systems and peripheral devices, and more particularly to methods for efficiently communicating with target devices and exception handling in the Intelligent Input/Output (I₂O) architecture environment.

[0004] 2. Description of the Related Art

[0005] In an effort to make computer systems more flexible and better able to expand their functionality, many types of well known computer peripheral devices and software drivers have been developed over the years. For example, peripheral devices may either be internal to a computer system's housing, or be external stand-alone devices. Typical internal peripheral devices include hard disk drives, optical disc drives and the like. Most commonly, external peripheral devices are connected to a computer system via a suitable host adapter card. The host adapter card is typically connected to the host computer system via an internal bus or an external connection providing similar functionality.

[0006] The host adapter generally has its own hardware to enable communication to and from the peripheral device. The peripheral devices, in turn, are specific to a particular type of communication protocol. One common type of protocol is the SCSI protocol, which enable many types of high speed SCSI peripheral devices to communicate data to and from the host computer. Although computer systems have been gaining additional uses, functionality and modularity, these added features do have the downside of placing a burden on the host computer's CPU.

[0007] As a result, microprocessor vendors, such as Intel Corporation of Santa Clara, Calif., have developed specialty I/O processors that are configured to offload some of the processing burden from the CPU of the host computer. Although the host computer has been spared of some processing responsibilities by implementing these specialty microprocessors, adding this type of additional hardware does have the downside of increasing the cost of an overall system.

[0008] To facilitate discussion, FIG. 1 illustrates a prior art interface between a host computer system 100 and a peripheral device 118. The simplified architecture of FIG. 1 is commonly used to implement the intelligent I/O (I₂O) architecture communication specification, which was jointly developed by several computer vendors, and is currently available from The I₂O Special Interest Group (SIG) of San Francisco, Calif. The I₂O Specification is hereby incorporated by reference in its entirety. The I₂O specification, in general, defines a standard architecture that is independent of the device being controlled. Thus, implementing the I₂O architecture has the power of enabling developers to design cross-platform intelligent I/O devices and software drivers. Accordingly, device manufacturers only need to write a single I₂O-ready driver for each device, irrespective of the operating system that will ultimately communicate with the I₂O device driver. Each operating system vender (OSV) must write their own drivers for storage, for LAN, etc.

[0009] The I₂O architecture is designed to work in conjunction with an input/output processor 106. The input/output processor 106 generally communicates across a PCI interface 104, to communicate with a block storage operating system module (OSM) 102. The block storage OSM 102 is configured to communicate I₂O message requests to the I/O processor 106, which is then configured to implement a real-time operating system (OS) 108 to execute a device driver 110 (i.e., the target device having a target ID “TID”).

[0010] The device driver 110 then communicates with a desired SCSI chip 116, for example, via a signal 112. The signal 112 represents the desired request that may be made to the SCSI chip 116 and thus communicated to the peripheral device 118. By way of example, in the case of peripheral storage devices, the request provided through signal 112 may be a request to read a certain number of data blocks from the peripheral storage device 118. Once the desired data has been read from the peripheral storage device 118, the data may be transferred to memory and a reply signal 114 may be provided back to the device driver 110, indicating that a successful data transfer has occurred (or alternatively, indicating that some type of error occurred). The device driver 110 is therefore a logical entity that responds as a target ID (TID). In general, the input/output processor 106 uses the real-time OS 108 to operate on the device driver 110 and communicate with the SCSI chip 116 without utilizing the host computer's processor. For more information on I/O processor functionality, reference may be made to U.S. Pat. Nos. 5,751,975 and 5,734,847, both of which are hereby incorporated by reference.

[0011] Although implementing an input/output processor 106 and associated hardware will enable proper handling of I₂O messaging from the block storage OSM 102, this implementation has the downside of significantly increasing the cost of implementing the I₂O architecture messaging scheme to simply effectuate communication with the target device driver 110. Therefore, when I₂O architecture messaging is desired, a user of a computer system will be required not only to purchase, for example, the correct SCSI host adapter card, but also to purchase a specialty input/output processor 106 and associated hardware. As mentioned above, implementing this amount of added hardware has the downside of increasing the total package cost of communicating with peripheral devices.

[0012] In spite of the fact that earlier generation computer systems lacked sufficient processor power to handle additional processing tasks, as processor speeds in common computer systems have continued to increase, the need for auxiliary processors is diminishing. That is, the added processing needed to communicate I₂O messages from a host computer system to a target device no longer places such a great processing burden on the processor of the host computer system.

[0013] In view of the foregoing, there is a need for a computer implemented method and system that will enable I₂O architecture messaging and exception handling between a host computer system and a target device, without unnecessarily increasing a system's cost by requiring specialty processors.

[0014] Broadly speaking, the present invention fills these needs by providing a method and system for employing an intelligent I/O pull transport for messaging that implements a host-resident hardware interface service module (such as a RAID driver) and an exception operating system module (EOSM) driver for exception handling. This novel method and system advantageously makes generic storage silicon appear and function as an I₂O ready capable device without a microprocessor. It should be appreciated that the present invention can be implemented in numerous ways, including as a process, an apparatus, a system, a device, a method, or a computer readable medium. Several inventive embodiments of the present invention are described below.

[0015] In one embodiment, a method for intelligent input/output message communication between a host computer and a target device is disclosed. The method includes generating an intelligent input/output message request intended for the target device, and pulling the intelligent input/output message request (from a block storage OSM, for example). Translating the intelligent input/output message request into a silicon specific message request (is one function performed by 204). The translating is performed by a host-resident intermediate service module, such as a RAID driver. The method then proceeds to store the silicon specific message request into a first queue, and pull the silicon specific message request from the first queue via a PCI interface for processing by the target device. The method is then configured to push a message reply from the target device to the first queue via the PCI interface, such that the host-resident intermediate service module can translate the message reply that may be in the form of a silicon specific reply into an intelligent input/output message reply. The method then pushes the intelligent input/output message reply to a block storage operating system module for communication to a host operating system (OS).

[0016] Still further, the disclosed method is configured to monitor the intelligent input/output message request, such that the monitoring is performed by an exception operating system module (OSM) driver. The silicon stores a copy of the intelligent input/output message request in a second queue (e.g., an internal queue) while a determination is made as to whether the intelligent input/output message reply was received successfully by the block storage operating system module. If the reply was not received successfully, the exception operating system module driver is configured to intervene to correct the problem and then provide the appropriate reply to the block storage operating system module.

[0017] In another embodiment, a computer implemented system for facilitating intelligent input/output message communication between a host computer system and a silicon specific target device without implementing an input/output processor is disclosed. The system includes a block storage operating system module for receiving a request from an operating system of the host computer system and generating an intelligent input/output message request. Also included is a host-resident intermediate service module (HISM) driver for translating the intelligent input/output message request into a silicon specific request (e.g., a modified I₂O message, an FFI message, a SCB message, etc.) that is compatible with the silicon specific target device (i.e., understood by the silicon circuitry and firmware). Further included is a queue for holding the silicon specific request until the silicon specific target device pulls the silicon specific request from the queue via a PCI interface transport. In this preferred embodiment, the system further includes an exception operating system module driver that is in communication with the silicon specific target device and the block storage operating system module.

[0018] In yet a further embodiment, a system for facilitating I/O processor-less I₂O message communication between a host computer and a silicon specific target device is disclosed. The system includes a block storage operating system module (OSM) that is configured to communicate with an operating system (OS) of the host computer such that the block storage operating system module receives OS-specific I/O requests that are processed into I₂O message requests. The system further includes a host-resident intermediate service module (HISM) that is configured to pull the I₂O message requests from the block storage operating system module and translate them into a silicon-specific format. Further included is a queue for temporarily storing the I₂O message requests that are in the silicon-specific format. The system then includes a silicon-specific target device that is configured to pull the I₂O message requests that are in the silicon-specific format from the queue and then process a reply. In this preferred embodiment, the system also includes an exception operating system module (OSM) driver that is in communication with the silicon-specific target device and the block storage operating system. The exception operating system module driver is preferably configured to observe the I₂O message requests and store a copy of the I₂O message requests for facilitating trouble shooting if necessary.

[0019] Other aspects and advantages of the invention will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, illustrating by way of example the principles of the invention.

[0020] The present invention will be readily understood by the following detailed description in conjunction with the accompanying drawings, and like reference numerals designate like structural elements.

[0021] FIG. 1 illustrates a prior art interface between a host computer system and a peripheral device, which implements an I/O processor to execute a device driver within a real-time OS.

[0022] FIG. 2 illustrates an improved I₂O architecture messaging method that streamlines the messaging functionality while eliminating unnecessary I/O processors and associated hardware, in accordance with one embodiment of the present invention.

[0023] FIG. 3 illustrates a more detailed flowchart diagram of the method operations performed by an exception operating system module (OSM) driver in accordance with one embodiment of the present invention.

[0024] An invention is described for a computer implemented method and system for employing intelligent I/O pull transport for messaging that implements a host-resident hardware interface service module and an exception operating system module driver for exception and error handling. This novel method and system advantageously makes non-I₂O storage silicon appear as though it were an I₂O capable device, without implementing cost increasing I/O processors. It will be obvious, however, to one skilled in the art, that the present invention may be practiced without some or all of these specific details. In other instances, well known process operations have not been described in detail in order not to unnecessarily obscure the present invention.

[0025] The details of the invention will now be described in greater detail with reference to FIGS. 2-3. By employing an intelligent I/O pull transport for messaging in conjunction with a host resident intermediate service module (ISM) (e.g., such as host resident RAID service module) and an exception handling OSM, non-I₂O silicon can be made to appear as a RAID capable I₂O device. In this manner, there is no need to implement a separate I/O processor, real-time OS, and associated hardware to make generic silicon act as though it were I₂O capable. In a preferred embodiment, exceptions will be treated as events for which the exception handling OSM has knowledge of (i.e., are registered exception events). Of particular significance is that the RAID service module is resident on the host resident, as opposed to prior art I/O processor (IOP) implementations which implement device drivers on the other side of the PCI interface as RAID drivers within a runtime OS (RTOS).

[0026] FIG. 2 illustrates an improved I₂O architecture messaging method and system that streamlines the messaging functionality while eliminating unnecessary add-on I/O processors and associated hardware, in accordance with one embodiment of the present invention. As shown, the host computer 200 will generally include a block storage operating system module (OSM) 202 a host intermediate service module (HISM) 204, which functions as the target device for pulling any I₂O message from the block storage OSM 202, and communicating a successful reply. Generally, when the OSM 202 is presented with a request from the host OS, it translates the request into the appropriate I₂O message before it is dispatched to the HISM 204.

[0027] The HISM 204 is, in one embodiment, a RAID driver which is configured to implement an I₂O message pull technique to acquire the I₂O messages 208 from the host's memory, and generate an I₂O push reply 210 back to the host memory. The HISM 204 is configured to write the I₂O message into a queue 203 which is configured to communicate over a PCI interface 212 (i.e., a PCI bus), which defines the transport layer interface to a silicon circuitry and firmware module 216. In this embodiment, the silicon circuitry and firmware module 216 is essentially the circuitry, in the form of a silicon chip, that is integrated as part of the host adapter 214. The host adapter 214 is thus capable of communicating with a SCSI peripheral device 218. Although a greater number of peripheral devices may be implemented, only one SCSI peripheral device 218 is provided here to simplify the discussion.

[0028] In this embodiment, the queue 203 and the queue 205 are preferably configured to queue data in accordance with an endless queue technique, which is described in greater detail in U.S. patent application Ser. Nos.: (1) 08/862,143, filed May 22, 1997, having inventor Arlen Young, (2) 08/815,645, filed Mar. 13, 1997, having inventor Arlen Young, and (3) 08/816,980, filed Mar. 13, 1997, having inventor Arlen Young. These U.S. patent applications, which are commonly assigned to the assignee of the present application, are hereby incorporated by reference.

[0029] The exception OSM driver 206 is shown in communication with the silicon circuitry and firmware module 216 via an event request signal 222 and an event reply signal 224. Also shown is a hardware interface module (HSM)—sequencer exception dialog signal 226, which communicates between the silicon circuitry and firmware module 216 and the exception OSM driver 206. As will be discussed in greater detail below, the exception OSM driver 206 is also capable of communicating with the block storage OSM 202 via a signal 207. During normal operation, the block storage OSM 202 is configured to send I₂O messages via signal 208 to the target device HISM 204.

[0030] The target device HISM 204 is thus configured to parse the I₂O message and perform an appropriate conversion in order for the silicon circuitry and firmware module 216 to be sent the request in interface calls specific to the silicon. For example, if the silicon circuitry and firmware module 216 only understands certain silicon-specific interface calls, the I₂O message received from the block storage OSM 202 will be translated into the appropriate silicon-specific interface call. These silicon-specific interface call can thus be transferred to the queue 203 and then via signal 211 over the PCI interface 212, which is then communicated to the silicon circuitry and firmware module 216.

[0031] Alternatively, the target device HISM 204 may convert the I₂O message 208 (depending upon the type of silicon circuitry and firmware module 216 being implemented), into one of a modified I₂O message, a fixed function interface (FFI) of the I₂O architecture, or a SCSI command block (SCB). By way of example, when the target device HISM 204 merely provides a modified I₂O message, the I₂O message may simply be converted from one that identifies logical drives with redundancy characteristics (e.g., in the case of a RAID implementation), to one directly associated with a particular physical device.

[0032] Accordingly, the target device HISM 204 is configured to parse through the I₂O message request received via signal line 208 and appropriately translate it to a form that is best suited to be understood by the silicon circuitry and firmware module 216 being implemented. Additionally, the target device HISM 204 is able to interface more efficiently with the block storage OSM 202 because it is situated on the host computer side of the PCI interface 212, as opposed to the prior art, which has the target device on the other side of the PCI interface and significant latency-increasing logic. This provides a significant improvement in performance and thus, the I₂O messages will be more expeditiously and efficiently handled as opposed to the prior art technique of implementing an auxiliary processor that is physically coupled on the other side of the PCI interface.

[0033] Assuming that the block storage OSM 202 generated an I₂O message that was configured to request reading of data from the SCSI peripheral device 218 (i.e., a hard disk drive or the like), that I₂O message would be communicated to the target device 204 HISM and then communicated to the silicon circuitry and firmware module 216 in accordance with the proper translation scheme. The silicon circuitry and firmware would then process the message and provide the appropriate reply back through the PCI interface 212 to the target device HISM 204. Generally, the reply that is generated from the silicon circuitry and firmware module 216 will be produced after the silicon and firmware appropriately respond with the data and that data is properly stored in a suitable memory location. Such data storing operation can be accomplished through the use of any memory access protocol, and one such exemplary protocol is a well known direct memory access (DMA) data transfer.

[0034] Typically, the silicon circuitry and firmware module 216 will have the appropriate sequencers and firmware to operate on the I₂O message requests received from the target device HISM 204. However, there are situations where the silicon circuitry and firmware module 216 are incapable of processing the request for one reason or another. When this occurs, a successful reply will not be generated and subsequently transferred back to the PCI interface 212 by the silicon circuitry and firmware module 216. To handle such a situation, the exception operating system module (EOSM) driver 206 is configured to handle any such errors implementing the following exception handling algorithm.

[0035] In this embodiment, each time the block storage OSM 202 generates an I₂O message request to the target device 204, the exception OSM driver 206 will be configured to read the request via a communication 222 that implements a pull technique. If an error occurs in the processing by silicon circuitry and firmware module 216, the exception OSM driver 206 using the request signal 222, will be able to observe the I₂O message request and simultaneously cache a copy of that request in a queue 205.

[0036] If an event error occurs during the processing of the request by the silicon circuitry and firmware module 216, the exception OSM driver 206, which is designed to generally be in idle state to preserve processing overhead, will wake up and respond by receiving the event reply 224 from the silicon and firmware module 216, provided that the exception OSM driver 206 has this type of error registered and will execute the appropriate software strategy routines to handle such an error. As will be described below in table A, the exception OSM driver 206 will preferably have all I₂O specific detailed status codes registered for the type of silicon. Other chip-specific error codes may also be registered in a like manner.

[0037] At this point, a hardware interface module (HIM)-sequence exception dialog 226 communication will be established between the exception OSM driver 206 and the silicon circuitry and firmware module 216. This interface is in essence, a fully enabled software interface, and not just a register level interface. In this manner, the HIM-sequence exception dialog can function in conjunction with the exception OSM driver to troubleshoot the problem or event error experienced by the silicon circuitry and firmware module 216.

[0038] If possible, the exception OSM driver will attempt to fix the detected error associated with the processing by the silicon circuitry and firmware module 216, and then generate an I₂O exception (e.g., backup) reply via 207 back to the block storage OSM 202. In this manner, the exception OSM driver 206 is therefore set up to step in and troubleshoot any errors that may occur in the processing of the request by the silicon circuitry and firmware module 216, and then generate a proper I₂O exception reply to the block storage OSM 202. This I₂O exception reply is therefore configured to substitute the I₂O reply that would have been provided by signal 210 if the error had not occurred. However, when an error does occur, the normal I₂O reply via signal 210 will typically not be possible.

[0039] Advantageously, the exception OSM driver 206 is well suited to step in and complete the reply to the block storage OSM 202 without disrupting the functionality between the host computer and the target device. A further advantageous feature is that the exception OSM driver 206 is generally in an idle state during most of the time I₂O communications are being exchanged, and very little host processor overhead is consumed by the exception OSM driver 206.

[0040] In most circumstances, proper communication between the block storage OSM 202, the target device 204 and ultimately, with the desired peripheral device, will operate very lean on host processor overhead. However, in those cases where an error occurs, the exception OSM driver 206 will swiftly move in to determine what the error may have been, attempt to repair the error if possible, and then provide the proper I₂O reply to the block storage OSM 202. In some cases, the I₂O exception reply provided by the exception OSM driver 206 will be a reply that indicates completion with error or retry occurred. In other cases, the reply will simply indicate that an error occurred and that the error could not be remedied.

[0041] FIG. 3 illustrates a more detailed flowchart diagram of the method operations performed by the exception operating system module (OSM) driver 206 in accordance with one embodiment of the present invention. Initially, an event notification request is generated by the exception OSM driver in operation 250. Once the exception OSM driver has generated the event request, the method will proceed to an operation 252 where the I₂O message request generated by the block storage OSM 202 is observed and a copy of the request is cached in a suitable memory location.

[0042] The method now proceeds to a decision operation 254 where it is determined whether a successful I₂O reply has been received by the block storage OSM 202 from the silicon circuitry and firmware module 216. If it is determined that a successful I₂O reply is successfully received, the method will proceed to an operation 256 where the cache memory is cleared to discard the copy of the request. The method will then proceed back to operation 252 where the next I₂O request message is observed and cached in memory. If it is determined that a successful I₂O reply was not received, the method will proceed to an operation 258 where an event reply is received from the silicon circuitry and firmware due to the existence of an error event.

[0043] Upon receiving notice of the error event, the method will proceed to an operation 260 where a hardware interface module (HIM)-sequencer exception dialog is invoked. The hardware interface module-sequencer exception dialog is configured to perform hardware-specific diagnostics at a low level in order to determine the source of the exception error and attempt to correct the problem. In general, the HIM-sequencer exception dialog is well suited to perform, for example, register level writes and reads in order to ascertain the source of the problem, perform error correction, or the like. If the problem is determined to be one that can be corrected, the HIM-sequencer exception dialog will attempt to repair the error condition.

[0044] In operation, detailed status codes, such as those status codes in table A, are provided by the exception OSM driver 206 to signal the error using a reply via signal 207.

[0045] The method will proceed to an operation 262 where a reply on behalf of the block storage OSM is built by the exception OSM driver 206. This reply is essentially an I₂O exception reply which will substitute the reply that was intended to be sent back to the block storage OSM if no error had occurred. Once the reply is been properly built in operation 262, the method will proceed to an operation 264 where the reply is transferred to the block storage OSM from the exception OSM driver. Typically, the reply provided by the exception OSM driver to the block storage OSM is one that provides information of whether there was an error in conjunction with the reply being sent, and the type of error that may have been fixed due to any number of well known problems, such as those of table A.

[0046] Once the transfer of the I₂O exception reply has been provided to the block storage OSM, the method will proceed back up to operation 250 where an event request is generated by the exception OSM driver to begin the method anew. The process will therefore continue during the messaging performed between the host computer OS and the silicon circuitry and firmware module 216. It should be understood that in most cases, the communication link between the block storage OSM 202 and the target device 204 of FIG. 2, will work flawlessly to communicate I₂O requests and receive I₂O replies to and from the silicon circuitry and firmware module 216.

[0047] In essence, the target device 204 is a lean and powerful host intermediate service module (HISM) that can operate as a RAID driver, however, it will not include the additional code for handling exceptions, which is more advantageously handled by the exception OSM driver 206. This therefore, provides for a target device HISM RAID driver that is more efficiently executed during normal operation without the need for cumbersome exception handling software code. At the same time, the exception operating system module (OSM) driver 206 of FIG. 2 will generally lie idle during normal transfers between the block storage OSM 202 and the silicon circuitry and firmware 216. Only when some kind of an error or failure has been detected will the exception OSM driver 206 wake up to handle the necessary exception processing.

[0048] As such, the normal I₂O message handling will be provided with exceptional performance that is substantially more efficient and faster than a system that incorporates exception handling code that is continually executed. In addition, as mentioned above, the target device host intermediate service module (HISM) RAID driver 204 is capable of handling more efficiently the I₂O messaging between the block storage OSM 202, as compared to the prior art which relied on the target device that was integral with the input/output processor 106, that resides on the other side of the PCI interface with respect to the host computer. As such, much more streamlined I₂O communication between the host computer and the selected silicon circuitry and firmware module 216 will be provided, without the need for cost increasing I/O processors, real-time OS's and associated hardware.

[0049] The invention may employ various computer-implemented operations involving data stored in computer systems to drive computer peripheral devices (i.e., in the form of software drivers). These operations are those requiring physical manipulation of physical and logical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. Further, the manipulations performed are often referred to in terms, such as producing, identifying, determining, or comparing.

[0050] Any of the operations described herein that form part of the invention are useful machine operations. The invention also relates to a device or an apparatus for performing these operations. The apparatus may be specially constructed for the required purposes, or it may be a general purpose computer selectively activated or configured by a computer program stored in the computer. In particular, various general purpose machines may be used with computer programs written in accordance with the teachings herein, or it may be more convenient to construct a more specialized apparatus to perform the required operations.

[0051] Although the foregoing invention has been described in some detail for purposes of clarity of understanding, it will be apparent that certain changes and modifications may be practiced within the scope of the appended claims. Accordingly, the present embodiments are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.