DAHLIN-00209: dahdi_dummy fails compile on Fedora 13 64-bit with kzalloc implicit declaration error

[Home]

Summary: DAHLIN-00209: dahdi_dummy fails compile on Fedora 13 64-bit with kzalloc implicit declaration error

Reporter: Glen M (glen201) Labels:

Date Opened: 2010-09-07 08:36:46 Date Closed: 2011-01-20 23:27:58.000-0600

Priority: Major Regression? No

Status: Closed/Complete Components: dahdi_dummy

Versions: 2.3.0.1 Frequency of
Occurrence

Related
Issues:

Environment: Attachments:

Description: Debug below is from 2.4.0 but 2.3.0.1 has the same compile time error

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

# make MODULES_EXTRA="dahdi_dummy"
make -C drivers/dahdi/firmware firmware-loaders
make[1]: Entering directory `/usr/src/dahdi-linux-complete-2.4.0+2.4.0/linux/drivers/dahdi/firmware'
make[1]: Leaving directory `/usr/src/dahdi-linux-complete-2.4.0+2.4.0/linux/drivers/dahdi/firmware'
make -C /lib/modules/2.6.34.6-47.fc13.x86_64/build SUBDIRS=/usr/src/dahdi-linux-complete-2.4.0+2.4.0/linux/drivers/dahdi DAHDI_INCLUDE=/usr/src/dahdi-linux-complete-2.4.0+2.4.0/linux/include DAHDI_MODULES_EXTRA="dahdi_dummy.o " HOTPLUG_FIRMWARE=yes modules DAHDI_BUILD_ALL=m
make[1]: Entering directory `/usr/src/kernels/2.6.34.6-47.fc13.x86_64'
CC [M] /usr/src/dahdi-linux-complete-2.4.0+2.4.0/linux/drivers/dahdi/dahdi_dummy.o
/usr/src/dahdi-linux-complete-2.4.0+2.4.0/linux/drivers/dahdi/dahdi_dummy.c: In function âinit_moduleâ:
/usr/src/dahdi-linux-complete-2.4.0+2.4.0/linux/drivers/dahdi/dahdi_dummy.c:229: error: implicit declaration of function âkzallocâ
/usr/src/dahdi-linux-complete-2.4.0+2.4.0/linux/drivers/dahdi/dahdi_dummy.c:229: warning: assignment makes pointer from integer without a cast
/usr/src/dahdi-linux-complete-2.4.0+2.4.0/linux/drivers/dahdi/dahdi_dummy.c:237: error: implicit declaration of function âkfreeâ
make[2]: *** [/usr/src/dahdi-linux-complete-2.4.0+2.4.0/linux/drivers/dahdi/dahdi_dummy.o] Error 1
make[1]: *** [_module_/usr/src/dahdi-linux-complete-2.4.0+2.4.0/linux/drivers/dahdi] Error 2
make[1]: Leaving directory `/usr/src/kernels/2.6.34.6-47.fc13.x86_64'
make: *** [modules] Error 2
#

Comments: By: Digium Subversion (svnbot) 2010-09-07 08:47:25

Repository: dahdi
Revision: 9307

U linux/trunk/drivers/dahdi/dahdi_dummy.c

------------------------------------------------------------------------
r9307 | sruffell | 2010-09-07 08:47:25 -0500 (Tue, 07 Sep 2010) | 6 lines

dahdi_dummy: #include <linux/slab.h> for kzalloc and friends.

Fix the same issue as in r8550 for dahdi_dummy.c

(closes issue DAHLIN-209)
Reported by: glen201
------------------------------------------------------------------------

http://svn.digium.com/view/dahdi?view=rev&revision=9307
By: Shaun Ruffell (sruffell) 2010-09-07 08:48:29

glen201: Is there a particular reason you still need dahdi_dummy? The core of dahdi should no longer require a dummy span in order to generate timing.
By: Glen M (glen201) 2010-09-07 10:53:16

Kindly update the README to reflect your note. It still discusses using dahdi_dummy and the natural proclivity (based upon the past requirement of a dummy and maybe the future requirement if the OS kernel does not supply timing) is to attempt to compile and insmod this module.
By: Digium Subversion (svnbot) 2010-09-07 11:11:50

Repository: dahdi
Revision: 9308

U linux/trunk/README

------------------------------------------------------------------------
r9308 | sruffell | 2010-09-07 11:11:50 -0500 (Tue, 07 Sep 2010) | 7 lines

README: Remove references to dahdi_dummy.

Since dahdi_dummy is no longer required remove the references from
README.

(issue DAHLIN-209)
Reported by: glen201
------------------------------------------------------------------------

http://svn.digium.com/view/dahdi?view=rev&revision=9308
By: Shaun Ruffell (sruffell) 2010-09-07 11:12:18

glen201: Ehh..good point. Fixed and thanks.
By: Glen M (glen201) 2010-09-07 11:20:07

I wouldn't remove the references, because if you're using an older kernel, you'll still need dahdi_dummy without hardware, no?

The README also doesn't help in correctly determining whether the dahdi system is actually using the kernel-based clock. One would ordinarily see the dahdi_dummy module loaded from lsmod, but how does one know whether the kernel timing is being used?
By: Shaun Ruffell (sruffell) 2010-09-07 11:38:08

glen201: The core of DAHDI will provide timing on all supported kernels. So, dahdi_dummy should really never be needed.

Regarding how to determine what the actual timing source is...if there is a hardware span (as shown by dahdi_scan), the timing is coming from the hardware device. Otherwise, the timing is coming from the kernel timer. Where the core of DAHDI is getting the timing really shouldn't be something the user should have to concern themselves with.

Is there a case that I'm not thinking of?
By: Glen M (glen201) 2010-09-07 13:03:29

dahdi_dummy is still referred to in /etc/init.d/dahdi start: - so I don't know how to confirm which of

res_timing_pthread.so
res_timing_dahdi.so
res_timing_timerfd.so

are doing the timing!

Loading DAHDI hardware modules:
WARNING: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/.
wct4xxp: WARNING: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/.
[ OK ]
wcte12xp: WARNING: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/.
[ OK ]
wct1xxp: WARNING: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/.
[ OK ]
wcte11xp: WARNING: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/.
[ OK ]
wctdm24xxp: WARNING: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/.
[ OK ]
wcfxo: WARNING: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/.
[ OK ]
wctdm: WARNING: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/.
[ OK ]
wcb4xxp: WARNING: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/.
[ OK ]
wctc4xxp: WARNING: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/.
[ OK ]
xpp_usb: WARNING: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/.
[ OK ]

No hardware timing source found in /proc/dahdi, loading dahdi_dummy
Running dahdi_cfg: [ OK ]
By: Digium Subversion (svnbot) 2010-09-07 13:27:58

Repository: dahdi
Revision: 9309

U tools/trunk/dahdi.init

------------------------------------------------------------------------
r9309 | sruffell | 2010-09-07 13:27:58 -0500 (Tue, 07 Sep 2010) | 11 lines

dahdi.init: Remove reference to dahdi_dummy.

Module 'dahdi_dummy.ko' is no longer needed for DAHDI to provide timing,
therefore we can remove the explicit load of dahdi_dummy, which by
default is aliased to dahdi.ko anyway. If you've edited the DAHDI
Kbuild file in order to build dahdi_dummy explicitly, then you should
add dahdi_dummy to /etc/dahdi/modules in order to load it, but this is
not needed for normal operation.

(issue DAHLIN-209)
Reported by: glen201
------------------------------------------------------------------------

http://svn.digium.com/view/dahdi?view=rev&revision=9309
By: Shaun Ruffell (sruffell) 2010-09-07 13:35:29

I can see how that message would be confusing so I removed from the init script.

However, DAHDI doesn't have any knowledge about where asterisk is getting it's timing from (whether res_timing_pthread.so, res_timing_dahdi.so, or res_timing_timerfd.so). All DAHDI cares about is being able to provide *some* timing regardless of what spans are configured or how they are configured.

As for how to tell which timing source asterisk is using:
http://svn.asterisk.org/view/asterisk/trunk/doc/timing.txt?revision=179937
By: Glen M (glen201) 2010-09-07 16:47:53

Thanks I read that in the source. Other than dahdi_test reporting that it is using a Pseudo interface (and removing all the .so modules you don't want to load) there's no way that I can see to confirm which method was actually loaded and is being used. That's a little too black-boxed, especially for troubleshooting audio stuttering issues. Dahdi_test should really report the module being used (the name in the ast_timing_interface should be available to it, after all).

IMHO, all of these methods are undesirable - as they rely on a (near) real-time linux, essentially, and stutter in recorded greeting playback seems all too common. That leads to problems in a virtualization environment as well. Most non-real time OSs have figured out how to eliminate stuttered playback, which should be especially simple for low bandwidth audio.

By: Shaun Ruffell (sruffell) 2010-09-08 09:19:46

glen201: dahdi_test *only* tests timing from DAHDI, it doesn't (and shouldn't) know anything about the timing source Asterisk has selected.

I can't speak about the real-time performance of the non DAHDI methods of timing, but the core timer in DAHDI no longer requires "(near) real-time linux". Instead of depending on a timer (or interrupt) running at a fixed periodic rate it is scheduled to run at a fixed periodic rate, but when it runs it calculates how much time has really passed and adjusts accordingly.

This was first added to dahdi_dummy in revision 6524 http://svn.asterisk.org/view/dahdi?view=revision&revision=6524 moved into the core of DAHDI as an option in 6863 http://svn.asterisk.org/view/dahdi?view=revision&revision=6863 and made the default behavior in 8053 http://svn.asterisk.org/view/dahdi?view=revision&revision=8053 .

Given that...it's still possible for there to be audio problems due to system conditions outside of DAHDI's/Asterisk's control. Two of the biggest culprits are frame buffers and IDE drives that aren't using DMA. I've seen 50+ ms latencies due to IDE configurations.

By: Digium Subversion (svnbot) 2011-01-20 23:27:41.000-0600

Repository: dahdi
Revision: 9656

U linux/branches/2.4/README

------------------------------------------------------------------------
r9656 | sruffell | 2011-01-20 23:27:40 -0600 (Thu, 20 Jan 2011) | 9 lines

README: Remove references to dahdi_dummy.

Since dahdi_dummy is no longer required remove the references from
README.

(issue DAHLIN-209)
Reported by: glen201

Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9308
------------------------------------------------------------------------

http://svn.digium.com/view/dahdi?view=rev&revision=9656
By: Digium Subversion (svnbot) 2011-01-20 23:27:58.000-0600

Repository: dahdi
Revision: 9658

U linux/branches/2.4/drivers/dahdi/dahdi_dummy.c

------------------------------------------------------------------------
r9658 | sruffell | 2011-01-20 23:27:58 -0600 (Thu, 20 Jan 2011) | 8 lines

dahdi_dummy: #include <linux/slab.h> for kzalloc and friends.

Fix the same issue as in r8550 for dahdi_dummy.c

(closes issue DAHLIN-209)
Reported by: glen201

Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=9307
------------------------------------------------------------------------

http://svn.digium.com/view/dahdi?view=rev&revision=9658
By: John Hyde (jahyde) 2011-06-07 18:08:35.549-0500

This comment from dev is contradicting to what is currently happening in asterisk:

"The core of dahdi should no longer require a dummy span in order to generate timing."

Some discussion above about a way to "manually pick" a timing source seems more logical as Asterisk 1.8.4 is still expecting a pseudo interface for meetme to properly work, if there is no pseudo interface in asterisk, certain meetme features do not work (user announcing), and audio quality suffers.

Documentation also shows meetme is still needing pseudo interface for timing (bottom):
https://wiki.asterisk.org/wiki/display/AST/Timing+Interfaces

Something would appear to be missing - either in the application, or in the documentation??