ERR008

[hklt0110]

This past day's I'm getting error on our Meridian/Avaya System - any clarification and help with us is very much appreciated, since our Telephony provider is blaming our network for errors:

Here is the error:

ERR008 07489DA2 00000607 031021AD 00006000 000001C8 0 00000000 00000000 00000000
0 702
A2A7 6185 1395 9 0 0
MG 177 1 1C8 07489DA2
307A3CC1 309239F5 30922DF7 3091C183 30918707
ERR8 + 30913706 44D7794F 3146BF3E 31811416 31810656
ERR008 + 3180943E 3173B2B0 30D82DF1
0 0 13 23 00 2 7 0 0 2 7

Any suggestions or explanation are very much appreciated.

 

[Firebird Scrambler]

I found this record below that might be helpful. What release is your CS1000 system?.

CS1000E rls 7.00
MGCs with 128-port DSP daughterboards
Default MGC loadware lineup:
IPMG TYPE CSP/SW MSP APP FPGA BOOT DBL1 DBL2

0 1 MGC BD02 AB01 BA07 AA18 BA07 DSP5AB01 N/A

MGCs reboot unexpectedly with this sort of thing in the MGC log:

[0086] 17/03/2011 00:54:03 LOG0004 tGtlRx: ALERT INDICATION devId = 1, alert type = 0x24, CPU number = 0, Unique Id = 0x3, Link RegVal = 0x6a438, Alert data size = 232
[0087] 17/03/2011 00:54:03 LOG0004 tGtlRx: Alert data:
[0088] 17/03/2011 00:54:03 LOG0004 tGtlRx: 0x24 0x700 0xfffe 0x3 0x197 0x0 0x13 0x0 0xa438 0x6 0xff8d 0xeaff 0x1f 0x0 0x13 0x0 0x0 0x0 0x4 0x0 0x9d00 0x8a 0xa8 0x0 0xbd00
[0089] 17/03/2011 00:54:03 LOG0004 tGtlRx: 0x8a 0xa200 0x8a 0x0 0x0 0x1 0x0 0x1 0x0 0x1 0x0 0x5ec 0x0 0xa440 0x6 0x19ac 0x24 0x3dd 0x3e4 0x29cc 0x0 0x9d00 0x8a 0xe1ad 0x28b
[0090] 17/03/2011 00:54:03 LOG0004 tGtlRx: 0xa8 0x0 0xbaa4 0x8 0x55a2 0xfaec 0xa0 0x0 0x13 0x2000 0x4bfc 0xa05 0x9d00 0x8a 0xdd00 0x8a 0xd00 0x8b 0xbd00 0x8a 0xa200 0x8a 0x0 0x0 0xbd00
[0091] 17/03/2011 00:54:03 LOG0004 tGtlRx: 0x8a 0xdee4 0x8 0xd5f8 0x89 0x5 0x0 0xdece 0x89 0xd4e0 0x89 0xbd00 0x8a 0x9d00 0x8a 0x2520 0xa09 0x10 0x0 0x0 0x0 0x9bc0 0x8a 0xbd00 0x8a
[0092] 17/03/2011 00:54:03 LOG0004 tGtlRx: 0xd274 0x8 0x4 0x0 0xd00 0x8b 0x9d00 0x8a 0x15fc 0x8 0x9d 0x0 0x269 0x0 0x74c 0xa00 0x0 0x0 0x0 0x0 0x0 0x0 0x300 0x6 0x0
[0093] 17/03/2011 00:54:29 LOG0004 VGW: channel 149 close msg in unknown dspMode: Opening, tick 4282956
[0094] 17/03/2011 00:55:09 LOG0004 VGW: Memory Dump in progress on device 1
[0095] 17/03/2011 01:01:17 MGC0015 Device 1 DSP Core Dump has happened
[0096] 17/03/2011 01:01:17 LOG0004 VGW: REBOOTING MGC AFTER MEMORY DUMP
[0097] 17/03/2011 01:01:22 SRPT0781 RST 0: COLD START IN PROGRESS - Reason -1


Resolved by installing new DSP loadware DSP5AZ05.lw
This is a debug version and may be superseded by a proper GA version shortly

** DSP5AB04 is the GA release which includes the fix for the above issue **

It may be necessary to take the MGC back to the Gold image before it will accept the new DSP loadware - see other Orbit record for instructions.

Further versions of DSP loadware have since been written but not yet officially released.

=======
Extra note. Seen this on another site, It was thought on that site that the CLS FAXA being set on an extn which call forwarded to another with no FAXD or to the switchboard. Never confirmed (As this would have made the MGC reboot again), but the fix is the same. Use the latest loadware.
The Call Server outpur ERR008 messages before the reboot
ERR008 0F10C9B7 00000607 01182084 00007C1C 00000056 0 00000000 00000000 00000000 0 7803
1183 0 0 0 0 0
MG F6 1 56 0F10C9B7
00B07EDE 00C7DFE0 00C7D41C 00C76948 00C72F98
ERR8 + 00C6E8C4 01905F44 01905E6E 01CB9EED 01CB9151
ERR008 + 01CB1C1E 0119C9EA
0 0 13 14 0 0 5 6 0 0 5 6





Firebird Scrambler

Nortel & Avaya Meridian 1 / Succession & BCM / Norstar Programmer

Website =

http://somertel.com

linkedin

 

[hklt0110]

I will check the loadware version to our provider since we don't have administrator rights. As per error - yes, the call drop once it is forwarded to another extension.


I also remove/do not broadcast the wireless network with SIP.Since we have SIP on wireless network which I've seen some mac flapping on SIP Network, since the provider told us that the error was cause by network switches, I reiterated that once network switches has a problem, all network will be disrupted but they keep blaming on us (network group).

I cannot told them that I have also experience with VoIP network but since we have different group/department - we just keep it as it is. This will be a difficult for us since they really think it's network problem.