Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
chan_capi error after update
4 views
Skip to first unread message
Andreas Longwitz
Feb 19, 2016, 4:40:16 AM2/19/16
to
Hi,
isdn4bsd + chan_capi works fine for years now, thanks !!
On machines running
FreeBSD 8.4-STABLE (LOSERVER) #2 r284338
with
ihfc0: <HFC-2BDS0 128K PCI ISDN adapter> port 0xbc00-0xbc07 mem
0xff532000-0xff5320ff irq 22 at device 1.0 on pci6
ihfc0: [ITHREAD]
ihfc0: Attaching I4B controller 0.
ihfc0: Creating /dev/ihfc0.X.
i4btel: 8 ISDN telephony interface device(s) attached
i4btrc: 64 ISDN trace device(s) attached
i4bctl: ISDN system control port attached
i4b: ISDN call control device attached
i4bisppp: 8 ISDN SyncPPP device(s) attached
there is a problem after updating software (without changing configuration)
asterisk18: 1.8.16.0 ---> 1.8.32.1
chan_capi: 2.0.3 ---> 2.0.14
libcapi: 2.0.1 ---> 2.0.2
isdn4bsd-kmod: 2.0.7 ---> 2.0.11
isdn4bsd-utils: 2.0.7 ---> 2.0.11
isdnd works fine, but chan_capi has a problem when asterisk starts:
[2016-02-18 17:16:51.477] VERBOSE[8810] chan_capi.c: [2016-02-18
17:16:51.477] == Reading config for ISDN
[2016-02-18 17:16:51.477] VERBOSE[8810] chan_capi.c: [2016-02-18
17:16:51.477] -- config entry 'ISDN' T=(4982871,isdn-in,2) C=[0,0]
E=(0,4,64) G=(1.000000/1.000000) H=(0)
[2016-02-18 17:16:51.477] ERROR[8810] chan_capi.c: CAPI error sending
CAPI_FACILITY_REQ {
header {
WORD wLen = 0x0000
WORD wApp = 0xffff
WORD wCmd = 0x8468
WORD wNum = 0x0001
DWORD dwCid = 0x00000000
}
data {
WORD wSelector = 0x0003
STRUCT Param.ptr = 0x03 '?', 0x00 '?', 0x00 '?', 0x00 '?'.
}
}
(NCCI=0) (error=0x1101)
[2016-02-18 17:16:51.477] NOTICE[8810] chan_capi.c: could not send
FACILITY REQUEST!
[2016-02-18 17:16:51.477] VERBOSE[8810] chan_capi.c: [2016-02-18
17:16:51.477] -- CAPI controller 0 supports: [DTMF][echo
cancellation][supplementary]
[2016-02-18 17:16:51.477] ERROR[8810] chan_capi.c: CAPI error sending
CAPI_LISTEN_REQ {
header {
WORD wLen = 0x0000
WORD wApp = 0xffff
WORD wCmd = 0x8462
WORD wNum = 0x0002
DWORD dwCid = 0x00000000
}
data {
DWORD dwInfoMask = 0x0000ffff
DWORD dwCipMask1 = 0x1fff03ff
DWORD dwCipMask2 = 0x00000000
STRUCT src_telno.ptr = (empty)
STRUCT src_subaddr.ptr = (empty)
}
}
(NCCI=0) (error=0x1101)
[2016-02-18 17:16:51.477] ERROR[8810] chan_capi.c: Unable to listen on
controller=0!
[2016-02-18 17:16:51.478] VERBOSE[8810] channel.c: [2016-02-18
17:16:51.478] == Registered channel type 'CAPI' (Common ISDN API 2.0
Driver 2.0.14)
[2016-02-18 17:16:51.478] VERBOSE[8810] pbx.c: [2016-02-18 17:16:51.478]
== Registered application 'capiCommand'
[2016-02-18 17:16:51.478] ERROR[8810] lock.c: chan_capi.c line 1237
(capi_application_usleep): mutex '&p_app->lock' freed more times than
we've locked!
[2016-02-18 17:16:51.478] VERBOSE[8810] loader.c: [2016-02-18
17:16:51.478] chan_capi.so => (Common ISDN API 2.0 Driver 2.0.14)
[2016-02-18 17:16:51.478] ERROR[8810] lock.c: chan_capi.c line 1237
(capi_application_usleep): Error releasing mutex: Operation not permitted
Some seconds later:
[2016-02-18 17:16:51.527] VERBOSE[8810] asterisk.c: [2016-02-18
17:16:51.527] Asterisk Ready.
[2016-02-18 17:16:53.873] VERBOSE[8810] chan_capi.c: [2016-02-18
17:16:53.873] -- CAPI controller 0 supports: [DTMF][echo
cancellation][supplementary]
[2016-02-18 17:16:55.258] VERBOSE[8810] chan_capi.c: [2016-02-18
17:16:55.258] -- listening on controller=0, cip_mask=0x1fff03ff
[2016-02-18 17:16:55.258] WARNING[8810] chan_capi.c: CAPI application
was restarted
Any ideas ?
Regards,
Andreas Longwitz
_______________________________________________
freebs...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-isdn
To unsubscribe, send any mail to "freebsd-isdn...@freebsd.org"
isdn4bsd + chan_capi works fine for years now, thanks !!
On machines running
FreeBSD 8.4-STABLE (LOSERVER) #2 r284338
with
ihfc0: <HFC-2BDS0 128K PCI ISDN adapter> port 0xbc00-0xbc07 mem
0xff532000-0xff5320ff irq 22 at device 1.0 on pci6
ihfc0: [ITHREAD]
ihfc0: Attaching I4B controller 0.
ihfc0: Creating /dev/ihfc0.X.
i4btel: 8 ISDN telephony interface device(s) attached
i4btrc: 64 ISDN trace device(s) attached
i4bctl: ISDN system control port attached
i4b: ISDN call control device attached
i4bisppp: 8 ISDN SyncPPP device(s) attached
there is a problem after updating software (without changing configuration)
asterisk18: 1.8.16.0 ---> 1.8.32.1
chan_capi: 2.0.3 ---> 2.0.14
libcapi: 2.0.1 ---> 2.0.2
isdn4bsd-kmod: 2.0.7 ---> 2.0.11
isdn4bsd-utils: 2.0.7 ---> 2.0.11
isdnd works fine, but chan_capi has a problem when asterisk starts:
[2016-02-18 17:16:51.477] VERBOSE[8810] chan_capi.c: [2016-02-18
17:16:51.477] == Reading config for ISDN
[2016-02-18 17:16:51.477] VERBOSE[8810] chan_capi.c: [2016-02-18
17:16:51.477] -- config entry 'ISDN' T=(4982871,isdn-in,2) C=[0,0]
E=(0,4,64) G=(1.000000/1.000000) H=(0)
[2016-02-18 17:16:51.477] ERROR[8810] chan_capi.c: CAPI error sending
CAPI_FACILITY_REQ {
header {
WORD wLen = 0x0000
WORD wApp = 0xffff
WORD wCmd = 0x8468
WORD wNum = 0x0001
DWORD dwCid = 0x00000000
}
data {
WORD wSelector = 0x0003
STRUCT Param.ptr = 0x03 '?', 0x00 '?', 0x00 '?', 0x00 '?'.
}
}
(NCCI=0) (error=0x1101)
[2016-02-18 17:16:51.477] NOTICE[8810] chan_capi.c: could not send
FACILITY REQUEST!
[2016-02-18 17:16:51.477] VERBOSE[8810] chan_capi.c: [2016-02-18
17:16:51.477] -- CAPI controller 0 supports: [DTMF][echo
cancellation][supplementary]
[2016-02-18 17:16:51.477] ERROR[8810] chan_capi.c: CAPI error sending
CAPI_LISTEN_REQ {
header {
WORD wLen = 0x0000
WORD wApp = 0xffff
WORD wCmd = 0x8462
WORD wNum = 0x0002
DWORD dwCid = 0x00000000
}
data {
DWORD dwInfoMask = 0x0000ffff
DWORD dwCipMask1 = 0x1fff03ff
DWORD dwCipMask2 = 0x00000000
STRUCT src_telno.ptr = (empty)
STRUCT src_subaddr.ptr = (empty)
}
}
(NCCI=0) (error=0x1101)
[2016-02-18 17:16:51.477] ERROR[8810] chan_capi.c: Unable to listen on
controller=0!
[2016-02-18 17:16:51.478] VERBOSE[8810] channel.c: [2016-02-18
17:16:51.478] == Registered channel type 'CAPI' (Common ISDN API 2.0
Driver 2.0.14)
[2016-02-18 17:16:51.478] VERBOSE[8810] pbx.c: [2016-02-18 17:16:51.478]
== Registered application 'capiCommand'
[2016-02-18 17:16:51.478] ERROR[8810] lock.c: chan_capi.c line 1237
(capi_application_usleep): mutex '&p_app->lock' freed more times than
we've locked!
[2016-02-18 17:16:51.478] VERBOSE[8810] loader.c: [2016-02-18
17:16:51.478] chan_capi.so => (Common ISDN API 2.0 Driver 2.0.14)
[2016-02-18 17:16:51.478] ERROR[8810] lock.c: chan_capi.c line 1237
(capi_application_usleep): Error releasing mutex: Operation not permitted
Some seconds later:
[2016-02-18 17:16:51.527] VERBOSE[8810] asterisk.c: [2016-02-18
17:16:51.527] Asterisk Ready.
[2016-02-18 17:16:53.873] VERBOSE[8810] chan_capi.c: [2016-02-18
17:16:53.873] -- CAPI controller 0 supports: [DTMF][echo
cancellation][supplementary]
[2016-02-18 17:16:55.258] VERBOSE[8810] chan_capi.c: [2016-02-18
17:16:55.258] -- listening on controller=0, cip_mask=0x1fff03ff
[2016-02-18 17:16:55.258] WARNING[8810] chan_capi.c: CAPI application
was restarted
Any ideas ?
Regards,
Andreas Longwitz
_______________________________________________
freebs...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-isdn
To unsubscribe, send any mail to "freebsd-isdn...@freebsd.org"
Hans Petter Selasky
Feb 19, 2016, 11:44:50 AM2/19/16
to
Did you set the correct permissions for /dev/capi20. Maybe Asterisk is
running it as a different user?
--HPS
Andreas Longwitz
Feb 19, 2016, 3:52:37 PM2/19/16
to
thanks for answer.
> Did you set the correct permissions for /dev/capi20. Maybe Asterisk is
> running it as a different user?
>
> --HPS
Yes, in my startup script I have
chown asterisk:wheel /dev/capi20
and
ls -l /dev/capi20
gives
crw------- 1 asterisk wheel 0, 162 18 Feb 17:16 /dev/capi20
Andreas Longwitz
> Did you set the correct permissions for /dev/capi20. Maybe Asterisk is
> running it as a different user?
>
> --HPS
chown asterisk:wheel /dev/capi20
and
ls -l /dev/capi20
gives
crw------- 1 asterisk wheel 0, 162 18 Feb 17:16 /dev/capi20
Andreas Longwitz
Hans Petter Selasky
Feb 20, 2016, 4:50:00 AM2/20/16
to
On 02/19/16 17:47, Hans Petter Selasky wrote:
> [2016-02-18 17:16:51.478] VERBOSE[8810] pbx.c: [2016-02-18 17:16:51.478]
> == Registered application 'capiCommand'
> [2016-02-18 17:16:51.478] ERROR[8810] lock.c: chan_capi.c line 1237
> (capi_application_usleep): mutex '&p_app->lock' freed more times than
> we've locked!
Hi,
> [2016-02-18 17:16:51.478] VERBOSE[8810] pbx.c: [2016-02-18 17:16:51.478]
> == Registered application 'capiCommand'
> [2016-02-18 17:16:51.478] ERROR[8810] lock.c: chan_capi.c line 1237
> (capi_application_usleep): mutex '&p_app->lock' freed more times than
> we've locked!
I found a minor bug there. I've made v2.0.15 available. Just SVN up and
install the port. I've also fixed a build issue with later versions of
asterisk, that it needs the "-fblocks" CFLAG when compiling.
I'm currently using the exact same setup with Asterisk 11.x without any
such problems.
--HPS
Andreas Longwitz
Feb 20, 2016, 9:13:58 AM2/20/16
to
Hi,
thanks for investigating in this problem !
> I found a minor bug there. I've made v2.0.15 available. Just SVN up and
> install the port. I've also fixed a build issue with later versions of
> asterisk, that it needs the "-fblocks" CFLAG when compiling.
>
> I'm currently using the exact same setup with Asterisk 11.x without any
> such problems.
OK, at the moment I am a little bit late with versions because I use a
consistent portstree 2014Q4 running poudriere on all of my servers.
>
> --HPS
After update to chan_capi 2.0.15 (without the -fblocks CFLAG, because
the compiler does not know in V8: cc1: error: unrecognized command line
option "-fblocks") the problem has not gone away. But the order of the
messages is a little bit different now:
[2016-02-20 14:55:37.071] VERBOSE[21261] config.c: [2016-02-20
14:55:37.071] == Parsing '/usr/local/etc/asterisk/capi.conf':
[2016-02-20 14:55:37
.072] VERBOSE[21261] config.c: [2016-02-20 14:55:37.072] == Found
[2016-02-20 14:55:37.072] VERBOSE[21261] chan_capi.c: [2016-02-20
14:55:37.072] == Reading config for ISDN
[2016-02-20 14:55:37.072] VERBOSE[21261] chan_capi.c: [2016-02-20
14:55:37.072] -- config entry 'ISDN' T=(4982871,isdn-in,2) C=[0,0]
E=(0,4,64)
G=(1.000000/1.000000) H=(0)
[2016-02-20 14:55:37.073] ERROR[21261] chan_capi.c: CAPI error sending
FACILITY REQUEST!
[2016-02-20 14:55:37.073] VERBOSE[21261] chan_capi.c: [2016-02-20
14:55:37.073] -- CAPI controller 0 supports: [DTMF][echo
cancellation][supplementary]
[2016-02-20 14:55:37.073] ERROR[21261] chan_capi.c: CAPI error sending
controller=0!
[2016-02-20 14:55:37.074] VERBOSE[21261] channel.c: [2016-02-20
14:55:37.074] == Registered channel type 'CAPI' (Common ISDN API 2.0
Driver 2.0.1
5)
[2016-02-20 14:55:37.074] VERBOSE[21261] pbx.c: [2016-02-20
14:55:37.074] == Registered application 'capiCommand'
[2016-02-20 14:55:37.074] VERBOSE[21261] loader.c: [2016-02-20
14:55:37.074] chan_capi.so => (Common ISDN API 2.0 Driver 2.0.15)
Some seconds later:
[2016-02-20 14:55:37.125] VERBOSE[21261] asterisk.c: [2016-02-20
14:55:37.125] Asterisk Ready.
[2016-02-20 14:55:39.469] VERBOSE[21261] chan_capi.c: [2016-02-20
14:55:39.469] -- CAPI controller 0 supports: [DTMF][echo
cancellation][supplementary]
[2016-02-20 14:55:40.854] VERBOSE[21261] chan_capi.c: [2016-02-20
14:55:40.854] -- listening on controller=0, cip_mask=0x1fff03ff
[2016-02-20 14:55:40.855] WARNING[21261] chan_capi.c: CAPI application
was restarted
[2016-02-20 14:55:40.855] ERROR[21261] lock.c: chan_capi.c line 2586
(capi_check_wait_get_cmsg): mutex '&p_app->lock' freed more times than
we've locked!
[2016-02-20 14:55:40.855] ERROR[21261] lock.c: chan_capi.c line 2586
(capi_check_wait_get_cmsg): Error releasing mutex: Operation not permitted
Regards
Andreas Longwitz
thanks for investigating in this problem !
> I found a minor bug there. I've made v2.0.15 available. Just SVN up and
> install the port. I've also fixed a build issue with later versions of
> asterisk, that it needs the "-fblocks" CFLAG when compiling.
>
> I'm currently using the exact same setup with Asterisk 11.x without any
> such problems.
consistent portstree 2014Q4 running poudriere on all of my servers.
>
> --HPS
After update to chan_capi 2.0.15 (without the -fblocks CFLAG, because
the compiler does not know in V8: cc1: error: unrecognized command line
option "-fblocks") the problem has not gone away. But the order of the
messages is a little bit different now:
[2016-02-20 14:55:37.071] VERBOSE[21261] config.c: [2016-02-20
14:55:37.071] == Parsing '/usr/local/etc/asterisk/capi.conf':
[2016-02-20 14:55:37
.072] VERBOSE[21261] config.c: [2016-02-20 14:55:37.072] == Found
[2016-02-20 14:55:37.072] VERBOSE[21261] chan_capi.c: [2016-02-20
14:55:37.072] == Reading config for ISDN
[2016-02-20 14:55:37.072] VERBOSE[21261] chan_capi.c: [2016-02-20
14:55:37.072] -- config entry 'ISDN' T=(4982871,isdn-in,2) C=[0,0]
E=(0,4,64)
G=(1.000000/1.000000) H=(0)
[2016-02-20 14:55:37.073] ERROR[21261] chan_capi.c: CAPI error sending
CAPI_FACILITY_REQ {
header {
WORD wLen = 0x0000
WORD wApp = 0xffff
WORD wCmd = 0x8468
WORD wNum = 0x0001
DWORD dwCid = 0x00000000
}
data {
WORD wSelector = 0x0003
STRUCT Param.ptr = 0x03 '?', 0x00 '?', 0x00 '?', 0x00 '?'.
}
}
(NCCI=0) (error=0x1101)
[2016-02-20 14:55:37.073] NOTICE[21261] chan_capi.c: could not send
header {
WORD wLen = 0x0000
WORD wApp = 0xffff
WORD wCmd = 0x8468
WORD wNum = 0x0001
DWORD dwCid = 0x00000000
}
data {
WORD wSelector = 0x0003
STRUCT Param.ptr = 0x03 '?', 0x00 '?', 0x00 '?', 0x00 '?'.
}
}
(NCCI=0) (error=0x1101)
FACILITY REQUEST!
[2016-02-20 14:55:37.073] VERBOSE[21261] chan_capi.c: [2016-02-20
14:55:37.073] -- CAPI controller 0 supports: [DTMF][echo
cancellation][supplementary]
[2016-02-20 14:55:37.073] ERROR[21261] chan_capi.c: CAPI error sending
CAPI_LISTEN_REQ {
header {
WORD wLen = 0x0000
WORD wApp = 0xffff
WORD wCmd = 0x8462
WORD wNum = 0x0002
DWORD dwCid = 0x00000000
}
data {
DWORD dwInfoMask = 0x0000ffff
DWORD dwCipMask1 = 0x1fff03ff
DWORD dwCipMask2 = 0x00000000
STRUCT src_telno.ptr = (empty)
STRUCT src_subaddr.ptr = (empty)
}
}
(NCCI=0) (error=0x1101)
[2016-02-20 14:55:37.073] ERROR[21261] chan_capi.c: Unable to listen on
header {
WORD wLen = 0x0000
WORD wApp = 0xffff
WORD wCmd = 0x8462
WORD wNum = 0x0002
DWORD dwCid = 0x00000000
}
data {
DWORD dwInfoMask = 0x0000ffff
DWORD dwCipMask1 = 0x1fff03ff
DWORD dwCipMask2 = 0x00000000
STRUCT src_telno.ptr = (empty)
STRUCT src_subaddr.ptr = (empty)
}
}
(NCCI=0) (error=0x1101)
controller=0!
[2016-02-20 14:55:37.074] VERBOSE[21261] channel.c: [2016-02-20
14:55:37.074] == Registered channel type 'CAPI' (Common ISDN API 2.0
Driver 2.0.1
5)
[2016-02-20 14:55:37.074] VERBOSE[21261] pbx.c: [2016-02-20
14:55:37.074] == Registered application 'capiCommand'
[2016-02-20 14:55:37.074] VERBOSE[21261] loader.c: [2016-02-20
14:55:37.074] chan_capi.so => (Common ISDN API 2.0 Driver 2.0.15)
Some seconds later:
[2016-02-20 14:55:37.125] VERBOSE[21261] asterisk.c: [2016-02-20
14:55:37.125] Asterisk Ready.
[2016-02-20 14:55:39.469] VERBOSE[21261] chan_capi.c: [2016-02-20
14:55:39.469] -- CAPI controller 0 supports: [DTMF][echo
cancellation][supplementary]
[2016-02-20 14:55:40.854] VERBOSE[21261] chan_capi.c: [2016-02-20
14:55:40.854] -- listening on controller=0, cip_mask=0x1fff03ff
[2016-02-20 14:55:40.855] WARNING[21261] chan_capi.c: CAPI application
was restarted
[2016-02-20 14:55:40.855] ERROR[21261] lock.c: chan_capi.c line 2586
(capi_check_wait_get_cmsg): mutex '&p_app->lock' freed more times than
we've locked!
[2016-02-20 14:55:40.855] ERROR[21261] lock.c: chan_capi.c line 2586
(capi_check_wait_get_cmsg): Error releasing mutex: Operation not permitted
Regards
Andreas Longwitz
Hans Petter Selasky
Feb 20, 2016, 9:55:59 AM2/20/16
to
On 02/20/16 15:13, Andreas Longwitz wrote:
> Hi,
> thanks for investigating in this problem !
>
>> I found a minor bug there. I've made v2.0.15 available. Just SVN up and
>> install the port. I've also fixed a build issue with later versions of
>> asterisk, that it needs the "-fblocks" CFLAG when compiling.
>>
>> I'm currently using the exact same setup with Asterisk 11.x without any
>> such problems.
> OK, at the moment I am a little bit late with versions because I use a
> consistent portstree 2014Q4 running poudriere on all of my servers.
>
>>
>> --HPS
>
> After update to chan_capi 2.0.15 (without the -fblocks CFLAG, because
> the compiler does not know in V8: cc1: error: unrecognized command line
> option "-fblocks") the problem has not gone away. But the order of the
> messages is a little bit different now:
>
Try to update once more.
> Hi,
> thanks for investigating in this problem !
>
>> I found a minor bug there. I've made v2.0.15 available. Just SVN up and
>> install the port. I've also fixed a build issue with later versions of
>> asterisk, that it needs the "-fblocks" CFLAG when compiling.
>>
>> I'm currently using the exact same setup with Asterisk 11.x without any
>> such problems.
> OK, at the moment I am a little bit late with versions because I use a
> consistent portstree 2014Q4 running poudriere on all of my servers.
>
>>
>> --HPS
>
> After update to chan_capi 2.0.15 (without the -fblocks CFLAG, because
> the compiler does not know in V8: cc1: error: unrecognized command line
> option "-fblocks") the problem has not gone away. But the order of the
> messages is a little bit different now:
>
--HPS
Hans Petter Selasky
Feb 20, 2016, 10:12:57 AM2/20/16
to
Hi,
Does the output from:
capi info
make sense?
Does the output from:
capi info
make sense?
Andreas Longwitz
Feb 20, 2016, 11:24:18 AM2/20/16
to
Hi,
> Try to update once more.
Done, update to chan_capi 2.0.16, same result as in 2.0.15, only the two
last ERROR messages "lock.c: chan_capi.c line 2586" are gone. Your check
for asterisk V11 failed because I have the file ast_version.h in
asterisk 1.8 too.
> Does the output from:
> capi info
> make sense?
I think yes, this is my capi.conf:
[general]
language=de
nationalprefix=0
internationalprefix=00
rxgain=1.0
txgain=1.0
alaw=yes
digit_timeout=1
ton2digit=1
[ISDN]
ntmode=no
isdnmode=msn
incomingmsn=4982871
defaultcid=4982871
controller=0
devices=2
group=1
accountcode=
context=isdn-in
holdtype=local
-> asterisk -r
[Feb 20 17:05:41] Asterisk 1.8.32.1, Copyright (C) 1999 - 2013 Digium,
Inc. and others.
Created by Mark Spencer <mark...@digium.com>
Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty'
for details.
This is free software, with components licensed under the GNU General Public
License version 2 and other licenses; you are welcome to redistribute it
under
certain conditions. Type 'core show license' for details.
=========================================================================
[Feb 20 17:05:41] Connected to Asterisk 1.8.32.1 currently running on
loserver (pid = 28258)
Verbosity is at least 5
Core debug is at least 3
[2016-02-20 17:05:41.500] -- Remote UNIX connection
loserver*CLI> capi info
CAPI thread [0x0] {
Application ID : 0x00000000
Application uptime : 0x0000003b seconds
Backend : capi20 @ localhost
Call descriptor statistics:
allocation count : 0x00000000 call descriptors
free count : 0x00000000 call descriptors
in memory count : 0x00000000 call descriptors
in use count : 0x00000000 call descriptors
record allocation rate : 0x0000 calls/second
limit allocation rate : 0x0010 calls/second
Currently active calls:
channel name, source->destination, call ID, in/out
}
Config entry 'ISDN' {
b_channels_curr : 2 call descriptor(s) free
b_channels_max : 2 call descriptor(s) total
}
Andreas Longwitz
> Try to update once more.
last ERROR messages "lock.c: chan_capi.c line 2586" are gone. Your check
for asterisk V11 failed because I have the file ast_version.h in
asterisk 1.8 too.
> Does the output from:
> capi info
> make sense?
[general]
language=de
nationalprefix=0
internationalprefix=00
rxgain=1.0
txgain=1.0
alaw=yes
digit_timeout=1
ton2digit=1
[ISDN]
ntmode=no
isdnmode=msn
incomingmsn=4982871
defaultcid=4982871
controller=0
devices=2
group=1
accountcode=
context=isdn-in
holdtype=local
-> asterisk -r
[Feb 20 17:05:41] Asterisk 1.8.32.1, Copyright (C) 1999 - 2013 Digium,
Inc. and others.
Created by Mark Spencer <mark...@digium.com>
Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty'
for details.
This is free software, with components licensed under the GNU General Public
License version 2 and other licenses; you are welcome to redistribute it
under
certain conditions. Type 'core show license' for details.
=========================================================================
[Feb 20 17:05:41] Connected to Asterisk 1.8.32.1 currently running on
loserver (pid = 28258)
Verbosity is at least 5
Core debug is at least 3
[2016-02-20 17:05:41.500] -- Remote UNIX connection
loserver*CLI> capi info
CAPI thread [0x0] {
Application ID : 0x00000000
Application uptime : 0x0000003b seconds
Backend : capi20 @ localhost
Call descriptor statistics:
allocation count : 0x00000000 call descriptors
free count : 0x00000000 call descriptors
in memory count : 0x00000000 call descriptors
in use count : 0x00000000 call descriptors
record allocation rate : 0x0000 calls/second
limit allocation rate : 0x0010 calls/second
Currently active calls:
channel name, source->destination, call ID, in/out
}
Config entry 'ISDN' {
b_channels_curr : 2 call descriptor(s) free
b_channels_max : 2 call descriptor(s) total
}
Andreas Longwitz
Hans Petter Selasky
Feb 20, 2016, 11:35:09 AM2/20/16
to
On 02/20/16 17:24, Andreas Longwitz wrote:
> Hi,
>
>> Try to update once more.
>
> Done, update to chan_capi 2.0.16, same result as in 2.0.15, only the two
> last ERROR messages "lock.c: chan_capi.c line 2586" are gone. Your check
> for asterisk V11 failed because I have the file ast_version.h in
> asterisk 1.8 too.
>
>
> Hi,
>
>> Try to update once more.
>
> Done, update to chan_capi 2.0.16, same result as in 2.0.15, only the two
> last ERROR messages "lock.c: chan_capi.c line 2586" are gone. Your check
> for asterisk V11 failed because I have the file ast_version.h in
> asterisk 1.8 too.
>
>
Looks good to me. What happens when you try to dial IN/OUT. Nothing works?
And did you try "capitest" to make a CAPI test call?
Can you describe a bit more what is not working?
--HPS
Andreas Longwitz
Feb 21, 2016, 5:55:40 PM2/21/16
to
Hi,
> Looks good to me. What happens when you try to dial IN/OUT. Nothing works?
> And did you try "capitest" to make a CAPI test call?
> Can you describe a bit more what is not working?
>
> --HPS
On first dial OUT asterisk crashed with core dump and therefore I first
> Looks good to me. What happens when you try to dial IN/OUT. Nothing works?
> And did you try "capitest" to make a CAPI test call?
> Can you describe a bit more what is not working?
>
> --HPS
tried to get rid of the messages
ERROR[988] chan_capi.c: CAPI error sending CAPI_FACILITY_REQ
In the meantime I have inspected the core dumps and found the crash
happens in the library libexecinfo.so.1, which is activated by asterisk
because I have
ASTCFLAGS+=-DDEBUG_THREADS -DBETTER_BACKTRACES -DNO_OPTIMIZE
in the configure step. Then I found PR/193610 which includes your
comment to the compiler flag "-fno-omit-frame-pointer". After adding
this flag to the asterisk18 Makefile the dumps are gone and on my
(small) test machine everything works as expected.
Maybe it is better to use this flag for chan_capi too ?
--
Andreas Longwitz
Hans Petter Selasky
Feb 22, 2016, 1:51:46 AM2/22/16
to
On 02/21/16 23:55, Andreas Longwitz wrote:
> Hi,
>
>
>> Looks good to me. What happens when you try to dial IN/OUT. Nothing works?
>> And did you try "capitest" to make a CAPI test call?
>> Can you describe a bit more what is not working?
>>
>> --HPS
>
> On first dial OUT asterisk crashed with core dump and therefore I first
> tried to get rid of the messages
>
> ERROR[988] chan_capi.c: CAPI error sending CAPI_FACILITY_REQ
>
> In the meantime I have inspected the core dumps and found the crash
> happens in the library libexecinfo.so.1, which is activated by asterisk
> because I have
>
> ASTCFLAGS+=-DDEBUG_THREADS -DBETTER_BACKTRACES -DNO_OPTIMIZE
>
> in the configure step. Then I found PR/193610 which includes your
> comment to the compiler flag "-fno-omit-frame-pointer". After adding
> this flag to the asterisk18 Makefile the dumps are gone and on my
> (small) test machine everything works as expected.
>
> Maybe it is better to use this flag for chan_capi too ?
>
Hi Andreas,
> Hi,
>
>
>> Looks good to me. What happens when you try to dial IN/OUT. Nothing works?
>> And did you try "capitest" to make a CAPI test call?
>> Can you describe a bit more what is not working?
>>
>> --HPS
>
> On first dial OUT asterisk crashed with core dump and therefore I first
> tried to get rid of the messages
>
> ERROR[988] chan_capi.c: CAPI error sending CAPI_FACILITY_REQ
>
> In the meantime I have inspected the core dumps and found the crash
> happens in the library libexecinfo.so.1, which is activated by asterisk
> because I have
>
> ASTCFLAGS+=-DDEBUG_THREADS -DBETTER_BACKTRACES -DNO_OPTIMIZE
>
> in the configure step. Then I found PR/193610 which includes your
> comment to the compiler flag "-fno-omit-frame-pointer". After adding
> this flag to the asterisk18 Makefile the dumps are gone and on my
> (small) test machine everything works as expected.
>
> Maybe it is better to use this flag for chan_capi too ?
>
I've now created version 2.0.17 of chan_capi and that also includes an
option to use clang to compile it, which supports the -fblocks argument.
I think 8.4-stable has the clang compiler?
Thank you!
--HPS
Andreas Longwitz
Feb 22, 2016, 3:39:08 AM2/22/16
to
Hi Hans,
>> because I have
>>
>> ASTCFLAGS+=-DDEBUG_THREADS -DBETTER_BACKTRACES -DNO_OPTIMIZE
>>
>> in the configure step. Then I found PR/193610 which includes your
>> comment to the compiler flag "-fno-omit-frame-pointer". After adding
>> this flag to the asterisk18 Makefile the dumps are gone and on my
>> (small) test machine everything works as expected.
>>
>> Maybe it is better to use this flag for chan_capi too ?
>>
>
from from port branch 2014Q4 has the entry "USE_GCC=YES" in his Makefile
independent of OS version.
--
Andreas Longwitz
>> because I have
>>
>> ASTCFLAGS+=-DDEBUG_THREADS -DBETTER_BACKTRACES -DNO_OPTIMIZE
>>
>> in the configure step. Then I found PR/193610 which includes your
>> comment to the compiler flag "-fno-omit-frame-pointer". After adding
>> this flag to the asterisk18 Makefile the dumps are gone and on my
>> (small) test machine everything works as expected.
>>
>> Maybe it is better to use this flag for chan_capi too ?
>>
>
> I've now created version 2.0.17 of chan_capi and that also includes an
> option to use clang to compile it, which supports the -fblocks argument.
> I think 8.4-stable has the clang compiler?
No, I use FreeBSD 8 (no clang) and 10 (has clang). My asterisk version
> option to use clang to compile it, which supports the -fblocks argument.
> I think 8.4-stable has the clang compiler?
from from port branch 2014Q4 has the entry "USE_GCC=YES" in his Makefile
independent of OS version.
--
Andreas Longwitz
Julian H. Stacey
Feb 22, 2016, 5:16:41 AM2/22/16
to
Andreas Longwitz wrote:
> Hi Hans,
>
> >> because I have
> >>
> >> ASTCFLAGS+=-DDEBUG_THREADS -DBETTER_BACKTRACES -DNO_OPTIMIZE
> >>
> >> in the configure step. Then I found PR/193610 which includes your
> >> comment to the compiler flag "-fno-omit-frame-pointer". After adding
> >> this flag to the asterisk18 Makefile the dumps are gone and on my
> >> (small) test machine everything works as expected.
> >>
> >> Maybe it is better to use this flag for chan_capi too ?
> >>
> >
> > I've now created version 2.0.17 of chan_capi and that also includes an
> > option to use clang to compile it, which supports the -fblocks argument.
> > I think 8.4-stable has the clang compiler?
>
> No, I use FreeBSD 8 (no clang) and 10 (has clang). My asterisk version
> from from port branch 2014Q4 has the entry "USE_GCC=YES" in his Makefile
> independent of OS version.
>
>
> --
> Andreas Longwitz
In case it might help anyone, I looked on my laptop with 4 MBR slices with
> Hi Hans,
>
> >> because I have
> >>
> >> ASTCFLAGS+=-DDEBUG_THREADS -DBETTER_BACKTRACES -DNO_OPTIMIZE
> >>
> >> in the configure step. Then I found PR/193610 which includes your
> >> comment to the compiler flag "-fno-omit-frame-pointer". After adding
> >> this flag to the asterisk18 Makefile the dumps are gone and on my
> >> (small) test machine everything works as expected.
> >>
> >> Maybe it is better to use this flag for chan_capi too ?
> >>
> >
> > I've now created version 2.0.17 of chan_capi and that also includes an
> > option to use clang to compile it, which supports the -fblocks argument.
> > I think 8.4-stable has the clang compiler?
>
> No, I use FreeBSD 8 (no clang) and 10 (has clang). My asterisk version
> from from port branch 2014Q4 has the entry "USE_GCC=YES" in his Makefile
> independent of OS version.
>
>
> --
> Andreas Longwitz
latest minor releases of each major, (3 releases not stables though)
S1 8.4-RELEASE
S3 9.3-RELEASE
S2 10.2-RELEASE
S4 11.0-CURRENT
chroot /s1
head -1 /etc/motd
FreeBSD 8.4-RELEASE (LAPR.small) #0: Fri May 9 02:23:49 CEST 2014
which clang
/usr/local/bin/clang
clang -v
clang version 3.2 (tags/RELEASE_32/final)
Target: amd64-portbld-freebsd8.4
Thread model: posix
which cc
/usr/bin/cc
cc -v
Using built-in specs.
Target: amd64-undermydesk-freebsd
Configured with: FreeBSD/amd64 system compiler
Thread model: posix
gcc version 4.2.1 20070831 patched [FreeBSD]
------
head -1 /etc/motd
FreeBSD 9.3-RELEASE (LAPR.small) #1: Tue Nov 4 22:22:57 CET 2014
which clang
/usr/bin/clang
clang -v
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: x86_64-unknown-freebsd9.3
Thread model: posix
Selected GCC installation:
which cc
/usr/bin/cc
cc -v
Using built-in specs.
Target: amd64-undermydesk-freebsd
Configured with: FreeBSD/amd64 system compiler
Thread model: posix
gcc version 4.2.1 20070831 patched [FreeBSD]
------
head -1 /etc/motd
FreeBSD 10.2-RELEASE (LAPR.small) #0: Tue Jan 19 21:14:45 CET 2016
which clang
/usr/bin/clang
clang -v
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: x86_64-unknown-freebsd10.2
Thread model: posix
Selected GCC installation:
which cc
/usr/bin/cc
cc -v
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: x86_64-unknown-freebsd10.2
Thread model: posix
Selected GCC installation:
------
S4 Current:
head -1 /etc/motd
FreeBSD 11.0-CURRENT (GENERIC) #0 r295216M: Thu Feb 4 12:18:23 CET 2016
which clang
/usr/bin/clang
clang -v
FreeBSD clang version 3.7.1 (tags/RELEASE_371/final 255217) 20151225
Target: x86_64-unknown-freebsd11.0
Thread model: posix
which cc
/usr/bin/cc
cc -v
FreeBSD clang version 3.7.1 (tags/RELEASE_371/final 255217) 20151225
Target: x86_64-unknown-freebsd11.0
Thread model: posix
------
Cheers,
Julian
--
Julian Stacey, BSD Linux Unix Sys Eng Consultant Munich http://berklix.eu/jhs/
Mail plain text, No quoted-printable, HTML, base64, MS.doc.
Prefix old lines '> ' Reply below old, like play script. Break lines by 80.
Andreas Longwitz
Feb 23, 2016, 6:13:34 PM2/23/16
to
Hi Hans,
the message that bothered me was
ERROR[8810] chan_capi.c: CAPI error sending CAPI_FACILITY_REQ ...
with error code 0x1101 (= CAPI_ERROR_INVALID_APPLICATION_ID).
In chan_capi 2.0.3 the application was registered with capi20_register()
on startup direct from load_module() via capi_application_alloc(), that
worked fine.
In chan_capi 2.0.17 the application will be registered with
capi20_register() in the capi_do_monitor thread in function
capi_application_restart(). Therefore the main thread should wait until
registration is done. After introducing the following patch all error
messages on startup are gone:
--- chan_capi.c.orig 2016-02-20 15:55:36.000000000 +0100
+++ chan_capi.c 2016-02-23 21:38:15.144667154 +0100
@@ -8309,6 +8309,9 @@
*/
capi_application[0] = p_app;
+ /* wait until capi_do_monitor has called capi20_register() */
+ sleep(2);
+
cc_mutex_lock(&p_app->lock);
app_locked = 1;
--
Thanks again for help, with kindly regards
Andreas Longwitz
the message that bothered me was
ERROR[8810] chan_capi.c: CAPI error sending CAPI_FACILITY_REQ ...
with error code 0x1101 (= CAPI_ERROR_INVALID_APPLICATION_ID).
In chan_capi 2.0.3 the application was registered with capi20_register()
on startup direct from load_module() via capi_application_alloc(), that
worked fine.
In chan_capi 2.0.17 the application will be registered with
capi20_register() in the capi_do_monitor thread in function
capi_application_restart(). Therefore the main thread should wait until
registration is done. After introducing the following patch all error
messages on startup are gone:
--- chan_capi.c.orig 2016-02-20 15:55:36.000000000 +0100
+++ chan_capi.c 2016-02-23 21:38:15.144667154 +0100
@@ -8309,6 +8309,9 @@
*/
capi_application[0] = p_app;
+ /* wait until capi_do_monitor has called capi20_register() */
+ sleep(2);
+
cc_mutex_lock(&p_app->lock);
app_locked = 1;
--
Thanks again for help, with kindly regards
Andreas Longwitz
0 new messages