US 6,282,673 B1Grant

Method of recording information system events

Issue Date:2001-08-28

•40 Claims

•6 Drawing Sheets

Abstract

A method of recording events occurring in an information processing system in a memory unit. A system recorder is used as part of a server system which supports communication of digital information for a microcontroller network. The server system monitors the status of several system functions including temperature, cooling fan speeds, and the presence or absence of canisters and power supplies. The system updates the pertinent event messages and identification codes in the memory unit including the time such event or change in status occurred.

Metadata

Assignee

Micron Technology, Inc.

Inventors

Ji-hwan Liu
Ken Nguyen
Karl S. Johnson

Application Information

Application Number:US 08/942,164

Filing Date:1997-10-01

Priority Date:1997-05-13

Art Unit:7

Classifications

IPC:

H02H 305H03K 19003H04B 174H04L 122

Field of Search:

714 25714 4714 39714 47714 45714 57714723714701711 1711100711171711173711201360 5710 8710 15710 17710 18710 19

Patent Drawings (6 sheets)

Description

[0002] The subject matter of U.S. Patent Application entitled BLACK BOX RECORDER FOR INFORMATION SYSTEM EVENTS, filed on Oct. 1, 1997, application Ser. No. 08/942,381.

Priority Claim

[0003] The benefit under 35 U.S.C. §119(e) of the following U.S. provisional application(s) is hereby claimed:

Appendices

[0004] Appendix A, which forms a part of this disclosure, is a list of commonly owned copending U.S. patent applications. Each one of the applications listed in Appendix A is hereby incorporated herein in its entirety by reference thereto.

Copyright Rights

[0005] A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.

Background of the Invention

[0006] 1. Field of the Invention

[0007] The invention relates generally to information processing systems, such as system servers and personal computers (PCs). More particularly, this invention relates to the management and maintenance of information system failures.

[0008] 2. Description of the Related Art

[0009] Information processing systems, such as computer system servers, have virtually become an inseparable part of information processing networks. These systems communicate and process an enormous amount of information in a relatively short time. To perform these sophisticated tasks, a computer system server typically includes various subsystems and components such as a plurality of microprocessors, memory modules, various system and bus control units, and a wide variety of data input/output (I/O) devices. These computer components communicate information using various data rates and protocols over multiple system buses. The demand for faster processing speeds, and the revolutionary fast-track development of computer systems, have necessitated the use of interconnecting devices. The wide variety of these devices, coupled with various data transfer protocols, have added special complexity to the management and maintenance of faults occurring in such information systems.

[0010] To facilitate the understanding of the invention, a brief description of the I²C bus protocol is first provided. FIG. 1 is a functional block diagram of an exemplary I²C bus application. As shown in FIG. 1, an I²C Bus 100 is provided to support data transfer among a variety of I²C devices. The I²C Bus 100 is a serial interface bus that allows multiple I²C devices to communicate via a bi-directional, two-wire serial bus. The I²C Bus 100 comprises two wires: a serial data line (SDA) 102 and a serial clock line (SCL) 104. The SDA 102 carries data transmissions among I²C devices, and the SCL 104 carries the clock timing information that synchronizes the data transmission. A complete system usually consists of at least one microcontroller and other peripheral devices such as memory units and input/output (I/O) expanders for transferring data on the I²C Bus 100. These peripheral devices may include liquid crystal display (LCD) and light emitting diode (LED) drivers, random access memory (RAM and read only memory (RON devices, clock/calendars, I/O expanders, analog-to-digital (A/D) and digital-to-analog (D/A) converters.

[0011] As shown in FIG. 1, a micro-controller A 106 and a micro-controller B 108 are coupled to the I²C Bus 100 for exchanging information on the I²C Bus 100. Additionally, an I²C-ISA Interface 110 is connected to the P²C Bus 100 to provide access interface between industry standard architecture (ISA) devices and I²C devices. A LCD driver 112 is coupled to the I²C Bus 100 for displaying information accessed from other I²C devices located on the I²C Bus 100. An I/O Expander 114 is also coupled to the I²C Bus 100 to enable I/O devices (not shown in this figure) to obtain direct access to the I²C Bus 100. Moreover, a memory device 116 such as a RAM or an electrically erasable programmable read only memory (EEPROM) is also coupled to the I²C Bus 100 to provide storage of data transmitted by other I²C devices.

[0012] Each device connected to the I²C bus is software addressable by a unique address and simple master/slave relationships exist at all times. The term “master” refers to an I²C device which initiates a transfer command to another I²C device, generates clock signals, and terminates the transfer on the I²C bus. The term “slave” refers to the I²C device which receives the transfer command from the master device on the I²C bus. The P²C bus is a true multi-master bus which includes collision detection and arbitration to prevent data corruption if two or more masters simultaneously initiate data transfer. Moreover, I²C devices act as transmitters and receivers. A “transmitter” is the I²C device which sends the data to the I²C Bus 100. A “receiver” is the I²C device which receives the data from the I²C Bus 100. Arbitration refers to a procedure whereby, if more than one master simultaneously attempts to control the I²C Bus 100, only one is allowed to do so and the transmitted message is not corrupted.

[0013] The I²C Bus 100 supports up to 40 I²C devices and may have a maximum length of 25 feet. The I²C Bus 100 supports a transfer data rate of up to 100 kilobits/second (kbps) in “standard mode,” or up to 400 kbps in “fast mode.” Data transfers over the I²C Bus 100 follow a well-defined protocol. A transfer always takes place between a master and a slave. All bus transfers are bounded by a “Start” and a “Stop” condition. In the standard mode, the first byte after the Start condition usually determines which slave will be selected by the master. In the fast mode, the first two bytes after the Start condition usually determine which slave will be selected by the maser. Each peripheral device on the I²C Bus 100 has a unique 8-bit address in the standard mode, or a 10-bit address in the fast mode. The address is hard-coded for each type of I²C device, but some devices provide an input pin that allows a designer to specify one bit of the device's I²C address. This allows two identical I²C devices used on the same bus to be addressed individually.

[0014] With the increased complexity of information processing systems, the frequency of system failures due to system- and component-level errors has increased. Some of the problems are found in the industry standard architecture (ISA) bus used in IBM PC-compatible computers. The enhanced ISA (EISA) provided some improvement over the ISA architecture of the IBM PC/AT, but more resistance to failure and higher performance are still required. Other problems may exist in interface devices, such as bus-to-bus bridges. Additionally, problems may exist in bus peripheral devices such as microcontrollers, central processors, power supplies, cooling fans, and other similar components.

[0015] With these added components and subsystems, occasional system failures have become inevitable. Existing information systems do not currently provide a tool for managing these failures. More importantly, present systems do not possess the means to more efficiently diagnose and restore the system from the occurrence of such failures. Therefore, when failures occur, there is a need to identify the events leading up to these failures. The ability to identify the events leading up to system failures minimizes downtime and ensures more efficient system maintenance and repair in the future.

Summary of the Invention

[0016] One embodiment of the invention provides a method of recording event messages with a real-time stamp in a memory unit. The method records an event occurring in an information processing system having a computer bus and a system recorder. The method comprises the act of accessing the system recorder via the computer bus, transmitting a message to the system recorder in response to the event, and storing the message in a memory unit.

Brief Description of the Drawings

[0017] The invention will be better understood by referring to the following detailed description, which should be read in conjunction with the accompanying drawings, in which:

[0018] FIG. 1 is a functional block diagram of an exemplary I²C bus application.

[0019] FIG. 2 is a functional block diagram of one embodiment of the invention.

[0020] FIG. 3 is a flow chart describing the decisional steps performed by one embodiment of the system recorder.

[0021] FIG. 4 is a flow chart describing the steps of performing an exemplary read from and/or write operations to a first block of the memory unit.

[0022] FIG. 5 is a flow chart describing the steps of performing an exemplary read operation from a second block of the memory unit.

[0023] FIG. 6 is a flow chart describing the steps of performing an exemplary write operation to a second block of the memory unit.

Detailed Description of the Invention

[0024] The invention provides a method of recording a time-stamped history of events leading up to the failure of an information system server. The method may be applied to a black box recorder (hereinafter the “System Recorder”). One embodiment of the invention involves system operation on an Inter-Integrated-Circuit (I²C) bus. The operation of the System Recorder on an I²C bus should not, however, be construed to imply any limitations on the bus protocol which may be used with this invention. The invention may be implemented using virtually any bus protocol.

[0025] Referring now to FIG. 2, a functional block diagram of an embodiment of the invention is shown. This embodiment depicts a system server 200 which comprises the so-called “Intrapulse” system. The system server 200 is a network of microcontrollers integrated to support the transfer of data messages within the system server 200. The system server 200 performs control and monitoring functions of processing units, power supplies, cooling fans, and similar functions. To achieve its monitoring objective, the system server 200 utilizes a variety of control, diagnostic, monitoring, and logging processors. The system server 200 may employ switches, indicators, or other controls to perform its monitoring and control functions. Optionally, the system server 200 need not employ any switches, indicators, or other controls, to perform these functions. This characteristic is often referred to as the “fly-by-wire” feature.

[0026] The system server 200 is a part of and supports one or more microcontroller networks (not shown in this figure). A microcontroller network further includes a variety of peripheral components such as AC/DC power supplies and cooling fans. The system server 200 may be divided into two main subsystems: the system board 202 and the back plane 204. Communication between main system processing units (e.g., CPU 212) and the system interface 214 on the system board 206 is supported by an industry standard architecture (ISA) Bus 208. Communication among the devices located on the back plane 204 is supported by an I²C Bus 210. The I²C Bus 210 also supports communication between the back plane 204 and the system board 206.

[0027] The system board 206 comprises a system interface 214 and a plurality of central processor units (CPUs) including CPU “A Controller” 216 and CPU “B Controller” 218 interconnected via the I²C Bus 210. One or more system CPU 212 communicates with the devices on the system board 206 via an ISA Bus 208. The system interface 214 provides a bridging function between the CPU 212 and the A Controller 216 and B Controller 218 on the system board 206. In addition, the system interface 214 interconnects the CPU 212 with other devices on the I²C Bus 210. A remote interface 240 is connected to the system board 206 to allow remote access by outside clients to the system server 200. Using a client modem 244, a client computer 246 accesses a server modem 242 via a remote link 243. The server modem 242 is typically directly connected to the remote interface 240 to support communication between the server system 200 and the client computer 246.

[0028] The back plane 204 includes a system recorder 220 and a chassis controller 222 interconnected via the P²C Bus 210. The system recorder 220 includes a real-time clock (RTC) 221. Additionally, a non-volatile random access memory (NVRAM) 224 is directly connected to the system recorder 220. A plurality of canister controllers are also coupled to the I²C Bus 210 to communicate with devices located on the back plane 204 and the system board 206. These canister controllers include “Canister Controller A” 232, “Canister Controller B” 234, “Canister Controller C” 236, and “Canister Controller D” 238 (the “canister controllers”). Generally, a canister is a detachable module which provides expendability to a plurality of peripheral component interconnect (PCI) devices. FIG. 2 does not show the canister controllers as part of the back plane 204 because they are removable units,

[0029] One embodiment of the system recorder 220 is a high-performance, CMOS, fully-static, 8-bit microcontroller which controls read and write operations from and into the NVRAM 224, respectively. The system recorder 220 of FIG. 2 has a multi-level deep stack, and multiple internal and external interrupt sources. The system recorder 220 may employ a Harvard architecture for allowing a 14-bit wide instruction word with separate 8-bit wide data. The system recorder 220 has 192 bytes of RAM and 33 I/O pins. In addition, several peripheral features are available, including: three timer/counters, two Capture/Compare modules, and two serial ports. The system recorder 220 can directly or indirectly address its register files or data memory. All special function registers including the program counter are mapped in the data memory. The system recorder 220 has a synchronous serial port which may be configured as either a two-wire I²C bus or a 3-wire serial peripheral interface (SPI). An 8-bit parallel slave port is also provided. The system recorder 220 may be based on microcontrollers manufactured by Microchip Technology Inc., e.g., the PIC16C6X family of microcontrollers.

[0030] The RTC 221 is integrated in the system recorder 220 on the back plane 204. The RTC 221 comprises two 32-bit counters which keep track of real time and elapsed time in seconds. The RTC 221 comprises a four-byte field (i.e., 32 bits) for recording time for over 125 years (2{circumflex over ( )}32 seconds) without having to reset itself. It is designed to count seconds when its input power (V_cc) is applied and continually count seconds under battery backup regardless of the condition of V_cc. The continuous counter is used to derive time of day, week, month, and year by using a software algorithm. Alternatively, the RTC 221 is used under the control of the system recorder 220 to record real time events. Communication to and from the RTC 221 takes place via a 3-wire serial port. A one byte protocol selects read/write functions, counter clear functions and oscillator trim. The RTC 221 records real time in an absolute format. The O/S uses a reference point in time in order to synchronize the RTC 221 with the standard 24-hour time format.

[0031] One embodiment of the NVRAM 224 is a 128-kbyte memory unit which is organized as 131,072 words by 8 bits. Each NVRAM 224 has a self-contained lithium energy source and control circuitry which continuously monitors its input voltage (V_cc) for an out-of tolerance condition (e.g., +/− 10% of 5 Volts). When such a condition occurs, the lithium energy source is automatically switched on and write protection is unconditionally enabled to prevent data corruption. With special firmware, the NVRAM 224 is divided into two blocks: a first block having 64 kbytes of-memory space, and a second block having 64 kbytes of memory space. The first block of the NVRAM 224 is a fixed-variable memory block which stores ID codes of the devices installed in the network. In addition to ID codes, the first block of NVRAM 224 may also store one or more address pointers, each pointing to a memory address in the second block of NVRAM 224. An address pointer may be a head pointer (indicating a start address) or a tail pointer (indicating an end address). The second block is a memory block which stores message codes in connection with events occurring in the network. The NVRAM 224 may be based upon devices manufactured by Dallas Semiconductor Corporation, e.g., the DS1245Y/AB 1024K Nonvolatile SRAM.

[0032] Once the system server 200 is powered on, the system recorder 220 writes an internal message entry to the NVRAM 224. When the power up process is enabled, the back plane 204 monitors the status of several system events and functions. These functions may include system temperature, fan speeds, and changes in the installation or presence of canisters and power supplies. Non-specific or general faults on most devices in the microcontroller network may be monitored in a summary bit. However, the fans, canisters, and temperature of the CPU may be monitored with particularity.

[0033] The back plane 204 monitors a plurality of temperature sensors located on a temperature bus (not shown in this figure) once every predetermined time interval, e.g., every second. Each temperature sensor comprises a transducer connected to and having an address at a serial bus (not shown in this figure) on the back plane 204. These transducers are read in the same sequence as their address order. The temperature may range between −25 and +70 degrees Celsius. If any of the temperature sensors reaches +55 degrees Celsius, or −25 degrees Celsius, then a warning is issued, and a message corresponding to that event is written to the NVRAM 224, and sent to other destinations via the system interface 214 and the remote interface 240. If any of the temperature sensors reaches +70 degrees Celsius, then a shutdown command is typically issued and the system is powered off.

[0034] The back plane 204 monitors the presence of the canisters several times per second. There are several methods to determine the presence or absence of a canister. To monitor the canister corresponding for Canister Controller A 232 for example, the chassis controller 222 sends a reset pulse to that canister, preferably through a direct one-wire serial bus connection. If the canister is changed/replaced, then the chassis controller 222 updates a canister presence bit accordingly and sends a canister event message to the system recorder 220 and remote interface 240, preferably via the I²C Bus 210. The system recorder 220 replaces the ID code (e.g., a serial number string) of the previous canister (corresponding to Canister Controller A 232) by the ID code of the current canister in the NVRAM 224 accordingly. If a canister is removed from the server system 200, then the length of the ID code string of that (absent) canister is set to zero. However, if a new canister is installed in its place, the ID code of the new canister is written to the NVRAM 224. Serial numbers are typically stored in NVRAM 224 in BCD format.

[0035] Similarly, the back plane 204 monitors the presence or absence of power supplies several times per second. To monitor a particular power supply, the chassis controller 222 transmits a reset pulse to detect a pulse of the power supply, preferably via a direct one-wire serial bus. If a power supply is replaced, the chassis controller 222 updates the presence bit for that power supply and sends a message corresponding to that power supply event to the NVRAM 224 and the remote interface 240. If a power supply is removed from the network, then the length of the ID code (e.g., serial number string) of that (absent) power supply is set to zero. However, if a new power supply is installed in the network, the system recorder 220 writes the ID code of that power supply into the NVRAM 224.

[0036] Similarly, the back plane 204 may monitor the speeds of the cooling fans of all CPUs in the same sequence as the CPU's address order. For instance, the cooling fan of the system board 206 generally has a low-speed limit of about 30 revolutions per second (rps). Moreover, the cooling fan of a canister typically has a low-speed limit of about 20 rps. If the speed of any fan falls below its set low limits, a fan fault corresponding to that fan is issued. In addition, the system recorder 220 writes a fan event message into the NVRAM 224. Corrective measures such as setting a fan fault LED on, and setting the fan speed to high, may also be performed.

[0037] The protocol of the I²C Bus 210 uses an address in the memory NVRAM 224 of the system server 200 as the means of identifying various control and diagnostic commands. Any system function is queried by generating a “read” request. Conversely, a function can be executed by generating a “write” request to an address specified in the protocol format. An I²C device in the system server 200 initiates read and write requests by sending a message on the I²C bus. A read or write request may consist of a payload, a message, and a packet. A payload is the data included in the request command. A message is a wrapper around the payload. In addition to the data, the message includes a slave address, a least significant bit (LSBit), a most significant bit (MSBit), a data type, a command ID (LSByte and MSByte), and status. A packet is a wrapper around a message that is transferred to the ISA Bus 208. The packet includes check sum and inverted slave address fields.

[0038] The slave address is typically a 7-bit wide field which specifies the identification code of a slave device. The slave address usually occupies the first byte of the message. The LSBit may specify the type of activity that is taking place on the bus. If the LSBit is set to 1 (i.e., high), the master is reading from a slave device. If the LSBit is set to 0 (i.e., low), then the master is writing to a slave device. The MSBit is bit 7 of the second byte (0-7 bits) of the message which specifies the type of command being executed. If the MSBit is set to a 1, then the command is a read command. If the MSBit is set to a 0, then the command is a write command. The data type specifies the data format of a read or write command. There are several data types that may be used in the server system 200. The data types include: a bit data type, a byte data type, a string data type, a log data type, an event data type, a queue data type, a byte array data type, a lock data type, and a screen data type. These data types determine the value specified in the Type field of a message.

[0039] A bit data type is typically used for a simple logic value, such as True (1) and False (0), or On (1) and Off (0). The byte data type is used for a single-byte value, with a variable length of 0 through FF (hexadecimal). A string data type is used for a variable-length string of data having a length of 0 to FF bytes. The log data type is used to write a byte string to a circular log buffer, such as the NVRAM 224. The log data type records system events in the NVRAM 224. A byte array data type is used for general data storage which is not anticipated in the implementation of the Intrapulse system. An event data type is used to alert external interfaces of certain events occurring in the system server 200, such as status changes in the CPU, power supplies, canisters, cooling fans, temperature, screen, queue, and O/S timeout. A screen data type is used to communicate character mode screen data from BIOS to time remote interface unit 240.

[0040] The command ID (LSByte) specifies the least significant byte of the device address. Command ID (MSByte) specifies the most significant byte of the device address. The status byte specifies whether or not a command has been executed successfully. A non-zero entry indicates an execution failure. The check sum byte specifies a direction control byte to ensure the integrity of a message on the bus. The check sum byte is typically calculated in the system server 200 firmware. Finally, the inverted slave address byte specifies the slave address in an inverted format. The inverted slave address byte is also calculated in the system server 200 firmware.

[0041] Referring now to FIG. 3, a flow chart is provided for describing the decisional steps performed by the system recorder 220 upon receiving interrupt commands from other microcontrollers. At step 302, the system recorder 220 is typically in an idle state, i.e., waiting for commands from other microcontrollers in the network. At step 304, the system recorder 220 determines if an interrupt command is detected from other microcontrollers. If no interrupt command is detected, then at step 306, the system recorder 220 checks if a reset command is received from other microcontrollers. A reset command is a request to clear the all memory cells in the NVRAM 224. If a reset command is detected, then at step 308, the system recorder 220 clears all memory cells in the NVRAM 220 and returns to its idle state at step 302, and the entire process repeats itself. If a reset command is not detected, then at step 310, the system recorder 220 updates the RTC 221 time every one second. At this step, the system recorder 220 reads the real time clock and saves the real time in its local register (not shown in this figure).

[0042] If, at step 304, an interrupt command is detected from other microcontrollers, the system recorder 220 determines the type of data in the interrupt command at step 312. For the purpose of logging message events in the NVRAM 224, the log data and event data type are pertinent. As noted above, the log data type is used to write a byte string to a circular log buffer, such as the NVRAM 224. The log data type records system events in the NVRAM 224. The maximum number of bytes that can be written in a log entry is 249 bytes. For some embodiments of the invention, the system recorder 220 adds a total of six bytes at the beginning of the interrupt command: a two-byte identification code (ID), and a four-byte timestamp for recording the real time of the occurrence of the system event.

[0043] Based on the interpretation of the data type at step 314, the system recorder 220 determines whether the interrupt command is intended to be communicated to the first block or second block of the NVRAM 224. If the interrupt command is intended to go to the first block of NVRAM 224, then the process described in FIG. 4 is followed. If the interrupt command is not intended to be transmitted to the first block of NVRAM 224, then it is intended to go to the second block of NVRAM 224. At step 316, the system recorder 220 determines whether the interrupt command is a read or write command for the second block. If the interrupt command is a read command, then the process described in FIG. 5 is followed. If the interrupt command is not a read command, then it is a write command and the process described in FIG. 6 is followed.

[0044] Referring to FIG. 4, a flow chart is provided for describing the steps of performing a read from and/or write to the first block of the NVRAM 224. As noted above, the first block of the NVRAM 224 is a 64-kbyte memory block. The first block is a fixed-variable memory block which stores ID codes of the devices installed in the network. Hence, a command addressed to the first block is typically generated by a controller (e.g., chassis controller 222) responsible for updating the presence or absence of devices in the network. The process described in FIG. 4 is followed when, at step 314 (shown in FIG. 3), the system recorder 220 determines that the command interrupt is intended for the first block of the NVRAM 224.

[0045] As shown in FIG. 4, at step 402, the system recorder 220 determines whether the interrupt command is to read from or write to the NVRAM 224. If the command interrupt is a read command, then at step 404, the system recorder 220 loads the address pointer at the intended address location in NVRAM 224. At step 406, the system recorder 220 reads the intended message from the address location in the NVRAM 224, and forwards the read data to the master device (i.e., device requesting the read operation) in the network. After the read operation is complete, at step 412, the system recorder 220 issues an interrupt return command to return to its idle state at step 302 (shown in FIG. 3).

[0046] If at step 402 the system recorder 220 determines that the interrupt command is a write command, then at step 408, the system recorder 220 loads the address pointer at the intended address location in NVRAM 224. The system recorder 220 typically checks on the availability of memory space in NVRAM 224 prior to executing a write operation (see FIG. 6 for details). At step 408, the system recorder 220 writes the event message to the address location in the NVRAM 224, and forwards a confirmation to the master device in the network. After the write operation is complete, at step 412, the system recorder 220 issues an interrupt return command to return to its idle state at step 302 (shown in FIG. 3).

[0047] Referring now to FIG. 5, a flow chart is provided for describing the steps of performing a read operation from the second block of the NVRAM 224. As noted above, the second block of the NVRAM 224 is a 64-kbyte memory block. The second block is a memory block which stores event messages in connection with events occurring in the network. Hence, a command addressed to the second block is typically generated by a controller responsible for updating the occurrence of such events. The process described in FIG. 5 is followed when, at step 316 (shown in FIG. 3), the system recorder 220 determines that the interrupt command is a read command intended to be transmitted to the second block of the NVRAM 224.

[0048] As shown in FIG. 5, if the system recorder 220 determines that the interrupt command is a read operation, then at step 502, the system recorder 220 loads an address pointer to the intended address in the second block of NVRAM 224. At step 504, the system recorder 220 performs a read operation of the first logged message from the NVRAM 224 commencing with the intended address location. For a read operation, it is preferable that only the 65534 (FFFEh) and 65533 (FFFDh) addresses be recognized. The address 65534 specifies the address of the oldest valid message. The address 65533 specifies the address of the next message following the last message read from the log in NVRAM 224. The last address in the second block of the NVRAM 224 is 65279 (FEFFh). This is also the address at which the system recorder 220 performs a pointer wrap operation (see FIG. 6 for details). In doing so, the system recorder 220 redirects the address pointer to the beginning of the second block of the NVRAM 224. Hence, the address of the next message address after the 65279 address is 0. To perform a read operation of the entire second block in a chronological order, the timestamp is read first. Then, the message logged at address 65534 is read second. This message constitutes the first logged message. Then, the message logged at address 65533 is read next. This message is the next logged message. Then, the message logged at address 65533 is read again to read all subsequently logged messages. The reading at address 65533 terminates until the status field returns a non-zero value.

[0049] At step 506, the system recorder 220 determines whether the address location has reached the end of the second block in the NVRAM 224. If the address location has not reached the end of the second block, then at step 508, the system recorder 220 performs a read operation of the next logged message using the addressing scheme described above. The system recorder 220 transmits all read messages to the master device via the I²C bus. If the address location has reached the end of the second block, then at step 510, the system recorder 220 issues an interrupt return command to return to its idle state 302 (shown in FIG. 3).

[0050] Referring now to FIG. 6, a flow chart is provided for describing the steps of performing a write operation to the second block of the NVRAM 224. Typically, a command addressed to the second block is generated by a controller (e.g., chassis controller 222) responsible for updating the occurrence of such events. The process described in FIG. 6 is followed when, at step 316 (shown in FIG. 3), the system recorder 220 determines that the interrupt command is a write command directed to the second block of the NVRAM 224.

[0051] As shown in FIG. 6, if the system recorder 220 determines that the interrupt command is a write command, then at step 602, the system recorder 220 loads an address pointer to the intended address in the second block of NVRAM 224. At step 604, the system recorder 220 determines whether a memory space is available in the second block of NVRAM 224 to perform the requested write operation. If a memory space is not available in the second block, then at step 606, the system recorder 220 performs a pointer wrap operation. In doing so, the system recorder 220 redirects the address pointer to the beginning of the second block of the NVRAM 224. The system recorder 224 erases the memory space corresponding to a single previously logged message which occupies that memory space. Additional previously logged messages are erased only if more memory space is required to perform the present write operation.

[0052] If the system recorder 220 determines that a memory space is available in the second block of the NVRAM 224, then at step 608, the system recorder 220 fetches the time from the real-time clock 221 and stamps (i.e., appends) the real time to the message being written. As noted above, the real time comprises a four-byte field (i.e., 32 bits) which are appended to the message being written. At step 610, the system recorder 220 writes the time-stamped message to the second block of the NVRAM 224. At step 612, the system recorder 220 issues an interrupt return command to return to its idle state 302 (shown in FIG. 3).

[0053] Upon the occurrence of a system failure, system maintenance personnel retrieve the logged event messages in a chronological fashion to identify and trace the events leading up to the time of when such failure occurred. As a result, the system failure is easily repairable with minimal downtime.

[0054] In view of the foregoing, it will be appreciated that the invention overcomes the longstanding need for logging and recording the occurrence of information system events leading up to the occurrence of system failures without the disadvantages of having complex failure diagnosis. The invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive and the scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

Certificate of Correction present

The claims shown below may not include correction changes. Use the corrected PDF for authoritative text.

What is claimed is:

1. A method of recording an event occurring in an information processing system having a computer bus and a system recorder, said method comprising:

accessing the system recorder via the computer bus;

transmitting a message to the system recorder in response to the event, wherein said message comprises a plurality of bits representing at least a slave address, a least significant bit, a most significant bit, a data type a command ID, and a status field; and

storing the message in a memory unit.

2. The method as defined in claim 1, wherein the act of accessing the system recorder includes the act of accessing a real-time clock for time-stamping said message.

3. The method as defined in claim 1, wherein the act of storing the message includes the act of storing the message in a non-volatile random access memory (NVRAM) unit having an exclusive power source.

4. The method as defined in claim 1, wherein the act of storing in the memory unit includes the act of storing in a plurality of memory blocks, wherein one block of the plurality of memory blocks stores a device identification code.

5. The method as defined in claim 4, wherein another block of the plurality of memory blocks stores an event message.

6. The method as defined in claim 1, wherein the act of accessing the system recorder includes the act of supporting a read operation from the memory unit.

7. The method as defined in claim 1, wherein the act of accessing via the computer bus includes the act of accessing via an inter-integrated-circuit (I²C) bus.

8. In an information processing system having a plurality of components and experiencing first-type and second-type events, a method of storing the events comprising:

receiving a signal indicative of at least one of the first-type and the second-type events;

storing information relating to the first-type event associated with one of the plurality of components in a first block of a memory; and

storing information relating to the second-type event associated with one of the plurality of components in a second block of the memory in a wrap around sequence, wherein said signal comprises at least a message of a failure in one of the plurality of components, and wherein the first and the second blocks of the memory are configured to store the information without restriction of time.

9. The method as defined in claim 8, wherein the act of storing the information relating to the first-type event includes the act of storing at least an identification number.

10. The method as defined in claim 8, wherein the act of storing the information relating to the first-type event includes the act of storing the an event message relating to a change in the presence of one of the plurality of components.

11. A program storage device storing instructions that when executed by a computer perform a method of recording an event occurring in an information system processing having a computer bus and a system recorder, said method comprising:

accessing the system recorder via the computer bus;

storing the message in a memory unit.

12. The device as defined in claim 11, wherein the method further comprises time-stamping sad message for storage.

13. The device as defined in claim 11, wherein storing the message includes storing the message in a non-volatile random access memory (NVRAM) having an exclusive source.

14. The device as defined in claim 11, wherein storing the message includes storing the message in a plurality of memory blocks, and wherein one block of the plurality of memory blocks stores a device identification code.

15. The device as defined in claim 14, wherein another block of the plurality of memory blocks stores an event message.

16. The device as defined in claim 11, further comprising performing a read operation from the memory unit.

17. The device as defined in claim 11, wherein accessing the system recorder via the computer bus includes accessing the system recorder via an inter-integrated circuit (I²C) bus.

18. A program storage device storing instructions that when executed by a computer perform, in an information processing system having a plurality of components and experiencing first-type and second-type events, a method of storing the events comprising:

receiving a signal indicative of at least one of the first-type and the second-type events;

storing information relating to the first-type event associated with one of the plurality of components in a first block of a memory; and

storing information relating to the second-type event associated with one of the plurality of components in a second block of the memory in a wrap around sequence, wherein the signal comprises at least a message of a failure in one of the plurality of components, and wherein the first and the second blocks of the memory are configured to store the information without restriction of time.

19. The device as defined in claim 18, wherein storing information relating to a first-type event includes storing information relating to at least an identification number.

20. The device as defined in claim 18, wherein storing information relating to the first-type event includes storing information that relates to a change in the presence of one of the plurality of components.

21. The device as defined in claim 18, wherein storing information relating to the second-type event includes storing information that relates to a failure occurring in one of the plurality of components.

22. The device as defined in claim 18, further comprising allocating the size of the first block to be equal to the size of the second block.

23. A method of recording information relating to an event experienced by a component in an information system having a processor and a memory unit, said method comprising:

receiving a command including data from the processor, wherein the command comprises a plurality of bits representing at least a slave address, a least significant bit, a most significant bit, a data type, a command ID, and a status field;

determining the data type of the command; and

performing at least one of a read and write operation in the memory unit in response to the act of determining the data type of the command.

24. The method as defined in claim 23, wherein the act of receiving a command includes the act of receiving an interrupt command.

25. The method as defined in claim 23, wherein the act of receiving the command includes the act of determining if the command has been received.

26. The method as defined in claim 25, further comprising the act of determining if a reset command has been received.

27. The method as defined in claim 26, further comprising the act of clearing the memory unit if the reset command is received.

28. The method as defined in claim 26, further comprising the act of saving, a real time if the reset command is not received.

29. The method as defined in claim 25, further comprising the act or determining if the command is intended for a first block of the memory unit.

30. The method as defined in claim 29, further comprising the act of determining if the command is a read command.

31. The method as defined in claim 30, further comprising the act of performing a read operation from the memory unit, if the command is a read command.

32. The method as defined in claim 30, further comprising the act of performing a write operation to the memory unit, if the command is not a read command.

33. The method as defined in claim 29, further comprising the act of determining if the command is a read command, if the command is not intended for the first block of the memory unit.

34. The method as defined in claim 33, further comprising the act of performing a read operation from the memory unit, if the command is a read command.

35. The method as defined in claim 33, further comprising the act of performing a write operation to the memory unit, if the command is not a read command.

36. The method as defined in claim 23, further comprising the act of returning to an idle state after performing a read operation.

37. The method as defined in claim 25, further comprising the act of returning to an idle state after performing a write operation.

38. A method of recording an event occurring in an information processing system having a computer bus, said method comprising:

monitoring the occurrence of the event;

generating a message in response to the event;

accessing a system recorder via the computer bus;

transmitting the message to the system recorder, wherein said message comprises a plurality of bits representing at least a slave address, a least significant bit, a most significant bit, a data type, a command ID, and a status field;

time-stamping the message using a substantially real-time clock; and

storing the message in a memory unit.

39. The method as defined in claim 38, wherein the act of monitoring the occurrence of the event includes the act of monitoring the occurrence of a failure in the information processing system.

40. In an information processing system having a plurality of components and experiencing an event, a method of storing the event comprising:

storing information relating to the presence of one of the plurality of components into a first memory block; and

storing information relating to the failure of one of the plurality of components into a second memory block in a wrap around sequence, wherein the first and second memory blocks are configured to store the information without restriction of time.

Patent Citations (246)

Patent	Date	Inventor	Cited By
US4057847	1977-11-01	Lowell et al.	Applicant
US4449182	1984-05-01	Rubinson et al.	Applicant
US4672535	1987-06-01	Katzman et al.	Applicant
US4695946	1987-09-01	Andreasen et al.	Applicant
US4707803	1987-11-01	Anthony, Jr. et al.	Applicant
US4769764	1988-09-01	Levanon	Applicant
US4774502	1988-09-01	Kimura	Applicant
US4821180	1989-04-01	Gerety et al.	Applicant
US4835737	1989-05-01	Herrig et al.	Applicant
US4949245	1990-08-01	Martin et al.	Applicant
US4999787	1991-03-01	McNally et al.	Applicant
US5006961	1991-04-01	Monico	Applicant
US5007431	1991-04-01	Donehoo, III	Examiner
US5051720	1991-09-01	Kittirutsunetorn	Applicant
US5073932	1991-12-01	Yossifor et al.	Applicant
US5103391	1992-04-01	Barrett	Applicant
US5118970	1992-06-01	Olson et al.	Applicant
US5123017	1992-06-01	Simpkins et al.	Applicant
US5136715	1992-08-01	Hirose et al.	Applicant
US5157663	1992-10-01	Major et al.	Applicant
US5210855	1993-05-01	Bartol	Applicant
US5222897	1993-06-01	Collins et al.	Applicant
US5247683	1993-09-01	Holmes et al.	Applicant
US5253348	1993-10-01	Scalise	Applicant
US5261094	1993-11-01	Everson et al.	Applicant
US5265098	1993-11-01	Mattson et al.	Applicant
US5266838	1993-11-01	Gerner	Applicant
US5269011	1993-12-01	Yanai et al.	Applicant
US5272382	1993-12-01	Heald et al.	Applicant
US5272584	1993-12-01	Austruy et al.	Applicant
US5276814	1994-01-01	Bourke et al.	Applicant
US5283905	1994-02-01	Saadeh et al.	Applicant
US5307354	1994-04-01	Cramer et al.	Applicant
US5311451	1994-05-01	Barrett	Applicant
US5317693	1994-05-01	Cuenod et al.	Applicant
US5329625	1994-07-01	Kannan et al.	Applicant
US5337413	1994-08-01	Lui et al.	Applicant
US5351276	1994-09-01	Doll, Jr. et al.	Applicant
US5367670	1994-11-01	Ward et al.	Examiner
US5379184	1995-01-01	Barraza et al.	Applicant
US5379409	1995-01-01	Ishikawa	Applicant
US5386567	1995-01-01	Lien et al.	Applicant
US5402431	1995-03-01	Saadeh et al.	Examiner
US5404494	1995-04-01	Garney	Applicant
US5423025	1995-06-01	Goldman et al.	Applicant
US5430717	1995-07-01	Fowler et al.	Applicant
US5430845	1995-07-01	Rimmer et al.	Applicant
US5432946	1995-07-01	Allard et al.	Applicant
US5440748	1995-08-01	Sekine et al.	Applicant
US5455933	1995-10-01	Schieve et al.	Applicant
US5465349	1995-11-01	Geronimi et al.	Applicant
US5471617	1995-11-01	Farrand et al.	Applicant
US5471634	1995-11-01	Giorgio et al.	Applicant
US5473499	1995-12-01	Weir	Applicant
US5483419	1996-01-01	Kaczeus, Sr. et al.	Applicant
US5485607	1996-01-01	Lomet et al.	Applicant
US5487148	1996-01-01	Komori et al.	Applicant
US5491791	1996-02-01	Glowny et al.	Applicant
US5493574	1996-02-01	McKinley	Applicant
US5493666	1996-02-01	Fitch	Applicant
US5513314	1996-04-01	Kandasamy et al.	Applicant
US5513339	1996-04-01	Agrawal et al.	Examiner
US5515515	1996-05-01	Kennedy et al.	Applicant
US5517646	1996-05-01	Piccirillo et al.	Applicant
US5519851	1996-05-01	Bender et al.	Applicant
US5526289	1996-06-01	Dinh et al.	Applicant
US5528409	1996-06-01	Cucci et al.	Applicant
US5530810	1996-06-01	Bowman	Applicant
US5533198	1996-07-01	Thorson	Applicant
US5539883	1996-07-01	Allon et al.	Applicant
US5542055	1996-07-01	Amini et al.	Applicant
US5546272	1996-08-01	Moss et al.	Applicant
US5555510	1996-09-01	Verseput et al.	Applicant
US5559764	1996-09-01	Chen et al.	Applicant
US5559958	1996-09-01	Farrand et al.	Applicant
US5559965	1996-09-01	Oztaskin et al.	Applicant
US5564024	1996-10-01	Pemberton	Applicant
US5566299	1996-10-01	Billings et al.	Applicant
US5568610	1996-10-01	Brown	Applicant
US5568619	1996-10-01	Blackledge et al.	Applicant
US5572403	1996-11-01	Mills	Applicant
US5577205	1996-11-01	Hwang et al.	Applicant
US5579491	1996-11-01	Jeffries et al.	Applicant
US5579528	1996-11-01	Register	Applicant
US5581712	1996-12-01	Herrman	Applicant
US5581714	1996-12-01	Amini et al.	Applicant
US5586250	1996-12-01	Carbonneau et al.	Applicant
US5588121	1996-12-01	Reddin et al.	Applicant
US5588144	1996-12-01	Inoue et al.	Applicant
US5592610	1997-01-01	Chittor	Applicant
US5598407	1997-01-01	Bud et al.	Applicant
US5602758	1997-02-01	Lincoln et al.	Applicant
US5604873	1997-02-01	Fite et al.	Applicant
US5606672	1997-02-01	Wade	Applicant
US5608865	1997-03-01	Midgely et al.	Applicant
US5608876	1997-03-01	Cohen et al.	Applicant
US5615207	1997-03-01	Gephardt et al.	Applicant
US5621159	1997-04-01	Brown et al.	Applicant
US5621892	1997-04-01	Cook	Applicant
US5622221	1997-04-01	Genga, Jr. et al.	Applicant
US5628028	1997-05-01	Michelson	Applicant
US5632021	1997-05-01	Jennings et al.	Applicant
US5636341	1997-06-01	Matsushita et al.	Applicant
US5638289	1997-06-01	Yamada et al.	Applicant
US5644470	1997-07-01	Benedict et al.	Applicant
US5644731	1997-07-01	Liencres et al.	Applicant
US5651006	1997-07-01	Fujino et al.	Applicant
US5652832	1997-07-01	Kane et al.	Applicant
US5652833	1997-07-01	Takizawa et al.	Applicant
US5652892	1997-07-01	Ugajin	Applicant
US5655081	1997-08-01	Bonnell et al.	Applicant
US5655148	1997-08-01	Richman et al.	Applicant
US5659682	1997-08-01	Devarakonda et al.	Applicant
US5664119	1997-09-01	Jeffries et al.	Applicant
US5666538	1997-09-01	DeNicola	Applicant
US5671371	1997-09-01	Kondo et al.	Applicant
US5675723	1997-10-01	Ekrot et al.	Applicant
US5680288	1997-10-01	Carey et al.	Applicant
US5682328	1997-10-01	Roeber et al.	Applicant
US5684671	1997-11-01	Hobbs et al.	Applicant
US5685671	1997-11-01	Hobbs et al.	Applicant
US5689637	1997-11-01	Johnson et al.	Applicant
US5696895	1997-12-01	Hemphill et al.	Applicant
US5696899	1997-12-01	Kalwitz	Applicant
US5696949	1997-12-01	Young	Applicant
US5696970	1997-12-01	Sandage et al.	Applicant
US5701417	1997-12-01	Lewis et al.	Applicant
US5704031	1997-12-01	Mikami et al.	Applicant
US5708775	1998-01-01	Nakamura	Applicant
US5708776	1998-01-01	Kikinis	Applicant
US5712754	1998-01-01	Sides et al.	Applicant
US5721935	1998-02-01	DeSchepper et al.	Applicant
US5724529	1998-03-01	Smith et al.	Applicant
US5726506	1998-03-01	Wood	Applicant
US5737708	1998-04-01	Grob et al.	Applicant
US5737747	1998-04-01	Vishlitzky et al.	Applicant
US5740378	1998-04-01	Rehl et al.	Applicant
US5742514	1998-04-01	Bonola	Applicant
US5742833	1998-04-01	Dea et al.	Applicant
US5747889	1998-05-01	Raynham et al.	Applicant
US5748426	1998-05-01	Bedingfield et al.	Applicant
US5752164	1998-05-01	Jones	Applicant
US5754396	1998-05-01	Felcman et al.	Applicant
US5754449	1998-05-01	Hoshal et al.	Examiner
US5754797	1998-05-01	Takahashi	Applicant
US5758352	1998-05-01	Reynolds et al.	Applicant
US5761033	1998-06-01	Wilhelm	Applicant
US5761045	1998-06-01	Olson et al.	Applicant
US5761462	1998-06-01	Neal et al.	Applicant
US5761707	1998-06-01	Aiken et al.	Applicant
US5764924	1998-06-01	Hong	Applicant
US5764968	1998-06-01	Ninomiya	Applicant
US5765008	1998-06-01	Desai et al.	Applicant
US5765198	1998-06-01	McCrocklin et al.	Applicant
US5767844	1998-06-01	Stoye	Applicant
US5768541	1998-06-01	Pan-Ratzlaff	Applicant
US5768542	1998-06-01	Enstrom et al.	Applicant
US5771343	1998-06-01	Hafner	Applicant
US5774640	1998-06-01	Kurio	Applicant
US5774645	1998-06-01	Beaujard et al.	Examiner
US5774741	1998-06-01	Choi	Applicant
US5778197	1998-07-01	Dunham	Applicant
US5781703	1998-07-01	Desai et al.	Applicant
US5781716	1998-07-01	Hemphill et al.	Applicant
US5781767	1998-07-01	Inoue et al.	Applicant
US5781798	1998-07-01	Beatty et al.	Applicant
US5784576	1998-07-01	Guthrie et al.	Applicant
US5787459	1998-07-01	Stallmo et al.	Applicant
US5790775	1998-08-01	Marks et al.	Applicant
US5790831	1998-08-01	Lin et al.	Applicant
US5793948	1998-08-01	Asahi et al.	Examiner
US5793987	1998-08-01	Quackenbush et al.	Applicant
US5794035	1998-08-01	Golub et al.	Applicant
US5796185	1998-08-01	Takata et al.	Applicant
US5796580	1998-08-01	Komatsu et al.	Applicant
US5796934	1998-08-01	Bhanot et al.	Applicant
US5796981	1998-08-01	Abudayyeh et al.	Applicant
US5798828	1998-08-01	Thomas et al.	Applicant
US5799036	1998-08-01	Staples	Applicant
US5799196	1998-08-01	Flannery	Applicant
US5801921	1998-09-01	Miller	Applicant
US5802269	1998-09-01	Poisner et al.	Applicant
US5802305	1998-09-01	McKaughan et al.	Applicant
US5802324	1998-09-01	Wunderlich et al.	Applicant
US5802393	1998-09-01	Begun et al.	Applicant
US5802552	1998-09-01	Fandrich et al.	Applicant
US5803357	1998-09-01	Lakin	Applicant
US5805804	1998-09-01	Laursen et al.	Applicant
US5805834	1998-09-01	McKinley et al.	Applicant
US5809224	1998-09-01	Schultz et al.	Applicant
US5809256	1998-09-01	Najemy	Applicant
US5809555	1998-09-01	Hobson	Applicant
US5812748	1998-09-01	Ohran et al.	Applicant
US5812750	1998-09-01	Dev et al.	Applicant
US5812757	1998-09-01	Okamoto et al.	Applicant
US5812858	1998-09-01	Nookala et al.	Applicant
US5815117	1998-09-01	Kolanek	Applicant
US5815651	1998-09-01	Litt	Applicant
US5815652	1998-09-01	Ote et al.	Applicant
US5821596	1998-10-01	Miu et al.	Applicant
US5822547	1998-10-01	Boesch et al.	Applicant
US5826043	1998-10-01	Smith et al.	Applicant
US5829046	1998-10-01	Tzelnic et al.	Applicant
US5835719	1998-11-01	Gibson et al.	Applicant
US5835738	1998-11-01	Blackledge, Jr. et al.	Applicant
US5838932	1998-11-01	Alzien	Applicant
US5841964	1998-11-01	Yamaguchi	Applicant
US5841991	1998-11-01	Russell	Applicant
US5850546	1998-12-01	Kim	Applicant
US5852720	1998-12-01	Gready et al.	Applicant
US5852724	1998-12-01	Glenn, II et al.	Applicant
US5857074	1999-01-01	Johnson	Applicant
US5864653	1999-01-01	Tavallaei et al.	Applicant
US5864654	1999-01-01	Marchant	Applicant
US5864713	1999-01-01	Terry	Examiner
US5867730	1999-02-01	Leyda	Applicant
US5875308	1999-02-01	Egan et al.	Applicant
US5875310	1999-02-01	Buckland et al.	Applicant
US5878237	1999-03-01	Olarig	Applicant
US5878238	1999-03-01	Gan et al.	Applicant
US5881311	1999-03-01	Woods	Applicant
US5884049	1999-03-01	Atkinson	Applicant
US5886424	1999-03-01	Kim	Applicant
US5892898	1999-04-01	Fujii et al.	Examiner
US5892915	1999-04-01	Duso et al.	Applicant
US5893140	1999-04-01	Vahalia et al.	Applicant
US5907672	1999-05-01	Matze et al.	Applicant
US5909568	1999-06-01	Nason	Applicant
US5911779	1999-06-01	Stallmo et al.	Applicant
US5913034	1999-06-01	Malcolm	Applicant
US5922060	1999-07-01	Goodrum	Applicant
US5930358	1999-07-01	Rao	Applicant
US5935262	1999-08-01	Barrett et al.	Applicant
US5936960	1999-08-01	Stewart	Applicant
US5938751	1999-08-01	Tavallaei et al.	Applicant
US5941996	1999-08-01	Smith et al.	Applicant
US5964855	1999-10-01	Bass et al.	Applicant
US5983349	1999-11-01	Kodama et al.	Applicant
US5987621	1999-11-01	Duso et al.	Applicant
US5987627	1999-11-01	Rawlings, III	Applicant
US6038624	2000-03-01	Chan et al.	Applicant
EP866403A1	1998-09-01		Applicant
JP4-333118	1992-11-01		Applicant
JP5-233110	1993-01-01		Applicant
JP7-093064	1995-04-01		Applicant
JP7-261874	1995-10-01		Applicant

Non-Patent Literature (25)

“The Flight Rcorder: An Architectural Aid For System Monitoring”, Michael M. Gorlick, Conference Proceedings on ACM/ONR workshop on parallel and distributed debugging, p 175-181, 1991.Applicant
Lyons, Computer Reseller News, Issue 721, pp. 61-62, Feb. 3, 1997, “ACC Releases Low-Cost Solution for ISPs.”Applicant
M2 Communications, M2 Presswire, 2 pages, Dec. 19, 1996, “Novell IntranetWare Supports Hot Pluggable PCI from NetFRAME.”Applicant
Rigney, PC Magazine, 14(17):375-379, Oct. 10, 1995, “The One for the Road (Mobile-aware capabilities in Windows 95).”Applicant
Shanley, and Anderson, PCI System Architecture, Third Edition, p. 382, Copyright 1995.Applicant
Gorlick, M., Conf. Proceedings: ACM/ONR Workshop on Parallel and Distributed Debugging, pp. 175-181, 1991, “The Flight Recorder: An Architectural Aid for System Monitoring.”Applicant
IBM Technical Disclosure Bulletin, 92A+62947, pp. 391-394, Oct. 1992, Method for Card Hot Plug Detection and Control.Applicant
Haban, D. & D. Wybranietz, IEEE Transaction on Software Engineering, 16(2):197-211, Feb. 1990, “A Hybrid Monitor for Behavior and Performance Analysis of Distributed Systems.”Applicant
Shanley and Anderson, PCI System Architecture, Third Edition, Chapters 15 & 16, pp. 297-328, CR 1995.Applicant
PCI Hot-Plug Specification, Preliminary Revision for Review Only, Revision 0.9, pp. i-vi, and 1-25, Mar. 5, 1997.Applicant
SES SCSI-3 Enclosure Services, X3T10/Project 1212-D/Rev 8a, pp. i, iii-x, 1-76, and I-1 (index), Jan. 16, 1997.Applicant
Compaq Computer Corporation, Technology Brief, pp. 1-13, Dec. 1996, “Where Do I Plug the Cable? Solving the Logical-Physical Slot Numbering Problem.”Applicant
Standard Overview, http://www.pc-card.com/stand_overview.html#1, 9 pages, Jun. 1990, “Detailed Overview of the PC Card Standard.”Applicant
Digital Equipment Corporation, datasheet, 140 pages, 1993, “DECchip 21050 PCI-TO-PCI Bridge.”Applicant
NetFRAME Systems Incorporated, News Release, 3 pages, referring to May 9, 1994, “NetFRAME's New High-Availability ClusterServer Systems Avoid Scheduled as well as Unscheduled Downtime.”Applicant
Compaq Computer Corporation, Phenix Technologies, LTD, and Intel Corporation, specification, 55 pages, May 5, 1995, “Plug & Play BIOS Specification.”Applicant
NetFRAME Systems Incorporated, datasheet, 2 pages, Feb. 1996, “NF450FT Network Mainframe.”Applicant
NetFRAME Systems Incorporated, datasheet, 9 pages, Mar. 1996, “NetFRAME Cluster Server 8000.”Applicant
Joint work by Intel Corporation, Compaq, Adaptec, Hewlett Packard, and Novell, presentation, 22 pages, Jun. 1996, “Intelligent I/O Architecture.”Applicant
Lockareff, M. HTINews, http://www.hometoys.com/htinews/dec96/articles/lonworks.htm, 2 pages, Dec. 1996, “Loneworks—An Introduction.”Applicant
Schofield, M.J., http://www.omegas.co.uk/CAN/canworks.htm, 4 pages, Copyright 1996, 1997, “Controller Area Network—How CAN Works.”Applicant
NTRR, Ltd., http://www.nrtt.demon.co.uk/cantech.html, 5 pages, May 28, 1997, “CAN: Technical Overview.”Applicant
Herr, et al., Linear Technology Magazine, Design Features, pp . 21-23, Jun. 1997, “Hot Swapping the PCI Bus.”Applicant
PCI Special Interest Group, specification, 35 pages, Draft For Review Only, Jun. 15, 1997, “PCI Bus Hot Plug Specification.”Applicant
Microsoft Corporation, file:///A|/Rem_devs.htm. 4 pages, Copyright 1997, undated Aug. 13, 1997, “Supporting Removable Devices Under Windows and Windows NT.”Applicant

Abstract