[asterisk-bugs] [DAHDI-linux 0013205]: [patch] bad master selection

Asterisk Bug Tracker noreply at bugs.digium.com
Tue Feb 10 00:06:40 CST 2009


A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13205 
====================================================================== 
Reported By:                biohumanoid
Assigned To:                kpfleming
====================================================================== 
Project:                    DAHDI-linux
Issue ID:                   13205
Category:                   dahdi (the module)
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
====================================================================== 
Date Submitted:             2008-07-31 00:11 CDT
Last Modified:              2009-02-10 00:06 CST
====================================================================== 
Summary:                    [patch] bad master selection
Description: 
Current dahdi master handling work in the following way:
The first SPAN become a master
If a new registered !!! SPAN is preferred , it is the new master
If a span is unregistered - the new master is the first available span
If master SPAN is in alarm state - the new master is the first non in
alarm state SPAN

So
1. dahdi-dummy once loaded will be the master forever.
2. even not-running SPAN can be a master
3. master implementation is ugly...
====================================================================== 

---------------------------------------------------------------------- 
 (0099776) biohumanoid (reporter) - 2009-02-10 00:06
 http://bugs.digium.com/view.php?id=13205#c99776 
---------------------------------------------------------------------- 
I'm happy you've asked it :-)

As far as I know, in most drivers syncsrc is used as a span priority in an
adapter. The lowest non-alarm span is used as a sync source for the whole
adapter.
So, "timing" field can be(and should be) used for dahdi arbitrage.

I'd like this simplified order:
1. a non-alarm OPEN SPAN with a lower priority (except DUMMY)
2. DUMMY span
dahdi_dynamic should use syncsrc field (removing checkmaster function,
...).
Now it's possible as long as dahdi_span have sync_tick callback.
If a SPAN have syncsrc !=0, and dahdi's master is other SPAN, then driver
must use (if can) sync_tick callback to provide timing for a SPAN. 

A quick example:
#board 1
span=1,1,0,ccs,hdb3,crc4
span=2,2,0,ccs,hdb3,crc4
#board 2
span=3,3,0,ccs,hdb3,crc4
dynamic=eth,eth0/00:02:b3:35:43:9c,24,4

All SPAN's have good line. 
SPAN 1 is a master.
SPAN 2 using timing from line 1.
SPAN 3 isn't a master for dahdi, so, using sync_tick.
SPAN 4 using sync_tick.

SPAN 1 & SPAN 2 changed to RED ALARM.
dahdi changing it's master to SPAN 3.
SPAN 3 switching to use timing from line.
SPAN 4 using sync_tick.

and so on.
If we want SPAN 3 & SPAN 4 to be timing providers - we can change it's
priority to zero. 

I think it's a good to give users a choice.
DAHDI should't not differ SPAN, dSPAN, PRI, BRI,... 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-02-10 00:06 biohumanoid    Note Added: 0099776                          
======================================================================




More information about the asterisk-bugs mailing list