dusyi command doesn´t work 1

[lpb612]

Hi guys!

I need your help again. I have a MD110 BC9 that dusyi command doesn´t work. I searched for helping at other threads about the similar problem. The REL1 has a error in file S1/L001 and the date file is missing, but REL2 is okay. If I reset the MD110, would I restore the system with the REL2 information or not? I´m afraid to reset the MD110 and the system doesn´t back to normal operation.

Here the problem:

<dusyirint=all,dump=all;
SYSTEM DUMP INFORMATION
BUFFER TRANSFER ERROR 14:21 17MAY17
FAILED FOR FILE DATE
END

<dubdp;
BACKUP DATA
BUFFER TRANSFER ERROR
END

<allop;
CLASS: 1
85 BUFFER TRANSFER HAS FAILED
DATE TIME ALP NOIF EQU BRDID INF1 INF2 INF3 INF4
17MAY17 15:15:23 5 1 001-0-60-00 69 301 2 1 1
END

<himdp:lim=1;
DIAGNOSTICS FROM OPERATING SYSTEM
TIME DATE
10:01:09 17MAY17
DIAGNOSTICS FROM LIM 001

TIME DATE ERROR CODE
09:57:56 17MAY17 H'44
COMMUNICATION STATUS ERROR AT BUFFER TRANSFER
SEND ERRORS, DUPLEX MODE = 000
RECEIVE ERRORS, DUPLEX MODE = 001
SEND ERRORS, SIMPLEX MODE = 000
EXE A IN LIM 170
END

<dubci:dir=inl;
SPONTANEOUS PRINTOUT
RESULT OF EXTERNAL BACKUP CHECK
INITIAL LOAD DIRECTORY
CHECK TERMINATED DUE TO FILE SYSTEM DETECTED ERROR
FILE/DIRECTORY DOES NOT EXIST
END

<dubci:dir=rel1;
SPONTANEOUS PRINTOUT
RESULT OF EXTERNAL BACKUP CHECK
RELOAD DIRECTORY REL1
CHECKSUM ERROR IN FILE S1/L001
END

<dubci:dir=rel2;
SPONTANEOUS PRINTOUT
RESULT OF EXTERNAL BACKUP CHECK
RELOAD DIRECTORY REL2
SUCCESSFUL
END

<fidapath=/sysn/usr1/ses/dr/rel1/*.*;
FILE/DIRECTORY DATA
FILE FITYPE LINKS OWNER SIZE DATE
P D 1 2 5072 13APR17 15:32
S1 D 1 2 16 13APR17 15:32
S2 D 1 2 0 13APR17 15:28
S3 D 1 2 0 13APR17 15:28
S4 D 1 2 0 13APR17 15:28
S5 D 1 2 0 13APR17 15:28
PID F 1 2 14582 13APR17 15:28
SID F 1 2 50 13APR17 15:28
IOPUF F 1 2 3029 13APR17 15:28
END

<fidapath=/sysn/usr2/ses/dr/rel2/*.*;
FILE/DIRECTORY DATA
FILE FITYPE LINKS OWNER SIZE DATE
P D 1 2 5072 30MAR17 8:59
S1 D 1 2 80 30MAR17 9:00
S2 D 1 2 0 30MAR17 8:55
S3 D 1 2 0 30MAR17 8:55
S4 D 1 2 0 30MAR17 8:55
S5 D 1 2 0 30MAR17 8:55
PID F 1 2 14582 12APR17 23:46
SID F 1 2 50 12APR17 23:46
IOPUF F 1 2 3029 12APR17 23:46
DATE F 1 2 7 12APR17 23:50
END

 

[fcpli]

62 BUFFER TRANSFER HARDWARE FAULTY means that LPU has a problem (????). Check with lsfti; FIP patches are ok.

 

[lpb612]

It seems good, isn´t it?

LIM SWITCH FUNCTION TEST RESULT FOR LIMNO 1
LSU CM : OK
AM : OK
PROM : OK
RAM : NO TEST PERFORMED
CLOCK : OK
HDLC : NO TEST PERFORMED
PCM-FREE : OK
PCM-BUSY : OK
BOARD PROM RAM FEEDBACK DB-ADDR P/U-SIGN FREQ
DSU 0 OK OK OK OK OK OK
DSU 1 OK OK OK OK OK OK
DSU 2 OK OK OK OK OK OK
DSU 3 OK OK OK OK OK OK

END

 

[lpb612]

Do you still think RFEXI will not help anyway?

Where is the PID file before it will be copy to HDU? In local backup? Where is local backup? At LPU?

 

[fcpli]

You can see the local backup in BUAR (cnlip). The memory is in the LPU. RFEXI is at your own risk, but if the local bu is fine, no probs.
About all these questions: I assume you have Alex, the info is there (about BUAR, LCP etc.), just read.....

 

[lpb612]

If in the procedure of DUSYI it really catches the data and operation system from the local backup, I guess that the execution of DUSYI will not have problems because the local backup has been done (as showed at DUBDP). However, I have not sure the operation system is good.

<dubdp;
BACKUP DATA
EXTERNAL BACKUP LATEST PREVIOUS
REL1 REL2
NOT VALID NOT VALID
LOCAL BACKUP
DIVERGENT TIME AND DATE LIM 1 09:58 27JUN17 10:30 26JUN17
2 09:58 27JUN17 10:30 26JUN17
3 09:58 27JUN17 10:30 26JUN17
4 09:58 27JUN17 10:30 26JUN17
5 09:58 27JUN17 10:30 26JUN17

END


<cnlip:lim=1,dev=yes;

LIM CONFIGURATION

LIM NUMBER 1
LIM CONTROL LIM CONTROL NUMBER OF SERVICE
SYSTEM SIDE SYSTEM STATE PCM-LINKS STATE LIM
A EXECUTING 2 ACTIVE
B NOT EQUIPPED
MEMORY MEMORY MEMORY SPARE
VOLUME SPARE AFTER PACKING
24575 KB 5788 KB 5788 KB

BUAR1 1707 KB BUAR2 1323 KB

CURRENT INTER LIM SIGNAL PACKET LENGTH: 90

INTER LIM SIGNAL PACKET LENGTH CAPABILITY
BPOS CAPABILITY
001-0-00 90
001-1-00 90

 

[fcpli]

Forget about the OS, it seems to be OK (from previous traces), at least those units, which are involved in dusyi. This is 99% a HW issue (HDU, IPU, LPU, LSU etc.). Start the LIM with rfexi and see what happens.

 

[lpb612]

I was researching about the history of PABX failures and I noticed that in 2012 there was a similar case of backup faulty. At that time the LSU of LIM 1 and LIM 3 was changed.
I tested the HDU (2GB) on another PBX and the external backup was performed.
So it is likely that the problem is in the IPU, LSU or even in the LPU as you had said.

 

[fcpli]

There is nothing we can do from here with the HW, so the case is back to you. If you change the LPU, everything is reloaded from the existing backup (which is none). So start with LSU, not LPU. Changing of IPU is mission impossible, if you don't have one spare?

 

[lpb612]

Thanks for your advices.

I received one IPU spare from another branch office. Next week I will try to change it.
I don't have a LSU spare.

 

[lpb612]

I changed the IPU board but the system continues without performing DUSYI.
I made a mistake. I have a LSU spare. But before testing, I would like to perform another procedure. I installed the other IPU in LIM2. Is it possible to install the HDU in LIM2 as well and run the backup? In this case the external backup would be testing with another LSU and LPU. What do you think? I'm wrong or not.

 

[fcpli]

Yes, you can. But this one is quite tricky:
Shortly, you need to initiate a fake SYS and mml for lim2 IPU, then remove SYSN from the original IPU and re-initiate it in lim2 IPU.
You have to change the MML cable several times between the IPU boards...

 

[lpb612]

Is it possible initiate SYSN in LIM2?

I did a simple test. I initiated DISK2 in LIM2 and executed DUPUI for some UNITs. For any LIM unless LIM1, the DUPUI is executed.

<ioddp;
I/O DEVICE DATA
NODE IODEV/SUBFS EQU/BPOS SIPOS VEND/USAGE STATUS
SYSN - 001-0-60 - - IN SERVICE
SYSN SYSTERMINAL 001-0-60-1 - MML -
SYSN PORTA2 001-0-60-2 - MML -
SYSN PORTA3 001-0-60-3 - MML -
NODE2 - 002-0-40 - - IN SERVICE
NODE2 DISK2 002-0-40-0 3 ADTX IN SERVICE
ADD-SF
NODE2 PORTA4 002-0-40-1 - MML -
END


<dupui:unit=twp2,lim=1,path=/node2/usr3;
DUMPING INFORMATION
BUFFER TRANSFER ERROR 14:36 20JUL17

END

<dupui:unit=twp2,lim=2,path=/node2/usr3;
DUMPING INFORMATION
FILE TIME DATE
TWP2.P 14:36 20JUL17
TWP2.D 14:36 20JUL17

END

<fidapath=/node2/usr3/*.*;
FILE/DIRECTORY DATA
FILE FITYPE LINKS OWNER SIZE DATE
P D 1 2 64 20JUL17 14:35
D D 1 2 48 20JUL17 14:36
END

<

 

[fcpli]

So what is your conclusion here? HW fault in LIM1?
As mentioned, the SYSN can be changed to lim2, but a little bit tricky. You need two IPU boards for this, then a bunch of commands. If interested to do this, I'll send the instruction. For this I need IODDP, if not the same as above...

 

[lpb612]

Yes, IODDP is above. It has something wrong in LIM1 (LSU or LPU, I don't know). But why does it fail only for dump? The switching between extensions and trunks at all system is okay. Maybe something in RAM was corrupted? And maybe a RFEXI solves. But I'm not sure. This case is new for me.
Well, how can I initiate SYSN at LIM2? Just erase SYSN at LIM1 and initiate at LIM2.

Thanks again.

 

[lpb612]

I did the test, but it failed. How sad
I guess the next step will be try to change LSU from LIM1...

The failed test:
<dusyirint=all,dump=all;
SYSTEM DUMP INFORMATION
RESULT OF PASSIVE COMMON FUNCTIONS UPDATE
SUCCESSFUL
WAIT FOR DUMP TO LOCAL BACKUP
RESULT OF DUMP TO LOCAL BACKUP
SUCCESSFUL
RESULT OF DUMP TO EXTERNAL BACKUP


BUFFER TRANSFER ERROR 09:39 24JUL17
FAILED FOR FILE PID

END

<ioddp;
I/O DEVICE DATA
NODE IODEV/SUBFS EQU/BPOS SIPOS VEND/USAGE STATUS
NODE1 - 001-0-60 - - IN SERVICE
NODE1 PORT1 001-0-60-1 - MML -
NODE1 PORT2 001-0-60-2 - MML -
NODE1 PORT3 001-0-60-3 - MML -
SYSN - 002-0-40 - - IN SERVICE
SYSN SYSDISK1 002-0-40-0 3 ADTX IN SERVICE
SYSSUBFS11
SYSSUBFS21
SYSN SYSTERMINAL 002-0-40-1 - MML -
END

<dubdp;
BACKUP DATA
EXTERNAL BACKUP LATEST PREVIOUS
REL1 REL2
NOT VALID NOT VALID
LOCAL BACKUP
DIVERGENT TIME AND DATE LIM 1 09:38 24JUL17 10:50 20JUL17
2 09:38 24JUL17 10:50 20JUL17
3 09:38 24JUL17 10:50 20JUL17
4 09:38 24JUL17 10:50 20JUL17
5 09:38 24JUL17 10:50 20JUL17

END

 

[fcpli]

Normal traffic in the PBX is not using buffers, just dump, loading etc.
Try to change LSU in LIM1, maybe it helps. Or rfexi (if the local backup is ok, it should not kill the system).

 

[lpb612]

Thanks very much again.
To change LSU first I need to schedule a period of maintenance because the system is critical.
While I will search for another BC9 system to copy INL directory by DUSII command.

 

[lpb612]

I´m back again...

Finally, I found out a MD110 BC9 in another branch office. However, I have a doubt.
The system with problem has the version: LZY203511211-R1A/BC90G
The another system has the version: LZY2035112/1-R1A/BC90C

Are these version compatible?
Can I load the system with the INL from LZY2035112/1-R1A/BC90C and then regenerate system database without failures?

Thanks!!!

 

[lpb612]

Finally this problem was solved. But I don´t know how it happened. I simply executed the DUSYI command and it worked.
However, I realised some alarms that could indicate a restarted event at LIM 1.

10 CONTROL SYSTEM DISTURBANCE COUNTER AT TOP
DATE TIME ALP NOIF EQU INF1
02SEP17 07:26:54 31 1 001-0-**-** 0

42 RELOAD OF EXCHANGE DATA IN LIM HAS FAILED
DATE TIME ALP NOIF EQU INF1 INF2 INF3
02SEP17 07:27:11 32 2 002-*-**-** 202 1 94

73 LIM RESTARTED
DATE TIME ALP NOIF UNIT EQU INF1
02SEP17 07:27:15 33 1 RER 001-0-**-** 2

89 LOST SIGNALS IN THE GROUP SWITCH
DATE TIME ALP NOIF GSSIDE
02SEP17 07:28:39 37 1 0

65 SYNCHRONIZATION FAULT IN LIM
DATE TIME ALP NOIF EQU INF1 INF3
02SEP17 07:27:36 35 1 001-*-**-** 1 2
RDATE RTIME
02SEP17 07:27:49

101 FAULTY CLOCK PROCESSOR
DATE TIME ALP NOIF EQU INF1
04SEP17 08:25:59 29 192 001-0-**-** 1
RDATE RTIME
04SEP17 08:26:13

25 SLIP ON GROUP JUNCTOR LINE
DATE TIME ALP NOIF EQU INF1
04SEP17 18:44:10 15 15 001-0-**-** 1
RDATE RTIME
04SEP17 18:55:04

88 GROUP SWITCH MODULE CLOCK ALARM
DATE TIME ALP NOIF GSSIDE GSM
04SEP17 19:18:21 14 248 0 0
RDATE RTIME
04SEP17 19:18:57

Now the system shows frequently alarms of faulty clock processor. I think that I need to change the LSU board from LIM 1 shortly.

Thanks guys for all support.

 

[himdp]

Hi, LIM 1 restarted due to lost signals (disturbance counter at top)
In some circumstances you can investigate the cause by printing the list signals (HIMDP) and checking the SYAR dump.(SDDSP)
The SYAR dump will only be made if the status was reset following a previous start/restart as the dump is protected from being overwritten in the event of multiple restarts.

Probably not worth the effort, but an HIMDP might be interesting to see what kicked the restart off.