Lucent Technologies R5SI Manual Do Utilizador

Issue 1

April 1997

Maintenance Commands and Trouble-Clearing Aids 

Page 8-159

download update-file 

A patch may not have been applied for the following reasons:

1. The memory card was write-protected. Remove this protection and issue a 

 command

2. The patch identifiers were inconsistent. Run 

 

and compare the old_patch identifier with the values in the update file.

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 
which stored the update file was corrupted. Apply the back out file 
immediately to back out the changes. Run the flash checksum test to 
make sure the system is back to its prepatch state. Check the validity of 
the file again with the development community and then try redownloading 
and applying the patch immediately.

4. The LMM reports a hard error. The symptoms of this is 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 couldn’t complete the programming of 
memory with the result that memory is in a corrupted state. The only 
recovery is to visit the site armed with new software and processor/ 
memory circuit packs.

In a High or Critical Reliability System, the failure causes a switch to the 
standby processor. The hardware on the standby must be repaired and 
the patch redownloaded. (There was nothing wrong with the patch)

This error is caused, not 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 
which backs out the patch should be downloaded and applied. Clearly, 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 about eight 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 can be restored to a normal state using the back out file.

Inconsistent software, as indicated by a failure in the data consistency test, can 
be caused by problems 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