[asterisk-bugs] [JIRA] (DAHLIN-25) [patch] bad master selection

[Pavel Selivanov (JIRA)]

     [ https://issues.asterisk.org/jira/browse/DAHLIN-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pavel Selivanov updated DAHLIN-25:
----------------------------------

    Attachment: dahdi-base.c.patch

There are still some troubles with locating true MASTER in DAHDI 2.6.1.
1. ::master not initialized (::master = NULL).
2. even span with alarm can become a master, if old_master == NULL.
3. Nobody call __dahdi_find_master_span in _dahdi_unassign_span.
_dahdi_unassign_span have own find_master loop. What for ?
4. dynamic spans still can not become a master span.
WHY ?
5. dummy span can not become a master span (it's good to have a backup span with good 1ms ticks, provided by HPET).
WHY ?

Provided patches can be used to fix this annoing bugs.
It's done to have logic, compatible with current DAHDI logic (it will not break current installations).
To make it clear, I've wrote a number of possible cases (possible installations).

Terms:
dummy - dummy SPAN. SPAN, provided by dahdi_dummy. Have 0 channels.
card0.0 - fixed SPAN, card #0, port 0, span=...
dynamic0 - dynamic SPAN, dynamic=...
master - master SPAN.

== case 0
dummy
card0.0 - clock source (sync from E1)
card0.1 - backup clock source  (sync from the same E1)
dynamic0 - clock slave (sync from sync_tick, so, from E1)
dynamic1 - clock slave (sync from sync_tick, so, from E1)

- card0.0 = OK
  master = card0.0
- card0.0 = RED
  master = card0.1
- card0.0 = card0.1 = RED
  master = dummy (slave dynamic spans have cannot_provide_timing=1).

== case 1
card0.0 - clock source (sync from E1)
card0.1 - backup clock source  (sync from the same E1)
dynamic.0 - clock slave (sync from sync_tick, so, from E1)
dynamic.1 - clock slave (sync from sync_tick, so, from E1)

- card0.0 = OK
  master = card0.0
- card0.0 = RED
  master = card0.1
- card0.0 = card0.1 = RED
  master = NULL (slave dynamic spans have cannot_provide_timing=1).
  _process_masterspan will be called by the timer 4 times every 4ms (true for x86. actually HZ/250)...



== case 2
dummy
dynamic0 - clock source (sync from E1)
dynamic1 - backup clock source (sync from the same E1)

- dynamic0 = OK
  master = dynamic0 (master dynamic spans have cannot_provide_timing=0).
- dynamic0 = RED
  master = dynamic1 (slave dynamic spans have cannot_provide_timing=1).
- dynamic0 = dynamic1 = RED
  master = dummy

== case 3
dynamic0 - clock source (sync from E1)
dynamic1 - backup clock source (sync from the same E1)

- dynamic0 = OK
  master = dynamic0 (master dynamic spans have cannot_provide_timing=0).
- dynamic0 = RED
  master = dynamic1 (slave dynamic spans have cannot_provide_timing=1).
- dynamic0 = dynamic1 = RED
  master = NULL
  _process_masterspan will be called by the timer 4 times every 4ms (true for x86. actually HZ/250)...



== case 4
dummy
dynamic0 - clock source (sync from E1)
dynamic1 - clock slave (sync from dynamic master SPAN)

- dynamic0 = OK
  master = dynamic0 (master dynamic spans have cannot_provide_timing=0).
- dynamic0 = RED
  master = dummy (slave dynamic spans have cannot_provide_timing=1).

== case 5
dynamic0 - clock source (sync from E1)
dynamic1 - clock slave (sync from dynamic master SPAN)

- dynamic0 = OK
  master = dynamic0 (master dynamic spans have cannot_provide_timing=0).
- dynamic0 = RED
  master = NULL (slave dynamic spans have cannot_provide_timing=1).
  _process_masterspan will be called by the timer 4 times every 4ms (true for x86. actually HZ/250)...



= case 6
dummy
dynamic0 - clock slave (sync from DAHDI, via sync_tick)
dynamic1 - clock slave (sync from DAHDI, via sync_tick)

  master = dummy

= case 7
dynamic0 - clock slave
dynamic1 - clock slave

  master = NULL (slave dynamic spans have cannot_provide_timing=1).
  _process_masterspan will be called by the timer 4 times every 4ms (true for x86. actually HZ/250)...


= case 8
card0.0 - clock source (E1 slave)
card1.0 - clock slave (card 1 should take sync tick from DAHDI, so, from card0).

- card0.0 = OK
  master = card0.0
- card0.0 = RED
  master = card1.0 (if card will not set cannot_provide_timing)
  master = NULL (if card will not set cannot_provide_timing).
  So, card1 driver must pass sync_tick(s, 1) to hardware, but ignore sync_tick(s, 0), to prevent self-tune itself.

                
> [patch] bad master selection
> ----------------------------
>
>                 Key: DAHLIN-25
>                 URL: https://issues.asterisk.org/jira/browse/DAHLIN-25
>             Project: DAHDI-Linux
>          Issue Type: Bug
>          Components: dahdi (the module)
>            Reporter: Pavel Selivanov
>            Assignee: Russ Meyerriecks
>         Attachments: 0001-dahdi-wip-Fix-dynamic_loc-span-operation-with-DAHDI-.patch, dahdi-base.c.patch, dahdi-base.c.patch, dahdi-base.c_syncprio.patch, dahdi_dummy.c.patch, dahdi_dummy.c_syncprio.patch, dahdi_dynamic.c_syncprio.patch, zaptel-base.c.patch, ztdummy.c.patch
>
>
> 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...
> ****** ADDITIONAL INFORMATION ******
> Implemented: correct(symmetric) master arbitrage
> 1. trying preffered master SPAN
> 2. trying non-zero channel SPANS
> 3. trying zero-channel SPANS (ztdummy,...)
> thus:
> 1. dahdi-dynamic CAN be (and it works perfect) a master
> 2. at any time, we can tell/expect - who is the master
> 3. If (and only if) we have no master - dahdi-dummy will be our master

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira