| Summary: | ASTERISK-01367: ztcfg causes loss of clocking on E1. | ||
| Reporter: | jcdutton (jcdutton) | Labels: | |
| Date Opened: | 2004-04-07 12:37:03 | Date Closed: | 2004-09-25 02:52:14 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Core/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| 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 | ||