DEFINITY Enterprise Communications Server Release 7
Maintenance for R7r
555-230-126
Issue 4
June 1999
Maintenance Object Repair Procedures
9-1504STBY-SPE (Standby SPE Maintenance)
9
no problems are revealed in the memory long test sequence, but memory refresh
persists in failing with error 1281 error aux 1383, escalate the problem.
Error code 1281 with auxiliary data 1381 indicates that refresh of the
packet-interface dual port RAM has failed. If this persists, one should look for
problems with either active SPE or standby SPE packet-interface boards. Follow
the procedures outlined in PKT-INT to fully test the active SPE’s Packet-interface.
Note that, since the standby SPE is not refreshed, one cannot execute the long
demand test sequence on the standby Packet Interface. One can however
trigger a reset of that circuit pack. If the active PKT-INT passes all tests of the
long sequence and if the standby PKT-INT successfully resets, the problem
should clear. If error 1281 aux 1381 persists, escalate the problem.
Error code 1281 with auxiliary data 1380 indicates that memory shadowing was
turned off during refresh and the refresh has therefore terminated in failure. This
situation should be treated as a shadowing failure and approached as described
in the section
Resolving Shadowing Failure
. If memory shadowing is restored, but
refresh again fails with code 1380, escalate attention to the problem.
One particular way memory or PKT-INT refresh can be led to fail is by inserting
one of these circuit packs into its slot without powering down the carrier. If this
happens, it may be necessary to cycle power on the given carrier and let the
LMM run all tests of components on the carrier to clear the problem. If such an
SPE is in standby mode,
reset spe-standby 4
would also cause the appropriate
initialization to occur. Always follow the lock-and-power-down approach to
replace circuit packs on the standby SPE.
Resolving Poor Health
It can happen that a standby SPE is properly maintaining handshake
communication, shadowing is on and the standby is fully refreshed, but for some
reason the SOH of that standby SPE remains at a level other than
functional
.
For example, in a heavily loaded system, the standby SOH may temporarily stay
at
not refreshed
, but eventually it should clear. Once refresh completes, system
software begins an effort to improve the standby SOH from
not refreshed
to
functional
. This effort can be delayed, but within a few minutes one should see
the change. If one sees an indefinite persistence of this health level, in an
otherwise perfect standby SPE, escalate the problem. This should be an
extremely rare event.
If the standby SOH Stays at
partially functional
, either the standby SPE is in
recent interchange mode
or there is a major alarm against some critical standby
component (see the table above). For the first case, verify the situation with
status spe and then clear the recent interchange mode by executing test
spe-standby long. Wait until at least the first four tests of the sequence
complete, then cancel out of the command. The standby SOH should eventually
be raised to
functional.
In the second case, check the alarm log to see if there is
any major alarm against any component of the standby SPE. If you find one, fix
