Summary:ASTERISK-01367: ztcfg causes loss of clocking on E1.
Reporter:jcdutton (jcdutton)Labels:
Date Opened:2004-04-07 12:37:03Date Closed:2004-09-25 02:52:14
Versions:Frequency of
Environment:Attachments:( 0) zaptel-clocksync.diff
Description:# cat /proc/zaptel/1
Span 1: TE4/0/1 "TE410P (PCI) Card 0 Span 1" HDB3/CCS ClockSource
# ztcfg
# cat /proc/zaptel/1
Span 1: TE4/0/1 "TE410P (PCI) Card 0 Span 1" HDB3/CCS

You can see that the ClockSource disappears for no valid reason. The Span changes to Internal clocking, when it should just stay on clocking from span 1.
Comments:By: Mark Spencer (markster) 2004-04-07 16:18:37

Okay should be fixed in CVS, please comment as soon as you can.

By: jcdutton (jcdutton) 2004-04-07 17:56:52

The attached diff file cures the problem for me.
It seems that when running ztcfg, the entry for span 1 is actually removed from the list and then returned to the list of availiable spans. During this process, the spansrc entries of all spans is set to 0 (or internal clocking). But "wc->syncsrc" stays set to a valid value, so the clock source setting at: -
line: 660
               for (x=0;x<4;x++)
                       wc->spans[x].syncsrc = unit;

never gets run after a ztcfg.

My clocksync.diff file just removes the
if (unit != wc->syncsrc) {
so that the clock source is always reset after a ztcfg command.
I think we would need to double check that the clock source is also not removed when a yellow alarm appears, and also is removed/replaced if a red alarm appears.

By: Mark Spencer (markster) 2004-04-07 18:44:54

Actually it turns out the timing is correct, it just wasn't being displayed properly.

By: Mark Spencer (markster) 2004-04-07 18:45:40

Fixed in CVS