[Home]

Summary:DAHLIN-00012: channel slave status not correctly cleared
Reporter:Richard van der Hoff (richvdh)Labels:
Date Opened:2007-12-20 11:22:50.000-0600Date Closed:2008-09-25 22:27:53
Priority:MinorRegression?No
Status:Closed/CompleteComponents:
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:If I configure a batch of channels to be slaved together (via zaptel.conf and ztcfg), then try to reset them to individual channels, the master channel gets stuck with a master status.


****** ADDITIONAL INFORMATION ******

1. First configure a span as follows:
span=1,1,0,ccs,hdb3,crc4
bchan=1-15,17-31
dchan=16

/proc/zaptel/1 then shows (correctly):
          1 TE4/0/1/1 Clear
          2 TE4/0/1/2 Clear
          3 TE4/0/1/3 Clear
          4 TE4/0/1/4 Clear



2. Now reconfigure as follows:
span=1,1,0,ccs,hdb3,crc4
clear=1-31

/proc/zaptel/1 then shows (still correctly):
          1 TE4/0/1/1 Clear Master
          2 TE4/0/1/2 Clear
          3 TE4/0/1/3 Clear
          4 TE4/0/1/4 Clear
...


3. Finally reconfigure as in 1.

/proc/zaptel/1 now _incorrectly_ shows:
          1 TE4/0/1/1 Clear Master
          2 TE4/0/1/2 Clear
          3 TE4/0/1/3 Clear
          4 TE4/0/1/4 Clear
...

Furthermore any data transmitted or received over channel 1 is corrupted.

Comments:By: Tzafrir Cohen (tzafrir) 2007-12-28 14:26:54.000-0600

I can replicate the problem here.
By: Shaun Ruffell (sruffell) 2008-01-11 18:34:21.000-0600

This can be worked around by running ztcfg with the -f command to force the update.

In step 1 each channel is set as it's own master, but it is not reported since they do not have any slaves.

In step 2 channel 1 is set to the master with slaves.

In step 3 ztcfg sees that channel 1 is already it's own master, and therefore doesn't reconfigure it, so the nextslave field never gets cleared.

Now how to fix it...
By: Digium Subversion (svnbot) 2008-08-01 17:59:05

Repository: dahdi
Revision: 4653

U   linux/trunk/drivers/dahdi/dahdi-base.c

------------------------------------------------------------------------
r4653 | kpfleming | 2008-08-01 17:59:04 -0500 (Fri, 01 Aug 2008) | 6 lines

use correct logic to handle a slave channel being removed from a master channel, so if the master channel itself is not reconfigured it will still end up properly linking to any remaining slaves

(closes issue DAHLIN-12)
Reported by: richvdh
Tested by: tzafrir

------------------------------------------------------------------------

http://svn.digium.com/view/dahdi?view=rev&revision=4653
By: Shaun Ruffell (sruffell) 2008-09-25 22:27:53

I made the following commit because it was possible to cause a kernel oops if the master channel was cleared, and then DAHDI_GET_PARAMS was called.  This was occuring for me if placing a tdm400 in a system with 2 FXO ports, misconfiguring those ports as fxoks, then changing the configuration to fxsks and rerunning dahdi_cfg.

http://svn.digium.com/view/dahdi?view=rev&revision=4990