This document contains the following sections:
Setting up the IBM HBA for loopback testing
Setting up a switch port for loopback testing
Setting up a controller port for loopback testing
Running the controller loopback test
You should arrive at this chapter from a PD map or indication. If this is not the case, click the Back button on your browser to return to the Problem determination starting points.
After you read the relevant information in this chapter, return to the PD map or indication that sent you to this procedure.
Note: Running the loopback test for a short period of time might not catch intermittent problems. It might be necessary to run the test in a continuous loop for at least several minutes to track down intermittent problems.
Port loopback diagnostics are implemented for host bus adapters, switches and controllers. The loopback test requires the use of a wrap connector (and coupler for cable testing). The loopback test sends data from the device transmit element to the receive element of the port through the wrap plug. The test detects and accumulates error incidents.
A wrap plug and coupler kit is available as a CRU. The kit contains the wrap plug and a coupler to enable you to connect the wrap plug to cables. The Part Number of the kit is: 24P0950 (LP form factor).
Setting up the IBM HBA for loopback test
IBM host bus adapters support loopback testing. This test can be invoked during system POST. Wrap plugs are required to run the loopback test.
To run the loopback test from Fast!Util, press the Ctrl+Q key sequence and select the Loopback Data Test menu item. For more information on Fast!UTIL, see Using IBM Fast!UTIL.
The Loopback Data Test can also be run from FAStT MSJ diagnostics. For more information on FAStT MSJ, see Introduction to FAStT MSJ.
Switches also support port loopback testing to diagnose issues with the switch ports. Each switch manufacturer has procedures to set up the ports for loopback test. Refer to your switch documentation for information on the diagnostics that are available for your switch.
Typically, the switch ports are set up for loopback testing in the following manner:
1. Set up the switch port to diagnostic mode. Refer to your switch documentation for more information.
2. Insert the wrap plug that was provided with the switch into the port to be tested.
3. Invoke the loopback test either through the management software (supplied by the switch manufacturer) or through the switch serial port. Some switches provide Telnet support.
4. Run the loopback test and check the results. Refer to your switch documentation for information.
To verify that a fibre channel cable itself is operational, run the loopback test at the end of the cable using the coupler from the wrap plug kit (PN 24P0950). Plug the fibre channel cable into the switch port to be tested and then plug the coupler into the other end of the cable. Insert the wrap plug into the coupler. See Figure 1. Run the switch port loopback test. This procedure verifies that the cable is functional.
Figure 1 Setting up cable for loopback test
Setting up a controller port for loopback testing
This section describes how to set up a controller port for loopback testing.
The DS400 controllers use SFP transceivers. There are times when these devices, and their corresponding cable mediums and concentrators, need to be tested to insure that they are functioning properly. The port loopback command causes the controller to test the fibre channel I/O ports when a loopback plug is attached to the controller port. The data is not compared, but checks are made for CRC, frame and disparity errors. Loopback testing can be performed on user-selected ports with an iteration count, including a continuous iteration count. See Figure 2.
Figure 2 Setting up controller port for loopback test
Loopback test for optical cable testing
Perform the following steps for optical cable loopback testing:
You run the loopback test on a controller port using the command line interface (CLI) through a Telnet session. You can locate the port you want to test by running the port command from the CLI. See Using the CLI for more information.
Warning:
The Diagnostic Loopback test requires that the controller have no
outstanding I/Os. When the loopback test is initiated, I/Os will be
automatically halted. When the test completes, I/Os will resume.
The following command line shows the correct loopback test syntax:
Note: To perfrom diagnostics, you need to be in administrator mode.
loopback drive# [iteration count] [stop-on-error]
The loopback command performs loopback tests on the specified FC port. If the iteration count is set to continuous, the test will halt only if an error is detected and the stop-on-error flag is set, or if you halt the test.
Note: It is recommended that you run the test for several minutes to verify functionality.
The following shows a sample CLI output running loopback test on FC port 0 for 10,000 iterations.
DS400> administrator
DS400# diag
DS400 (diag)# loopback 0
<number of iterations: 1..100000> stop continual
DS400 (diag)# loopback 0 10000
Halt controller I/O and perform loopback test? [No]: y
----[ Loopback test results 'Port 0' ]-----------------------------------------
CRC errors: 0
Disparity errors: 0
Frame length errors: 0
Data mismatch errors: 0
Test OKI
f you were referred to the controller loopback test from the Controller Check, return to that PD map.
If you were referred to the controller loopback test from the Single Path Fail PD, return to that PD map.
Loopback tests require plugging and unplugging components. This could lead to other difficulties if, for instance, a cable is not plugged back completely. Therefore, when the problem is resolved, you should perform a path check to make sure that no other problems have been introduced into the path. Conversely, if you started with a problem and, after unplugging and re-plugging multiple components, you end up at a non-failing point in the PD maps without any repairs or replacement, then the problem was probably a bad connection. You should go back to the original check, such as FAStT MSJ, and rerun the check. If it now runs correctly, you can assume that you have corrected the problem (but it is recommended that you keep checking the event logs for further indications of problems in this area).