Difference between revisions of "Debug log"
From Zenitel Wiki
(→Subscriber key signaling) |
|||
Line 38: | Line 38: | ||
Relates to physical station 30.<br> | Relates to physical station 30.<br> | ||
− | The station is in state "No subscriber line interface", this means not connected/registered or not found jet (ASLT scanning | + | The station is in state "No subscriber line interface", this means not connected/registered or not found jet (ASLT scanning after reset.) <br> |
The station receives a KEY PRES/KEY RELEASE signal, this should not be possible unless the signal comes from event handler or $DP signaled key pres. <br> | The station receives a KEY PRES/KEY RELEASE signal, this should not be possible unless the signal comes from event handler or $DP signaled key pres. <br> | ||
− | |||
Revision as of 23:54, 13 March 2012
Description of some of the messages found in the debug log.
Contents
Directory Table
W(1.65) ERR_NVRAM, no:26 "CTNS_GPDH2" P1: 0, P2: 29, P3: 863
An element in the directory tables internal hash fast lookup table has a wrong value.
(The directory table sorting system (TNS) will be triggered for be rebuild)
W(1.65) TNS_VERIFY, no:34 "CTNS_V_NOW" P1: 0, P2: 0, P3: 0
The directory table sorting system is triggered for verification/rebuild (Verify Now) .
W(1.65) TNS_VERIFY, no:35 "CTNS_REGEN" P1: 0, P2: 0, P3: 0
The directory table sorting system is regenerated.
Data Protocol
E(1.65) UNEXP_SWITCH, no:27 "DplcSndMsg" P1: 7, P2: 1, P3: 0
P1: = Link number (ACDP link) P2: = Link address (Device number) The ACDP link is not operational thus no message could be sent.
INFO_DPMR_NO_ROUTE, no:1279 CSI#1 sent READY to CSI#1 state CSI/ReadingCommands (3)"" P1: 1, P2: 62, P3: 0 Packet to node 1 device 62 dropped, no routing information
The routing to node 1 device 62 is not available (Typicaly after reset before the links are up, or due to no configuration)
Subscriber key signaling
E(1.65) UNEXP_SIG, no:1281 SBS#30 sent M_PRES_SBS to SBS#30 state SBS/IdleOnHook (14)"SBS010" P1: 0, P2: 0, P3: 0
Relates to physical station 30.
The signal M_PRES_SBS is used during active states of a subscriber. (Active in features like a call)
Since the station now is "IdleOnHook" probably the station just came back from an active state and received this signal delayed.
Maybe event handler or $DP signaled M pres?
E(1.65) UNEXP_SIG, no:6 TO_IF#1 sent KEY_PRES to SBS#30 state SBS/NoSLI (1)"SBS010" P1: 0, P2: 0, P3: 0 (1)"SBS010" P1: 0, P2: 0, P3: 0 E(1.65) UNEXP_SIG, no:87 TO_IF#1 sent KEY_REL to SBS#30 state SBS/NoSLI (1)"SBS010" P1: 0, P2: 0, P3: 0 (1)"SBS010" P1: 0, P2: 0, P3: 0
Relates to physical station 30.
The station is in state "No subscriber line interface", this means not connected/registered or not found jet (ASLT scanning after reset.)
The station receives a KEY PRES/KEY RELEASE signal, this should not be possible unless the signal comes from event handler or $DP signaled key pres.
E(1.65) UNEXP_SIG, no:7 DP#1 sent M_PRES to SBS#30 state SBS/NoSLI (1)"SBS010" P1: 0, P2: 0, P3: 0
Relates to physical station 30.
The station is in state "No subscriber line interface", this means not connected/registered or not found jet after reset.
The station receives a M_PRES signal from date protocol. I.e. from Event Handler or ACDP.
W(1.65) TABLE, no:57 "CipherErr" P1: 0, P2: 0, P3: 0
Problems with decoding of the license key.
Corrupted license string.
Could be wrong license MAC address.
Issues with reading own MAC address.
RCI - RCO
RCI
W(1.65) UNEXP_SIG, no:36262 DP#1 sent SCAN_RCI_ACK to RCI#51 state RCI/WaitResp (8)"sRCI010" P1: 0, P2: 0, P3: 0
Relate to logical RCI 51.
The input device (RIO/MIO) is sending $SCAN_RCI_ACK in a state where $RCI_IS_ON or $RCI_IS_OFF is expected.
Last signal received before this state was $SCAN_RCI_ACK, thus it looks like double signaling.
(Multi Drop Master protocol fixes for 11.2.3.2?)
W(1.65) UNEXP_SIG, no:257 DP#1 sent SCAN_RCI_ACK to RCI#71 state RCI/WaitRespAlarm (14)"sRCI010" P1: 0, P2: 0, P3: 0
Relates to RCI 71.
The RCI is active, expected signal is RCI_ON or RCI_OFF (dependent on the polarity setting).
Instead SCAN_RCI_ACK is received.
RCO
W(1.65) UNEXP_SWITCH, no:65294 DP#1 sent CLEAR_RCO_ACK to RCO#1 state RCO/Running (1)"RcoUnexp" P1: 7, P2: 0, P3: 0.
Relates to RCO 7 (P1)
Unexpected CLEAR_RCO_ACK from RIO/MIO, (no pending ACK for this RCO). Could it be resending of CLEAR_RCO_ACK?
W(1.65) UNEXP_SWITCH, no:10429 DP#1 sent SET_RCO_ACK to RCO#1 state RCO/Running (1)"RcoPolarit" P1: 8, P2: 0, P3: 0
Relates to RCO 7 (P1)
unexpected SET_RCO_ACK from RIO/MIO, (no pending ACK for this RCO). Could it be resending of SET_RCO_ACK?
Conference
E(1.65) ILLEGAL_PAR, no:39413 SPF#30 sent ST_TALK_STOP to CNF#5 state CNF/Operating (1)"CnfTalkSto" P1: 30, P2: 0, P3: 0
Physical station 30 was asked to stop talking in conference 5, but no one was talking in the conference.
P1 = New Talker To stop
P2 = Current talker
E(1.65) UNEXP_SIG, no:39414 SPF#30 sent DP_TALK_END_RCTRL to SBS#30 state SBS/IdleOnHook (14)"SBS010" P1: 0, P2: 0, P3: 0
This is a result of the "CnfTalkSto" error message.
Conference 5 was replying to the "stop talking message" but subscriber 30 was not talking, "IdleOnHook".
E(1.65) UNEXP_SIG, no:41065 SPF#37 sent DP_TALK_SUCCESS to SBS#37 state SBS/GoActiveKeyPres (52)"SBS010" P1: 0, P2: 0, P3: 0
Station 37 entered talk mode in a conference at the same moment as a key pres was activated on the station.
This resulted in the acknowledge message "DP_TALK_SUCCESS" from the conference was received in a transit state for activating the station because of key pres.
E(1.65) UNEXP_SIG, no:41068 SPF#37 sent CONFERENCE_MODE to SBS#37 state SBS/ConfGoTalk (76)"SBS010" P1: 0, P2: 0, P3: 0
Station 37 is entering talk mode in a conference and at the same time receives a signal for entering conference mode.
The subscriber and the conference seams to be out of sync, or $DP conference messages are interfering the internal state changes of the station
E(1.65) UNEXP_SIG, no:21354 SPF#30 sent NORMAL_MODE to SBS#30 state SBS/IdleOnHook (14)"SBS010" P1: 0, P2: 0, P3: 0
Physical station 30 is asked to leave conference mode and return to idle, but the station is already in idle.
(Conference and station mismatch in state, $DP messages?)