[asterisk-bugs] [DAHDI-linux 0013930]: dahdi_dummy does not tick on some systems

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13930 
====================================================================== 
Reported By:                tzafrir
Assigned To:                
====================================================================== 
Project:                    DAHDI-linux
Issue ID:                   13930
Category:                   dahdi_dummy
Reproducibility:            sometimes
Severity:                   minor
Priority:                   normal
Status:                     feedback
====================================================================== 
Date Submitted:             2008-11-19 08:34 CST
Last Modified:              2009-02-04 14:49 CST
====================================================================== 
Summary:                    dahdi_dummy does not tick on some systems
Description: 
On some systems dahdi_dummy (or ztdummy, in the case of Zaptel) fails to
"tick" DAHDI and hence DAHDI does not provide a working timing source.

Indications that DAHDI (Zaptel) provides no timing source:

1. dahdi_test (zttest) does not give an error on startup, but hangs.
2. Asterisk >= 1.4.20 fails to start, and gives the ugly "no timing
source" error message:

ERROR[10981]: asterisk.c:3036 main: Asterisk has detected a problem
with your DAHDI configuration and will shutdown for your protection.
You have options:
        1. You only have to compile DAHDI support into Asterisk if you
need it.  One option is to recompile without DAHDI support.
        2. You only have to load DAHDI drivers if you want to take
advantage of DAHDI services.  One option is to unload DAHDI modules if
you don't need them.
        3. If you need DAHDI services, you must correctly configure
DAHDI.

An indication that dahdi_dummy should be the timing source for dahdi could
be:

  lsmod | grep ^dahdi
  dahdi                 231888  1 dahdi_dummy

Or to see that /proc/dahdi/1 is dahdi_dummy and is listed as "MASTER".


I have seen various suggestions on how to solve this. None seems to be a
silver bullet. 
====================================================================== 

---------------------------------------------------------------------- 
 (0099444) sruffell (administrator) - 2009-02-04 14:49
 http://bugs.digium.com/view.php?id=13930#c99444 
---------------------------------------------------------------------- 
I've finally been able to get onto a system that exhibits this problem.  It
appears to specifically be a problem with the periodic interrupt from the
real time clock.  If you disable the use of the real-time clock by
commenting out the line that says "#define USE_RTC", then dahdi_dummy will
fall back to the original method of using kernel timers, and tick once
again.

What I still cannot answer is why the periodic interrupt stops being
called on this system.  But perhaps what is needed is either a parameter to
allow the user forcibly use the kernel timers instead of the real-time
clock (or high-res clock for that matter if that is what they want to do)
and possibly even during startup change the driver to see if it is ticking
at a resonable rate, and if not, automatically fall back to the kernel
timers.

Although, I would rather know why it is stopping on this system before
spending any time working around it. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-02-04 14:49 sruffell       Note Added: 0099444                          
======================================================================