[asterisk-dev] Dahdi building: autoconf generated configure script
Hey there,
I've got a trivial question I hope to get a quick response to :)
I am fiddling with dahdi 2.10.0.1 on non-linux variant of UNIX. To be
more specific, I am trying to build dahdi from sources, and am a bit
confused about autoconf.
It seems that 'configure' script generated using 'tools/configure.ac' is
not quite the same as 'tools/configure' (which is supposed to be
generated using corresponding 'configure.ac', right ?).
# autoconf configure.ac > configure.generated_via_autoconf
I am attaching a diff, that suggests that last configure.ac is
out-of-sync, and seems to be stuck in dahdi 2.8.
Is this correct ?
Sincerely,
-Ł
--- configure.orig 2014-10-27 03:44:37.191346234 -0800
+++ configure.generated_via_autoconf2014-10-27 04:00:08.520237312 -0800
@@ -1,7 +1,7 @@
#! /bin/sh
-# From configure.ac Revision.
+# From configure.ac.orig Revision.
# Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.69 for dahdi 2.8.0.
+# Generated by GNU Autoconf 2.69 for dahdi 2.10.0.1.
#
# Report bugs to .
#
@@ -583,8 +583,8 @@
# Identity of this package.
PACKAGE_NAME='dahdi'
PACKAGE_TARNAME='dahdi'
-PACKAGE_VERSION='2.8.0'
-PACKAGE_STRING='dahdi 2.8.0'
+PACKAGE_VERSION='2.10.0.1'
+PACKAGE_STRING='dahdi 2.10.0.1'
PACKAGE_BUGREPORT='www.asterisk.org'
PACKAGE_URL=''
@@ -631,19 +631,6 @@
ASCIIDOC
USE_SELINUX
PBX_HDLC
-PBX_DAHDI23
-PBX_USB
-USB_DIR
-USB_INCLUDE
-USB_LIB
-PBX_NEWT
-NEWT_DIR
-NEWT_INCLUDE
-NEWT_LIB
-PBX_DAHDI
-DAHDI_DIR
-DAHDI_INCLUDE
-DAHDI_LIB
DAHDI_DECLARATION_AFTER_STATEMENT
DAHDI_DEVMODE
DOWNLOAD
@@ -653,7 +640,6 @@
HOSTCC
BDFARCH
BDFNAME
-GNU_MAKE
LN_S
INSTALL_DATA
INSTALL_SCRIPT
@@ -711,9 +697,6 @@
ac_user_opts='
enable_option_checking
enable_dev_mode
-with_dahdi
-with_newt
-with_usb
with_selinux
with_ppp
'
@@ -1266,7 +1249,7 @@
# Omit some internal or obsolete options to make the list less imposing.
# This message is too long to be a string in the A/UX 3.1 sh.
cat <<_ACEOF
-\`configure' configures dahdi 2.8.0 to adapt to many kinds of systems.
+\`configure' configures dahdi 2.10.0.1 to adapt to many kinds of systems.
Usage: $0 [OPTION]... [VAR=VALUE]...
@@ -1327,7 +1310,7 @@
if test -n "$ac_init_help"; then
case $ac_init_help in
- short | recursive ) echo "Configuration of dahdi 2.8.0:";;
+ short | recursive ) echo "Configuration of dahdi 2.10.0.1:";;
esac
cat <<\_ACEOF
@@ -1340,9 +1323,6 @@
Optional Packages:
--with-PACKAGE[=ARG]use PACKAGE [ARG=yes]
--without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no)
- --with-dahdi=PATH use DAHDI files in PATH
- --with-newt=PATHuse newt files in PATH
- --with-usb=PATH use usb files in PATH
--with-selinux enable (with) / disable (without) SELinux
--with-ppp=PATH Use PPP support from PATH
@@ -1422,7 +1402,7 @@
test -n "$ac_init_help" && exit $ac_status
if $ac_init_version; then
cat <<\_ACEOF
-dahdi configure 2.8.0
+dahdi configure 2.10.0.1
generated by GNU Autoconf 2.69
Copyright (C) 2012 Free Software Foundation, Inc.
@@ -1793,7 +1773,7 @@
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
-It was created by dahdi $as_me 2.8.0, which was
+It was created by dahdi $as_me 2.10.0.1, which was
generated by GNU Autoconf 2.69. Invocation command line was
$ $0 $@
@@ -4332,34 +4312,7 @@
$as_echo "no, using $LN_S" >&6; }
fi
-{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for GNU make" >&5
-$as_echo_n "checking for GNU make... " >&6; }
-if ${ac_cv_GNU_MAKE+:} false; then :
- $as_echo_n "(cached) " >&6
-else
- ac_cv_GNU_MAKE='Not Found' ;
- ac_cv_GNU_MAKE_VERSION_MAJOR=0 ;
- ac_cv_GNU_MAKE_VERSION_MINOR=0 ;
- for a in make gmake gnumake ; do
- if test -z "$a" ; then continue ; fi ;
- if ( sh -c "$a --version" 2> /dev/null | grep GNU 2>&1 > /dev/null ) ;
then
- ac_cv_GNU_MAKE=$a ;
- ac_cv_GNU_MAKE_VERSION_MAJOR=`$ac_cv_GNU_MAKE --version | grep "GNU
Make" | cut -f3 -d' ' | cut -f1 -d'.'`
- ac_cv_GNU_MAKE_VERSION_MINOR=`$ac_cv_GNU_MAKE --version | grep "GNU
Make" | cut -f2 -d'.' | cut -c1-2`
- break;
- fi
- done ;
-
-fi
-{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_GNU_MAKE" >&5
-$as_echo "$ac_cv_GNU_MAKE" >&6; } ;
-if test "x$ac_cv_GNU_MAKE" = "xNot Found" ; then
- as_fn_error $? "*** Please install GNU make. It is required to build
Asterisk!" "$LINENO" 5
- exit 1
-fi
-GNU_MAKE=$ac_cv_GNU_MAKE
-
-
+AST_CHECK_GNU_MAKE
test_obj=conftest.o
if ac_fn_c_try_compile "$LINENO"; then :
@@ -4620,402 +4573,15 @@
fi
+AST_EXT_LIB_SETUP(DAHDI, DAHDI, dahdi)
+AST_EXT_LIB_SETUP(NEWT, newt, newt)
+AST_EXT_LIB_SETUP(USB, usb, usb)
-DAHDI_DESCRIP="DAHDI"
-DAHDI_OPTION="dahdi"
-
-# Check whether --with-dahdi was given.
-if test "${with_dahdi+set}" = set; then :
- withval=$with_dahdi;
- case
Re: [asterisk-dev] Digium TE820 on BSD: bunch of missed interrupts
W dniu 2014-05-16 20:32, Łukasz Wójcik pisze:
On 05/15/2014 07:52, Russ Meyerriecks wrote:
On Wed, May 14, 2014 at 1:40 PM, Łukasz Wójcik mailto:lukasz.woj...@zoho.com>> wrote:
That's what I just did. It seems that irq handling routine takes
260-280ms during span setup. My measurements indicate that the most
time is being spent in '__t4_set_timing_source_auto()__'
This is curious. There is no blocking in that function and it's just a
small number of bit checks and two gpio writes.
(..)
Missed interrupt. Expected ident of 97 and got ident of 111
(..)
It might be helpful to see the full output of the kernel log while the
wct4xxp module is starting up.
Hello again, Russ
Please see the log attached.
Log lines starting with 'TICKS' is my addition. The whole interrupt
handler was divided into 11 points, at which number of 'ticks' is taken.
Clock ticks 1000x per second, so a single tick means 1ms.
The line is intended to show CPU ticks at those sampling points, how
many ticks it took to handle interrupt. 'samples taken' shows how many
of 11 sampling points were actually reached (it may be less than 11 if
certain code path was taken). All irq handler runs that take very long
to finish, seem to spend most time between sampling points:
5-6 and 9-10.
Sampling point 5. is located just before call to t4_prep_gen2().
Sampling point 6. is located just after call to __handle_leds().
(...)
4248 //5
4249 } else {
4250 t4_prep_gen2(wc);
4251 }
4252
4253 #endif
4254 t4_do_counters(wc);
4255 spin_lock(&wc->reglock);
4256 __handle_leds(wc);
4257 spin_unlock(&wc->reglock);
4258
4259 }
4260 //6
(...)
Sampling point 9. and 10. :
(...)
4304 //9
4306 if (unlikely(test_bit(T4_CHECK_TIMING, &wc->checkflag))) {
4307 __t4_set_timing_source_auto(wc);
4308 }
4309
4310 //10
(...)
NOTE that line numbers won't match your codebase, but given code blocks
should be easy to locate in irq handler routine (_t4_interrupt_gen2()).
Oh, and lines starting with "dahdi_iface(dahdi@TE8/X/Y/Z):" are FreeBSD
specific.
Thanks again,
-ŁW
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Digium TE820 on BSD: bunch of missed interrupts
Hello Russ, 2014-05-14 17:36, Russ Meyerriecks: On Wed, May 14, 2014 at 2:57 AM, Łukasz Wójcik mailto:lukasz.woj...@zoho.com>> wrote: I would appreciate any clues and suggestions on how to improve the latency situation. I'm unfamiliar with BSD driver development but here are a couple things I might check: - Ensure the interrupts are being acknowledged properly by the driver. If interrupts were left un-acknowledged, it could produce this scenario. Unless there's something device-specific that has to be done, everything seems to be in order in this resort. - Ensure all memory addresses are mapped properly regarding the descriptor ring. If memory addresses were incorrectly loaded to the card for the dring, it may cause similar issues. Hmm that's a good point, although I would expect some panics if that would be the case. I will certainly check that, however. - Time the irq handler to find it's running time. Linux has a tracer for this, maybe BSD does as well. (I think this is least likely, unless some BSD quirk is hanging up in the middle of the irq routine) That's what I just did. It seems that irq handling routine takes 260-280ms during span setup. My measurements indicate that the most time is being spent in '__t4_set_timing_source_auto()' which is only called from the interrupt handler when T4_CHECK_TIMING flag is set (which I guess happens only during span setup ?). After all spans are configured, interrupt handling time drops to average 1ms (min: < 1ms, max: 5ms), and that's where the driver first wants to bump latency up and where missed interrupt message starts to appear: (..) Missed interrupt. Expected ident of 97 and got ident of 111 (..) Another question I'd like to ask is: Assuming that 'status' contains whatever device status register holds, what does the check: (status & 0x2) mean ? Once again, thank you for your help Russ! Sincerely, -ŁW -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] Digium TE820 on BSD: bunch of missed interrupts
Hello there, I am developing custom DAHDI-based solution on FreeBSD. My work is based on already working DAHDI port by Max Khon, called dahdi-kmod26. I am using TE820 8-port Digium cards in HDLC mode. The problem I am observing is that starting from the very beginning (just after loading dahdi modules) latency bumps quickly up to it's max (127ms) and never goes down. After turning on debugging messages, I observe flood of Missed interrupt messages. My guess is that it is because interrupt handling routine takes too much time to complete. I made sure interrupts are not shared, but it did not change anything. Then I tried setting 'ms_per_irq' to 2,4,8 and 16. That did not change anything either. I do not have access to hardware manual, so I am unsure of how exactly interrupts handling should work in this case. I would appreciate any clues and suggestions on how to improve the latency situation. Also, could anyone explain what exactly 'rxident' is ? Sincerely, -LW -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
