Error detection/correction and fault detection/recovery – Data processing system error or fault handling – Reliability and availability
Reexamination Certificate
2000-05-31
2004-05-11
Baderman, Scott (Department: 2184)
Error detection/correction and fault detection/recovery
Data processing system error or fault handling
Reliability and availability
Reexamination Certificate
active
06735720
ABSTRACT:
TECHNICAL FIELD
This invention relates generally to making computing environments having a plurality of devices interconnected by one or more buses stable and capable of automatically recovering from failures, and more particularly, relates to devices connected to a computer environment via a Universal Serial Bus (USB).
BACKGROUND
Many new applications in the area of computers, networks and computing environments in general require interconnection of several devices to meet particular needs such as a personal office, a gaming machine with a variety of peripherals or a home network that controls the television, VCR or even the coffee maker. Devices can be interconnected using a variety of buses such as a memory addressed bus, e.g., one compliant with the IEEE 1394 specifications, found at http://standards.ieee.org/catalog/bus.html#1394-1995, or a polled bus, e.g., the Universal Serial Bus (“USB”), described by the specifications at http://www.usb.org, or many other specifications. A bus in general is a structure to which several other devices can be connected. Thus, a device may be considered to be a bus if other devices may be plugged into it.
A goal of designing computing systems is to enable hands-off operation of devices requiring little effort beyond merely plugging a device into a suitable socket. This requires implementation of a bus that is maintenance free. In turn, such designs require that the devices being plugged into the bus be compliant with the bus specifications to allow automatic configuration of the computing environment in response to the addition or removal of a device.
In particular, when a central master control is used, it is advantageous to use a USB to connect peripherals to the central control although other bus designs, including the IEEE 1394 compliant bus, can also be used to implement master-slave device controls. USB is a cable bus that supports data exchange between a host and a plurality of peripheral devices by means of serial data packets. The USB design permits a tree-like topology for connecting up to 127 devices with the host at the root of the tree. Advantageously, the host is implemented in a personal computer, although this is not a requirement.
Devices connected to a USB fall into two major classes—functions and hubs, which are differentiated by the roles they play in the organization and operation of the USB system. Each USB hub has a hub controller, which initiates all data transfers. In addition, each hub has one upstream port and at least one downstream port for connecting additional devices, including hubs. Therefore, a hub is a bus in its own right. In contrast, functions are devices that do not possess ports for connecting additional devices downstream from them, but usually perform tasks. Some examples of tasks performed by functions include collecting data via a video camera, providing audio output via speakers, telephony, faxing and/or modem based access. A USB hub that also performs tasks is considered by the USB to comprise a hub connected to one or more functions.
An IEEE 1394—compliant serial bus provides greater bandwidth (100 Mbps or more) than the USB (12 Mbps), although version 2.0 of the USB specification being developed envisages a forty-fold increase in bandwidth while maintaining backward compatibility. Notably, both USB and IEEE 1394 buses power devices connected to them, although this is not a requirement for a bus in general. USB is preferable to IEEE 1394 bus for many applications due to its simple, robust design that does not require expensive devices to function as nodes. Since many of the management functions of a USB can be performed at a computer implementing the host and associated drivers, it offers a cheaper alternative that uses available computing power efficiently.
However, the USB, as presently implemented, has a number of limitations that reduce its utility. In actual use, bus implementations are susceptible to failures that may not be easy to pinpoint and may even be transient. Of particular interest are failures due to poor power line regulation, which is encountered in some countries in Europe and Asia—both being important markets, or due to electrostatic discharge or difficult-to-diagnose state of the electronics in the devices. Failure of a device in a USB could also be caused by software or a particular state of the device in addition to poor power line regulation or a resource crunch. Such limitations can be particularly vexing for users who are not computer-literate. Consequently, it is desirable to make recovery from errors increasingly transparent to the user because the average user cannot be expected to skillfully diagnose and correct such conditions as a matter of routine.
SUMMARY
The invention described in the instant application overcomes these limitations and more by providing for a failure-recovery module, which permits automatic investigation of possible reasons for the failure and takes corrective action, when desired, to make such troubleshooting transparent to the user. The failure-recovery module is advantageously implemented as a software module. It is useful in evaluating a device connected to a master-slave bus to determine whether it has failed. In the event the device is still connected to the master-slave bus but is non-responsive, the failure-recovery module resets and reinitializes the device. This resetting may require turning off the power to the affected device and rebooting the device with a cold start. Alternatively, a mere reboot without terminating all power to the device may be employed.
The failure-recovery module diagnoses the failure of a device by determining if the non-responsiveness is due to the device being physically disconnected. If the device is still connected to the master-slave bus, then since the device failure was not handled by the built in mechanisms in the bus to handle failures, the failure is determined to be due to unknown causes. The failure-recovery module then, in response to the determination of failure due to unknown causes, sets a flag to mark the device as having failed while disabling access to devices downstream of the failed device. Subsequently the resources allocated to the downstream devices to the failed device are released. This is accompanied or followed by a re-initialization of the failed device with or without a cold start.
If the failure-recovery module is unable to execute successfully, it assumes that the failure causing condition still exists. In some embodiments this results in rescheduling the execution of the failure-recovery module while in other embodiments a general failure may be declared or the failed device left in its disconnected state. On the other hand, if the failure-recovery module executes successfully, the affected device is reinitialized and the flags marking it as failed are cleared with access to the device being restored. Furthermore, devices downstream of the device are also reinitialized and resources, if available, allocated to them.
It should be understood, as would be apparent to one of ordinary skill in the art, that many embodiments of the invention are possible, which do not necessarily require use of the USB, and, thus, are not limited to the USB.
REFERENCES:
patent: 4423480 (1983-12-01), Bauer et al.
patent: 5687167 (1997-11-01), Bertin et al.
patent: 5701305 (1997-12-01), Albrecht
patent: 5848266 (1998-12-01), Scheurich
patent: 6000040 (1999-12-01), Culley et al.
patent: 6049828 (2000-04-01), Dev et al.
patent: 6252886 (2001-06-01), Schwager et al.
patent: 6262974 (2001-07-01), Chevalier et al.
patent: 6279060 (2001-08-01), Luke et al.
Universal Serial Bus Specification; Revision 1.1; Sep. 23, 1998 (http://www.usb.org/developers/docs).*
IEEE Std 1394-1995, “IEEE Standard for a High Performance Serial Bus,” pp. i-viii, 1-384, (1996).
Garney, “An Analysis of Throughput Characteristics of Universal Serial Bus,” USB technical paper, Dec. 6, 1996.
Microsoft Corporation, “Microsoft's USB plans,” published at www.microsoft.com/HWDev/presents winhec98/winhec3-4.htm, accessed Apr.
Dunn John C.
Ray Kenneth D.
Baderman Scott
Leydig , Voit & Mayer, Ltd.
Lohn Joshua
Microsoft Corporation
LandOfFree
Method and system for recovering a failed device on a... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and system for recovering a failed device on a..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and system for recovering a failed device on a... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3254497