Qlogic Fast Fabric, User Manual

Page: 122 / 174

5 – Detailed Descriptions of Command LineTools
Advanced Initialization and Verification - ibtest
5-68 D000006-000 Rev A
Q
5.5.4
Interpreting the ibtest log files
Each run of
ibtest
will create
test.log
and
test.res
files in the current
directory.
When
ibtest
indicates that some or all of the test cases failed, the
test.res
and
test.log
files should be reviewed.
test.res
will summarize which tests
have failed. Using the
test.res
file for servers that failed can be quickly
identified. If the problem is not immediately obvious, check the
test.log
file.
The most recent results will be at the end of the file. The
save_tmp/*/test.log
files will be easier to read since they will represent the
logs for a single test case, typically against a single chassis, switch or host.
The keyword
FAILURE
will be used to mark any failures. Typically due to the roll
up of error messages, the first instance of
FAILURE
in a given sequence of
failures will show what was being done. Preceeding the
FAILURE
, the log will
also show the exact sequence of commands issued to the target host and/or
chassis and the resulting output from that host and/or chassis.
For example,
test.log
may contain lines such as:
scp ./InfiniServPerf.4.1.1.0.15.tgz root@n001a:
TEST CASE FAILURE=scp ./InfiniServPerf.4.1.1.0.15.tgz
root@n001a: failed: ssh: n001a Name or service not known
lost connection
This indicates the scp command shown was executed but failed with the error
message
"ssh: n001a Name or service not known
.
lost connection"
In this example, this was the exact output from SSH.
If there is a
FAILURE
message indicating timeout, it means the expected output
did not occur within a reasonable time limit. The time limits used are quite
generous, so such failures often indicate a host, chassis or switch is offline. It
could also indicate unexpected prompts (such as a password prompt when
password-less ssh is expected). Review the test.log first for such prompts. Also
verify that the host can SSH to the the target host or chassis with the expected
password behavior.
Another common source of timeouts is incorrect host shell command prompts.
Verify that both this host and the target host have their prompts set correctly.
The command line prompt must end in
#
or
$
(make certain there is a space
after either).
Yet another common source of timeouts is typograhical errors in selected host
or chassis names. Verify that the host, chassis or switch names in
test.log