No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

What If the NESF_LOS Alarm Is Reported After the Q3CXL Board Is Upgraded on the OptiX OSN 2500

Publication Date:  2012-07-25 Views:  79 Downloads:  2
Issue Description
The OptiX OSN 2500s in a certain office were upgraded to version 5.36.18.50P01 by means of the simulation packet loading. After the upgrade was successfully performed, the system control boards reported the NESF_LOST alarm with the parameters of 0x01, 0x00, 0x0d, 0x01, 0xff. The hardware version of the system control boards was SSQ3CXL.
Alarm Information
NESF_LOST
Handling Process

1. The first parameter of the NESF_LOST alarm is fixed. The third parameter of the alarm is the registered path ID of the lost software. The lost file can be queried by comparing this path ID with the actual path ID by using the :sftm-get-fpatrol-info:bid command.

2. Alternatively, the following commands can be used to query the software of the upgraded NE. To be specific, make a comparison between the normal NE and the alarmed NE. Check whether any necessary files are not loaded or whether the size of the loaded software is abnormal. Reload the lost or inconsistent files.

:sftm-show-dir:82(83),"/ofs1/fpga";

:sftm-show-dir:82(83),"/ofs1/hwx";

:sftm-show-dir:82(83),"/ofs2/fpga";

:sftm-show-dir:82(83),"/ofs2/hwx";

3. After comparing the normal NE with the alarmed NE, the engineer found that on the alarmed NE, some earlier-version files existed but the q31500.hwx file was missing under the /ofs1/hwx, /ofs2/hw directory. For details, see the attachment.

4. According to the R&D engineer, the problem arose because the software routine inspection defined on the SSQ3CXL board is different from that on the earlier-version board and the extended BIOS on the board did not take effect. In this case, do as follows:

(For example, the board in slot 83 is the standby system control board, and the board in slot 82 the active system control board.)

Step 1:

On the Navigator, run the following commands to rename the extended BIOS files of the active and standby system control boards.

:sftm-copy-file:82,"/ofs1/hwx/extbios.hwx",82,"/ofs1/hwx/q3ebios.hwx";

:sftm-copy-file:83,"/ofs1/hwx/extbios.hwx",83,"/ofs1/hwx/q3ebios.hwx";

:sftm-copy-file:82,"/ofs2/hwx/extbios.hwx",82,"/ofs2/hwx/q3ebios.hwx";

:sftm-copy-file:83,"/ofs2/hwx/extbios.hwx",83,"/ofs2/hwx/q3ebios.hwx";

Then, run the following commands:

:sftm-show-dir:83,"/ofs1/hwx";

:sftm-show-dir:83,"/ofs2/hwx";

:sftm-show-dir:82,"/ofs1/hwx";

:sftm-show-dir:82,"/ofs2/hwx";

If the q3ebios.hwx file exists, delete the existing file extbios.hwx.

:sftm-delete-file:82,"/ofs1/hwx/extbios.hwx"

:sftm-delete-file:83,"/ofs1/hwx/extbios.hwx"

:sftm-delete-file:82,"/ofs2/hwx/extbios.hwx"

:sftm-delete-file:83,"/ofs2/hwx/extbios.hwx"

Step 2:

Run the :cfg-reset-board:83,soft and :cfg-reset-board:82,soft commands to reset the standby system control board, and then the active system control board.
Root Cause

1. The NESF_LOST alarm was incorrectly reported.

2. Some necessary files were not loaded.

3. Other reasons.
Suggestions
The problem arose because the software routine inspection defined on the SSQ3CXL board is different from that on the earlier-version board and the extended BIOS on the board did not take effect. For how to handle the NE on which the Q3CXL board has not reported the NESF_LOS alarm, see the attachment.

END