Method and system for recovering a failed device on a master-slave bus

• US 6,735,720 B1
• Filed: 05/31/2000
• Issued: 05/11/2004
• Est. Priority Date: 05/31/2000
• Status: Active Grant

• Current Assignee: Microsoft Technology Licensing LLC (Microsoft Corporation)
• Original Assignee: Microsoft Corporation
• Inventors: Dunn, John C., Ray, Kenneth D.
• Primary Examiner(s): Baderman, Scott
• Assistant Examiner(s): LOHN, JOSHUA A
• Application Number:
  US09/584,554
• Time in Patent Office: 1,441 Days
• Field of Search: 714/43, 714/44, 710/302, 710/304
• US Class Current: 714/43
• CPC Class Codes: G06F 11/0745 in an input/output transactions management context input/output processing in general G06F13/00
• CPC Class Codes: G06F 11/0757 by exceeding a time limit, i.e. time-out, e.g. watchdogs
• CPC Class Codes: G06F 11/0793 Remedial or corrective actions recovery from an exception in an instruction pipeline G06F9/3861; by retry G06F11/1402; for recovering from a failure of a protocol instance or entity H04L69/40

Abstract

The invention described in the instant application provides for a failure-recovery module, which permits automatic investigation of possible reasons for the failure and takes corrective action in a manner transparent to the user. The failure-recovery module, which is a software module, 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 the device, e.g., by turning off the power to the affected device and rebooting the device with a cold start. The failure-recovery module diagnoses the failure of a device by determining if the device is still connected to the master-slave bus. Then, the failure-recovery module sets a flag to mark the device as having failed while disabling access to devices downstream of the failed device. 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. Subsequently, downstream devices are reinitialized and resources, if available, allocated to them along with enumeration of the devices.

Claims

1. A failure-recovery software module for correcting failure of a device connected to a master-slave bus organized in a tree structure comprising a plurality of devices, the tree structure including branches formed by a first device upstream port connected to a second device downstream port, the tree structure having furthermore a root corresponding to a master control for managing the master-slave bus, and the failure-recovery software module comprising computer-executable instructions for:

detecting a non-responsive device connected to the master-slave bus, wherein the non-responsive device does not respond to a status query by a master-slave bus system software in conformity with a specified time interval;

determining that the non-responsive device is powered and connected to the master-slave bus;

requesting resetting a downstream port on a device upstream of the non-responsive device to place the non-responsive device in a first defined state;

configuring the non-responsive device to be in a second defined state from the first defined state; and

unloading device drivers corresponding to devices downstream of the non-responsive device.

2. The failure-recovery software module of claim 1 wherein the master-slave bus is a universal serial bus.

3. The failure-recovery software module of claim 1 wherein the device is a hub.

4. The failure-recovery software module of claim 1 wherein the status query is via a status change pipe defined by end points supporting interrupt transfers, on the non-responsive device.

5. The failure-recovery software module of claim 1 wherein the first defined state is to power off the non-responsive device.

6. A method for correcting failure of a device connected to a master-slave bus organized in a tree structure comprising a plurality of devices, the tree structure including branches formed by a first device upstream port connected to a second device downstream port, the tree structure having furthermore a root corresponding to a master control for managing the master-slave bus, and the method comprising:

detecting a non-responsive device connected to the master-slave bus, wherein the non-responsive device does not respond to a status query by a master-slave bus system software in conformity with a specified time interval;

determining that the non-responsive device is powered and connected to the master-slave bus;

resetting a downstream port on a device upstream of the non-responsive device to place the non-responsive device in a first defined state;

configuring the non-responsive device to be in a second defined state from the first defined state; and

unloading device drivers corresponding to devices downstream of the non-responsive device.

7. The method of claim 6 wherein the master-slave bus is a universal serial bus.

8. The method of claim 6 wherein the device is a hub.

9. The method of claim 6 wherein the status query is via a status change pipe, defined by end points supporting interrupt transfers, on the non-responsive device.

10. The method of claim 6 wherein the first defined state is to power off the non-responsive device.

11. The method of claim 6 wherein configuring the non-responsive device in the second defined state includes renegotiating resources for the non-responsive device with system software for the master-slave bus.

12. The method of claim 6 further comprising:

enumerating the devices downstream of the non-responsive device; and

configuring the devices downstream of the non-responsive device.

13. A universal serial bus packaged with a computer, the universal serial bus comprising:

a host having a root hub with at least one downstream port for connecting a device;

universal serial bus system software;

at least one driver for the host; and

a failure-recovery module for resetting a hub connected to the universal serial bus, the failure recovery module having a failure-recovery software module comprising computer-executable instructions for;

detecting a non-responsive device connected to the universal serial bus, wherein the non-responsive hub does not respond to a status query by the universal serial bus system software in conformity with a specified time interval;

determining that the hub is powered and connected to the universal serial bus;

resetting a downstream port on a hub upstream of the hub to place the hub in a first defined state;

configuring the hub to be in a second defined state from the first defined state and

releasing resources allocated to devices downstream of the non-responsive hub.

14. The universal serial bus packaged with a computer of claim 13 wherein furthermore the failure-recovery software module having the status query via a status change pipe, defined by end points supporting interrupt transfers, on the non-responsive device.

15. The universal serial bus packaged with a computer claim 13 wherein furthermore the failure-recovery software module using the first defined state is to power off the non-responsive device.

16. A failure-recovery software module for correcting failure of a device connected to a master-slave bus organized in a tree structure comprising a plurality of devices, the tree structure including branches formed by a first device upstream port connected to a second device downstream port, the tree structure having furthermore a root corresponding to a master control for managing the master-slave bus, and the failure-recovery software module comprising computer-executable instructions for:

detecting a non-responsive device connected to the master-slave bus, wherein the non-responsive device does not respond to a status query by a master-slave bus system software in conformity with a specified time interval;

determining that the non-responsive device is powered and connected to the master-slave bus;

requesting resetting a downstream port on a device upstream of the non-responsive device to place the non-responsive device in a first defined state;

configuring the non-responsive device to be in a second defined state from the first defined state; and

releasing resources allocated to devices downstream of the non-responsive device.

17. The failure-recovery software module of claim 16 wherein the master-slave bus is a universal serial bus.

18. The failure-recovery software module of claim 16 wherein the non-responsive device is a hub.

19. The failure-recovery software module of claim 16 wherein the status query is via a status change pipe defined by end points supporting interrupt transfers on the non-responsive device.

20. The failure-recovery software module of claim 16 wherein the first defined state is to power off the non-responsive device.

21. A failure-recovery software module for correcting failure of a hub connected to a universal serial bus organized in a tree structure comprising a plurality of devices, the tree structure including branches formed by a first device upstream port connected to a second device downstream port, the tree structure having furthermore a root corresponding to a master control for managing the universal serial bus, and the failure-recovery software module comprising computer-executable instructions for:

detecting a non-responsive hub connected to the universal serial bus, wherein the non-responsive hub does not respond to a status query by a universal serial bus system software in conformity with a specified time interval;

determining that the non-responsive hub is powered and connected to the universal serial bus;

requesting resetting a downstream port on a device upstream of the non-responsive hub to place the non-responsive hub in a first defined state of being powered off; and

configuring the non-responsive hub to be in a second defined state from the first defined state;

wherein the status query is via a status change pipe defined by end points supporting interrupt transfers on the hub.

22. A method for correcting failure of a device connected to a master-slave bus organized in a tree structure comprising a plurality of devices, the tree structure including branches formed by a first device upstream port connected to a second device downstream port, the tree structure having furthermore a root corresponding to a master control for managing the master-slave bus, and the method comprising:

detecting a non-responsive device connected to the master-slave bus, wherein the non-responsive device does not respond to a status query by a master-slave bus system software in conformity with a specified time interval;

determining that the non-responsive device is powered and connected to the master-slave bus;

resetting a downstream port on a device upstream of the non-responsive device to place the non-responsive device in a first defined state;

configuring the non-responsive device to be in a second defined state from the first defined state; and

releasing resources allocated to devices downstream of the non-responsive device.

23. The method of claim 22 wherein the master-slave bus is a universal serial bus.

24. The method of claim 22 wherein the non-responsive device is a hub.

25. The method of claim 22 wherein the status query is via a status change pipe defined by end points supporting interrupt transfers on the non-responsive device.

26. The method of claim 22 wherein the first defined state is to power off the non-responsive device.

27. The method of claim 22 wherein configuring the non-responsive device in the second defined state includes renegotiating resources for the non-responsive device with system software for the master-slave bus.

28. The method of claim 22 further comprising:

enumerating the devices downstream of the non-responsive device; and

configuring the devices downstream of the non-responsive device.

29. A method for correcting failure of a hub connected to a universal serial bus organized in a tree structure comprising a plurality of devices, the tree structure including branches formed by a first device upstream port connected to a second device downstream port, the tree structure having furthermore a root corresponding to a master control for managing the universal serial bus, and the method comprising:

detecting a non-responsive hub connected to the universal serial bus, wherein the non-responsive hub does not respond to a status query by a universal serial bus system software in conformity with a specified time interval;

determining that the non-responsive hub is powered and connected to the universal serial bus;

resetting a downstream port on a device upstream of the non-responsive hub to place the non-responsive hub in a first defined state of being powered off; and

configuring the non-responsive hub to be in a second defined state from the first defined state;

wherein the status query is via a status change pipe defined by end points supporting interrupt transfers on the hub.

30. A method for correcting failure of a hub connected to a universal serial bus organized in a tree structure comprising a plurality of devices, the tree structure including branches formed by a first device upstream port connected to a second device downstream port, the tree structure having furthermore a root corresponding to a master control for managing the universal serial bus, and the method comprising:

detecting a non-responsive hub connected to the universal serial bus, wherein the non-responsive hub does not respond to a status query by a universal serial bus system software in conformity with a specified time interval;

determining that the non-responsive hub is powered and connected to the universal serial bus;

resetting a downstream port on a device upstream of the non-responsive hub to place the non-responsive hub in a first defined state;

renegotiating resources for the non-responsive hub with system software for the universal serial bus to configure the hub in the second defined state; and

configuring the non-responsive hub to be in a second defined state from the first defined state according to the renegotiation step;

wherein the status query is via a status change pipe defined by end points supporting interrupt transfers on the hub.

31. The method of claim 30 further comprising:

enumerating devices downstream of the hub; and

configuring the devices downstream of the hub.

32. A method for correcting failure of a device connected to a master-slave bus organized in a tree structure comprising a plurality of devices, the tree structure including branches formed by a first device upstream port connected to a second device downstream port, the tree structure having furthermore a root corresponding to a master control for managing the master-slave bus, and the method comprising:

detecting a non-responsive device connected to the master-slave bus, wherein the non-responsive device does not respond to a status query by a master-slave bus system software in conformity with a specified time interval;

determining that the non-responsive device is powered and connected to the master-slave bus;

resetting a downstream port on a device upstream of the non-responsive device to place the non-responsive device in a first defined state;

configuring the non-responsive device to be in a second defined state from the first defined state; and

scheduling, after a first time interval, determining that the non-responsive device is powered and connected to the master-slave bus;

resetting a downstream port on a device upstream of the non-responsive device to place the non-responsive device in a first defined state; and

configuring the non-responsive device to be in a second defined state from the first defined state.

33. A universal serial bus packaged with a computer, the universal serial bus comprising:

a host having a root hub with at least one downstream port for connecting a device;

universal serial bus system software;

at least one driver for the host; and

a failure-recovery module for resetting a hub connected to the universal serial bus, the failure recovery module having a failure-recovery software module comprising computer-executable instructions for;

detecting a non-responsive device connected to the universal serial bus, wherein the non-responsive hub does not respond to a status query by the universal serial bus system software in conformity with a specified time interval;

determining that the hub is powered and connected to the universal serial bus;

resetting a downstream port on a hub upstream of the hub to place the hub in a first defined state;

configuring the hub to be in a second defined state from the first defined state; and

unloading device drivers corresponding to devices downstream of the non-responsive hub.