Transition to switch node adapter diagnostics using adapter device driver

• US 6,892,321 B2
• Filed: 07/17/2001
• Issued: 05/10/2005
• Est. Priority Date: 07/17/2001
• Status: Expired due to Fees

• Current Assignee: International Business Machines Corporation
• Original Assignee: International Business Machines Corporation
• Inventors: Chen, Wen Chong
• Primary Examiner(s): Baderman, Scott
• Assistant Examiner(s): Damiano, Anne L.
• Application Number:
  US09/907,118
• Publication Number:
  US 20030018926A1
• Time in Patent Office: 1,393 Days
• Field of Search: 714/4, 714/25, 714/31, 714/49
• US Class Current: 714/25
• CPC Class Codes: H04L 12/00 Data switching networks interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units G06F13/00

Abstract

Smooth release of resources on a switch node adapter to a diagnostics program is provided without requiring rebooting of the system. The release technique includes: setting a first flag at a device driver associated with the adapter to block new open system calls from opening the device driver; broadcasting an adapter down event to instruct internet protocol (IP), fault service daemon (FSD) and application program interface (API) components of the node to release resources on the adapter; and setting a second flag at the device driver to block input/output control calls other than from the diagnostics program. When the device driver supports multiple adapters, only the adapter undergoing diagnostics is suspended, the remaining adapters remain up to components of the switch node. Upon completion of diagnostics, components remaining in open state are restarted on their communication windows at the adapter.

Claims

1. In a switch node, a method of releasing control of an adapter to a diagnostics program, the method comprising:

setting a first flag by a device driver associated with the adapter to block any new open system call;

broadcasting an adapter down event to instruct components of the switch node to release resources on the adapter; and

setting a second flag by the device driver to block input/output control calls other than from the diagnostics program.

2. The method of claim 1, wherein the components of the switch node release resources on the adapter without closing those resources.

3. The method of claim 2, wherein the components of the switch node include one or more of an internet protocol (IP) component, a fault service daemon (FSD) component, and an application program interface (API) component.

4. The method of claim 3, wherein the resources to be released on the adapter comprise client windows on the adapter.

5. The method of claim 1, further comprising initiating the diagnostics program and opening the device driver to the diagnostics program.

6. The method of claim 1, wherein said broadcasting comprises broadcasting from the device driver the adapter down event to instruct components to release resources on the adapter.

7. The method of claim 1, wherein the first flag comprises a diag_open flag, and the second flag comprises an ioctl_from_diag_only flag.

8. The method of claim 1, wherein the adapter comprises a first adapter and the device driver further includes a second adapter, and wherein the method comprises releasing the first adapter to the diagnostics program, while the second adapter remains up and running to components of the switch node.

9. The method of claim 1, further in combination with a method of diagnostic testing of the adapter, said combination including the diagnostic program resetting the adapter, loading diagnostic microcode onto the adapter, and using ioctl calls to test the adapter.

10. The combination method of claim 9, further comprising reinitiating the adapter when diagnostics is complete, said reinitiating comprising:

closing the diagnostics program on the device driver;

unsetting the second flag and broadcasting an adapter initiate event;

bringing up default device driver microcode;

opening client windows on the adapter for any components remaining in open status, and restarting input/output on their communication windows; and

unsetting the first flag to allow new processes to open the device driver.

11. A system of initiating diagnostics of a switch node adapter, said system comprising:

means for setting a first flag by a device driver associated with the adapter to block any new open system call;

means for broadcasting an adapter down event to instruct components of the switch node to release resources on the adapter; and

means for setting a second flag by the device driver to block input/output control (ioctl) calls other than from a diagnostics program.

12. The system of claim 11, wherein the components of the switch node release resources on the adapter, without closing those resources, responsive to said means for broadcasting.

13. The system of claim 12, wherein the components of the switch node include one or more of an internet protocol (IP) component, a fault service daemon (FSD) component, and an application program interface (API) component.

14. The system of claim 13, wherein the resources to be released on the adapter comprise client windows on the adapter.

15. The system of claim 11, further comprising means for initiating the diagnostics program and for opening the device driver to the diagnostics program.

16. The system of claim 11, wherein said means for broadcasting comprises means for broadcasting from the device driver the adapter down event to instruct the components to release resources on the adapter.

17. The system of claim 11, wherein the first flag comprises a diag_open flag, and the second flag comprises an ioctl_from_diag_only flag.

18. The system of claim 11, wherein the adapter comprises a first adapter and the device driver further includes a second adapter, and wherein the system further comprises means for releasing the first adapter to the diagnostics program, while the second adapter remains up and running to components of the switch node.

19. The system of claim 11, further in combination with a system for diagnostic testing the adapter, said combination system including means for the diagnostic program to reset the adapter, to load diagnostic microcode onto the adapter, and to use ioctl calls to test the adapter.

20. The combination system of claim 19, further comprising means for reinitiating the adapter when diagnostics is complete, said means for reinitiating comprising:

means for closing the diagnostics program on the device driver;

means for unsetting the second flag and broadcasting an adapter initiate event;

means for bringing up default device driver microcode;

means for opening client windows on the adapter for any components remaining in open status, and for restarting input/output on their communication windows; and

means for unsetting the first flag to allow new processes to open the device driver.

21. A system for facilitating diagnostics testing of a switch node adapter, said system comprising:

a device driver having an adapter to undergo diagnostics testing, wherein upon initiation of diagnostics said device driver is adapted to;

set a first flag associated with the adapter to block any new open system call;

broadcast an adapter down event to instruct components of the switch node to release resources on the adapter; and

set a second flag on the device driver to block input/output control calls other than from a diagnostics routine, thereby releasing control of the adapter to the diagnostics routine for testing.

22. At least one program storage device readable by a machine, tangibly embodying at least one program of instructions executable by the machine to perform a method of releasing control of a switch node adapter to a diagnostics program, comprising:

setting a first flag by a device driver associated with the adapter to block any new open system call;

broadcasting an adapter down event to instruct components of the switch node to release resources on the adapter; and

setting a second flag by the device driver to block input/output control calls other than from the diagnostics program.

23. The at least one program storage device of claim 22, wherein the components of the switch node release resources on the adapter without closing those resources.

24. The at least one program storage device of claim 23, wherein the components of the switch node include one or more of an internet protocol (IP) component, a fault service daemon (FSD) component, and an application program interface (API) component.

25. The at least one program storage device of claim 24, wherein the resources to be released on the adapter comprise client windows on the adapter.

26. The at least one program storage device of claim 22, further comprising initiating the diagnostics program and opening the device driver to the diagnostics program.

27. The at least one program storage device of claim 22, wherein said broadcasting comprises broadcasting from the device driver the adapter down event to instruct components to release resources on the adapter.

28. The at least one program storage device of claim 22, wherein the first flag comprises a diag_open flag and the second flag comprises an ioctl_from_diag_only flag.

29. The at least one program storage device of claim 22, wherein the adapter comprises a first adapter and the device driver further includes a second adapter, and wherein the method comprises releasing the first adapter to the diagnostics program, while the second adapter remains up and running to components of the switch node.

30. The at least one program storage device of claim 22, wherein said method is further in combination with a method of diagnostic testing of the adapter, said combination method including employing the diagnostic program to reset the adapter, to load diagnostic microcode onto the adapter, and use ioctl calls to test the adapter.

31. The at least one program storage device of claim 30, further comprising reinitiating the adapter when diagnostics is complete, said reinitiating comprising:

closing the diagnostics program on the device driver;

unsetting the second flag and broadcasting an adapter initiate event;

bringing up default device driver microcode;

opening client windows on the adapter for any components remaining in open status, and restarting input/output on their communication windows; and

unsetting the first flag to allow new processes to open the device driver.