Lucent Technologies lucent ユーザーズマニュアル
DEFINITY Enterprise Communications Server Release 6
Maintenance for R6vs/si
Maintenance for R6vs/si
555-230-127
Issue 1
August 1997
Packet Bus Fault Isolation and Correction
Page 9-25
Packet Bus Fault Correction
9
Considerations for High and Critical Reliability
Systems
Systems
If a High or Critical Reliability system is involved, special considerations involving
the features of this type of system must be kept in mind. In particular, if a Packet
Bus problem is caused by a duplicated component, switching to the standby
component may both alleviate the problem and isolate the faulty circuit pack.
Therefore, the commands in the following list should be executed first in a High
or Critical reliability system. For more information on these commands, refer to
the features of this type of system must be kept in mind. In particular, if a Packet
Bus problem is caused by a duplicated component, switching to the standby
component may both alleviate the problem and isolate the faulty circuit pack.
Therefore, the commands in the following list should be executed first in a High
or Critical reliability system. For more information on these commands, refer to
■
reset system interchange
If this command resolves the Packet Bus
problem, the problem is with the Packet Control in the (new) standby SPE.
Refer to PKT-CTRL maintenance in
Refer to PKT-CTRL maintenance in
.
■
set exp-link
If this command resolves the Packet Bus problem, the
problem is with either the (new) standby EI Link or the EIs at either end.
Refer to EXP-INTF maintenance in
Refer to EXP-INTF maintenance in
.
■
set tone-clock
If this command resolves the Packet Bus problem, the
.
NOTE:
Keep in mind that, even though the steps discussed in the previous
list may fail to resolve the problem, the steps are not necessarily
fault-proof. Continue with the procedures in the next section.
list may fail to resolve the problem, the steps are not necessarily
fault-proof. Continue with the procedures in the next section.
Troubleshooting Procedures
As we discussed earlier in this chapter, Packet Bus faults are usually caused by
a defective circuit pack connected to the backplane, by bent pins on the
backplane, or by defective cables/terminators that make up the Packet Bus. The
first two faults cause shorts, while the third fault causes either shorts or opens.
a defective circuit pack connected to the backplane, by bent pins on the
backplane, or by defective cables/terminators that make up the Packet Bus. The
first two faults cause shorts, while the third fault causes either shorts or opens.
There are four procedures for correcting Packet Bus faults. The number of
procedures that are to be used to correct faults depends upon a number of
factors relevant to system performance and to the content of the procedures
themselves. For example, if the Maintenance/Test Packet Bus port is activated,
and if there is an indication of open leads on the Packet Bus (either via the
procedures that are to be used to correct faults depends upon a number of
factors relevant to system performance and to the content of the procedures
themselves. For example, if the Maintenance/Test Packet Bus port is activated,
and if there is an indication of open leads on the Packet Bus (either via the
status
system
command or via Test #572 failure),
go directly to Procedure 4
. The
reason for this is that Procedures 1 through 3 try to locate faulty circuit packs or
bent pins behind circuit packs. Since these types of failures can never cause
open faults, Procedures 1 through 3 need not be implemented in this case.
However, if there are both shorts and opens, execute Procedure 4, then return to
Procedure 1 if there are still shorts after the open lead problems are resolved.
bent pins behind circuit packs. Since these types of failures can never cause
open faults, Procedures 1 through 3 need not be implemented in this case.
However, if there are both shorts and opens, execute Procedure 4, then return to
Procedure 1 if there are still shorts after the open lead problems are resolved.