Filter
Top Products
DEFINITY Enterprise Communications Server Release 6
Maintenance for R6vs/si
555-230-127
Issue 1
August 1997
Maintenance Commands and Trouble-Clearing Aids
Page 8-91download update-file
8
3. The LMM encountered a problem with the patch file. This is unlikely
because the same checks (and more) were performed when the file was
downloaded, prior to marking the file valid. This implies that the memory
that stored the update file was corrupted.
a. Apply the back out file immediately to back out the changes.
b. Run the flash checksum test to make sure the system is back to its
prepatch state.
c. Check the validity of the file again
d. Try redownloading and applying the patch immediately.
4. The LMM reports a hard error. Symptoms of this are an entry in the
hardware error log for the processor/memory board (if you’re lucky), or
extremely odd switch behavior followed by SPE down mode (if you’re not).
The problem is that the LMM cannot complete the programming of
memory with the result that memory is in a corrupted state. The only
recovery is to get or order new software and processor/ memory circuit
packs.
In a High or Critical Reliability System, the failure causes a interchange to
the standby processor. The hardware on the standby must be repaired
and the patch redownloaded. (There was nothing wrong with the patch.)
Good application - bad patch
This error is not caused by a failure in the download or application, but by a fault
in the patch file itself. To recover from this type of problem, the back out file that
backs out the patch should be downloaded and applied. This requires that the
system be sane enough to receive the file correctly and be able to apply it.
In a High or Critical Reliability System, the user has approximately 8 minutes to
recognize that a problem exists and force an interchange to the standby
processor. If this can be done, the file on the newly-active processor can be
invalidated using a file containing a destroy tuple or the
wp byte
command. The
standby processor can be restored to a normal state using the back out file.
Inconsistent software versions on a duplicated
switch
As indicated by a failure in the data consistency test, inconsistent software can
be caused by problems in copying the update file to the standby or validation
test failures on the standby. Unlike the tape or MIPS systems which revert to the
same version of software as a result of a refresh, a flash system remains
inconsistent until some manual intervention occurs:
1. Use the list config software command to determine the status of the
vintages, patch identifiers, and patch file data on both the active and
standby processors.