Description of the problem

Huawei OSN3500 equipment HSC_UNAVAIL alarm, after processing found that the alarm has a lot of reasons may lead to, NG-SDH equipment site will have a lot of cases reported HSC_UNAVAIL alarm, the following is a detailed description of the meaning of the alarm.

Alarm Message

HSC_UNAVAIL on Huawei OSN3500 equipment.

Processing

During the processing, it is finally positioned as a cross-board fault, but through analysis, not only cross-board faults will lead to the reporting of this alarm, the following is a list of possible faults according to the parameters of the reported alarm:

1, when the alarm parameter PARA1 = 0x80

that the cross board just hard reset up less than 5 minutes (5 minutes of timing is a bit of error, in the range of 5 to 8 minutes are normal, because the timing is from the alarm module after the start of the task began to run after the start counting), if there is no other abnormalities at this time, 5 minutes after the alarm will automatically disappear.

This alarm does not necessarily affect the cross-primary backup reversal, just used to remind the user at this time it is best not to hard reset the motherboard or pull the board operation, so as not to affect the business (the backup board just up to synchronize some data from the motherboard), in addition to the single-board srv on the yellow light!

2, alarm parameter PARA1 = 0x01 when

that the board detects the state of the board bad, this alarm will generally be accompanied by HARD_BAD alarm, if the current alarm in the HARD_BAD alarm, we must pay attention to query the history of the alarm in the wrong HARD_BAD, while backing up the black box records, locate to the specific aspects of the hardware failure caused by. (Note: If there is no HARD_BAD alarm in the current alarm, there is another possibility that the alarm PARA1=0x81 was reported after the hard reset, and the alarm 0x80 was canceled after the 5-minute timer arrived, so there is still the alarm PARA1=0x01, which is caused by the unfinished host backup of the bad ready line, and it will end only after the host backup is completed.)

3、When the alarm parameter PARA1 = 0x02

indicates that the business board detects a bad ready line, when this alarm occurs, the general business board will report T_LOSEX (the business board detects an alarm on the business bus sent over the cross) or TR_LOC (the business detects a fault in the frame header, clock, and bad board sent over the cross board), and at the same time report a bad cross board through the 0xCE4 command; if it is a UXCSB with an extended subframe, it may be that the XCE board reports a bad alarm. It is possible that the XCE board reports the BUS_ERR alarm.

.

On the cross board, you can check the status of the cross board reported by the service board through the 0xC47 command.

:optp:9,0,77,1,c,47,0

:optp:9,0,77,1,c,47,1

4、When alarm parameter PARA1 = 0x04

Indicates that the crossover board detects a type 2 BUS_ERR alarm (i.e., the reported alarm bus is detected normally by the main board, but abnormally by the backup board).

You can check the comprehensive status of Type 2 BUS_ERR detection on the cross board by using the 0xC47 command.

:optp:9,0,77,1,c,47,2

:optp:9,0,77,1,c,47,3

The specific alarms are as follows

Note: Cross actually report alarms may also be a composite of two, three or four of the above four cases, such as PARA1= 0x81, PARA1=0x03, PARA1=5, PARA1= 0x07, etc., at this time to gradually locate according to the meaning of the individual bit representation.

5, the alarm does not disappear

After hard resetting the main cross board for master and backup cross reversal, the HSC_UNAVAIL alarm does not disappear.

The problem is roughly like this: the host in the hard reset command to the cross board before the 0xC52 pre-reset command, set the cross board bad offline (this is currently done to achieve the cross of the master and backup of the rapid reversal, reduce the impact on business), in the real reset of the board before the cross-board software detected a bad state of the single board to report the HSC_UNAVAIL (PARA1 = 0x01), and then because of the host After that, due to the faults in host processing, the alarms do not disappear after the reset of the single board, and no BD_STATUS alarms are reported.

In similar cases, we have to go to the site in time to locate whether it is a cross-board problem.

Method one:

Directly use 0x211 to command whether there is still an alarm on the single board

:optp:9,0,2,6,2,11,0,0

Method two:

You can also use the alm-set-bsrep command to turn on the original alarm reporting function, to see whether the cross board to the host to report the end of the alarm, at the same time, this alarm should be registered as from the single board. If the crossover board doesn't report, it will automatically check the end of the host after 3 minutes. If the cross board doesn't keep reporting alarms to the host, it's not the cross board's problem anyway.

Root Cause

Huawei OSN3500 HSC_UNAVAIL is only reported by the backup board, and the meaning of this alarm is as follows:

Alarm meaning: para[0] Indicates the type of the alarm

BIT[0]: bad state of this board

BIT[1]: Bad board detected by service board.

BIT[2]：Type 2 BUSERR is detected by this board.

BIT[3~6]: reserved

BIT[7]: spare board hard reset up for 5 minutes

para[1] Indicates the primary and backup status of the unavailable boards

0-main board; 1-spare board

para[2] Indicates the physical slot number where the board is unavailable

9, 10 (3500 devices)

80, 81 (1500, 2500 devices)

para[3~4] 0xff

Recommendations and Summary

The alarm is summarized as follows:

1. 5 minutes after the Huawei SXCSA crossover board is hard reset up, only the HSC_UNAVLIABLE alarm is reported if there is no accompanying other failure;

2, the cross-board software detects its own hardware failures and places the board in bad condition. At this time, in addition to reporting the HSC_UNAVLIABLE alarm, it is accompanied by the HARD_DAD alarm and the rest of the alarms that lead to hardware failure, such as CHIP_FAIL, POWER_ABNORMAL, etc. The alarms are summarized as follows;

3. The FPGA of the cross-board detects a hardware failure, which is accompanied by the HARD_DAD alarm in addition to the HSC_UNAVLIABLE alarm;

4, the cross-board software detects a type 2 BUS_ERR, which is accompanied by a BUS_ERR alarm in addition to the HSC_UNAVLIABLE alarm;

5, the business board detects that the clock or frame header or signal sent over by the cross board is faulty, and reports that the cross board is bad (the cross board itself does not have any faults), at this time, the cross board only reports the HSC_UNAVLIABLE alarm, and the business board reports the T_RLOC or T_LOSEX alarm;

The HSC_UNAVAIL alarm is reported only by the crossover backup board! The main crossover board is not processed!

The technical information related to this chapter and the SDH equipment troubleshooting process are collected and organized by Shenzhen Optical Transmission Network Technology Co. ( www.opticaltrans.com), please retain the reproduction! Our company specializes in the sales of Huawei SDH optical transmission equipment, SDH transmission equipment.