Re: [asterisk-users] asterisk 1.4 freezes with queues and iax after virtualization

2013-07-30 Thread Gareth Blades



On 29/07/13 18:12, samuel wrote:

there's no dahdi installed.

Following debugging the issue, it looks like the astdb file is broken. 
Whenever database show command is executed it loops over the same 
results. The file itself is around 225K but dumping its content via 
asterisk -rx 'database show' creates and endless file.


Is there any easy way to restore the database content?

Thanks a lot for the replies,
Samuel.

There is some information listed here :-
http://www.voip-info.org/wiki/view/Asterisk+database
Are you actually storing any data in there yourself? If not it would 
probably be a lot easier to just rename the file and restart asterisk 
and it should create a new clean file.



--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
  http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users


Re: [asterisk-users] using E1 PRI lines

2013-07-30 Thread Gareth Blades

On 30/07/13 05:35, Duncan Turnbull wrote:
E1 PSTN line interfaces are either unbalanced 75 ohm( and used to use 
BNC connectors ) or a 120 ohm balanced twisted pair.


The other standard is T1 and digium cards can let you choose between 
T1  E1 and definitely do 120 ohm


Telco's will usually provide 120ohm twisted pair interfaces as it 
travels further and has less interference from noise.


120ohm is the standard for E1 RJ45 while T1 normally has a 100ohm 
impedance. The E1/T1 jumper on the Digium cards is actually changing the 
impedance.
BNC is 75ohm and if your telco provides these you need a balun panel to 
convert the impedance and the wiring to RJ45. e.g 
http://www.tekmos.co.uk/baluns/panel/rj45/rj45-balun-panel-16e1-coax-front-mount.shtml



--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
  http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users


Re: [asterisk-users] Connected Line presentation in 1.8.x upwards

2013-07-30 Thread Steve Davies
On 29 July 2013 16:55, Kevin Larsen kevin.lar...@pioneerballoon.com wrote:



 From:Steve Davies davies...@gmail.com
 To:Asterisk Users Mailing List - Non-Commercial Discussion 
 asterisk-users@lists.digium.com,
 Date:07/29/2013 10:53 AM
 Subject:[asterisk-users] Connected Line presentation in 1.8.x
 upwards
 Sent by:asterisk-users-boun...@lists.digium.com
 --



 Hi,

 I've searched the *asterisk.org* http://asterisk.org/ and voip-info
 wiki sites, but not found an answer that seems to match.

 Hopefully this is a simple question. COLP is working very well on our
 system - Unfortunately it is working a bit TOO well in some circumstances.
 We have some untrusted trunks. On these trunks, an initial CallerID can
 be used, but any redirected caller numbers, COLP updates etc are not safe
 to accept. Sadly I cannot find how to cause COLP updates to be ignored for
 a trunk.

 I need solutions for SIP, IAX and DAHDI, what options do I have? This
 applies to both in- and out-bound calls.

 Are there some variables that I can set just before dialling an outbound
 call, and immediately on receiving an inbound call to determine what the
 callerID values will be for the entire duration of the call? (ie. old-style
 pre-COLP behaviour for specific trunks)

 Thanks for any pointers.

 Regards,
 Steve



 I believe what you are looking for in Dial is the 'I' option.



Ah. Many thanks.

It appears that the normally reliable voip-info wiki is out of date and
does not include that option. I should probably have just used Asterisk's
built-in documentation anyway :)

I guess on an inbound call I will have to conditionally set 'I' on the Dial
command based on the originating channel?

I will also have to go and check what affect this has when a call is SIP
REFER'ed as that might result in an asymmetric requirement. The internal
SIP handset will want updating, but the external SIP trunk call will not.

Regards,
Steve
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] RTP from pcap file

2013-07-30 Thread James Bensley
Hi all,

Many thanks to all for your helpful suggestions. I have compiled
rtpbreak. That is exactly what I needed, easily scripted with sox, for
auto conver PCAPs to WAV files.

Many thanks all, especially Gianluca!

Cheers,
James.

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users


[asterisk-users] Dahdi interface flapping

2013-07-30 Thread Andre Goree
Hello,

I seem to be having an issue with the configuration of my PRI on a new
asterisk server I've created to replace an old install that I have.
The card is Digium Wildcard TE133.  I continually get messages like
Primary D-Channel on span 1 down, rather irregularly:

[2013-07-29 17:31:39] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 up
[2013-07-29 17:31:39] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 up
[2013-07-29 17:32:52] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 down
[2013-07-29 17:32:52] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 down
[2013-07-29 17:33:16] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 up
[2013-07-29 17:33:16] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 up
[2013-07-29 17:33:35] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 down
[2013-07-29 17:33:35] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 down
[2013-07-29 17:33:50] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 up
[2013-07-29 17:33:50] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 up
[2013-07-29 17:34:05] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 down
[2013-07-29 17:34:05] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 down
[2013-07-29 17:34:32] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 up
[2013-07-29 17:34:32] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 up
[2013-07-29 17:35:37] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 down
[2013-07-29 17:35:37] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 down
[2013-07-29 17:36:02] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 up
[2013-07-29 17:36:02] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 up
[2013-07-29 17:36:21] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 down
[2013-07-29 17:36:21] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 down
[2013-07-29 17:36:36] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 up
[2013-07-29 17:36:36] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 up
[2013-07-29 17:36:51] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 down
[2013-07-29 17:36:51] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 down
[2013-07-29 17:37:35] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 up
[2013-07-29 17:37:35] VERBOSE[3621] sig_pri.c:   == Primary D-Channel
on span 1 up

I've searched a lot regarding this problem and it seems that this
might simply be a configuration error, or an issue with the cable
(consequently, I used a straight-through cable from the PRI to the
Dahdi interface...is this correct?  Or should I have used a crossover
cable?  I'm waiting for a technician from my telco to contact me and
I'm sure he'll be able to give insight).

I've posted the configs and the output of a 'pri debug' below.  Please
let me know if I should include anything else to help troubleshoot.
I've tried both a standalone conifguration as well as the Dahdi module
in FreePBX, results with the same error(s).

/etc/dahdi/system.conf:
span=1,0,0,ESF,B8ZS
bchan=1-23
dchan=24
loadzone=us

/etc/asterisk/chan_dahdi.conf
[channels]
language=en
busydetect=yes
busycount=10
usecallerid=yes
callwaiting=yes
usecallingpres=yes
threewaycalling=yes
transfer=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=no
echotraining=no
immediate=no
faxdetect=no
rxgain=0.0
txgain=0.0

[root@asterisk-master ~]# dahdi_scan
[1]
active=yes
alarms=OK
description=Wildcard TE133 Card 0
name=WCT13x/0
manufacturer=Digium
devicetype=Wildcard TE133
location=PCI Bus 01 Slot 01
basechan=1
totchans=24
irq=0
type=digital-T1
syncsrc=0
lbo=0 db (CSU)/0-133 feet (DSX-1)
coding_opts=B8ZS,AMI
framing_opts=ESF,D4
coding=B8ZS
framing=ESF


[root@asterisk-master ~]# cat /proc/interrupts
   CPU0   CPU1   CPU2   CPU3   CPU4   CPU5
  CPU6   CPU7
  0:124  0  0  0  0  0
 0  0   IO-APIC-edge  timer
  1:  2  0  0  0  0  0
 0  0   IO-APIC-edge  i8042
  3:  2  0  0  0  0  0
 0  0   IO-APIC-edge
  4:  2  0  0  0  0  0
 0  0   IO-APIC-edge
  8:  1  0  0  0  0  0
 0  0   IO-APIC-edge  rtc0
  9:  0  0  0  0  0  0
 0  0   IO-APIC-fasteoi   acpi
 10:  2  0  0  0  0  0
 0  0   IO-APIC-edge
 12:  4  0  0  0  0  0
 0  0   IO-APIC-edge  i8042
 16: 62  0  0  0  0  0
 0  0   IO-APIC-fasteoi   ehci_hcd:usb1
 23:  

Re: [asterisk-users] Dahdi interface flapping

2013-07-30 Thread Shaun Ruffell
On Tue, Jul 30, 2013 at 10:36:58AM -0400, Andre Goree wrote:
 
 I seem to be having an issue with the configuration of my PRI on a new
 asterisk server I've created to replace an old install that I have.
 The card is Digium Wildcard TE133.

In case you haven't, you should feel free to contact Digium customer
support with installation assistance with your new card.

http://www.digium.com/en/support/contact

 I've posted the configs and the output of a 'pri debug' below.  Please
 let me know if I should include anything else to help troubleshoot.
 I've tried both a standalone conifguration as well as the Dahdi module
 in FreePBX, results with the same error(s).
 
 /etc/dahdi/system.conf:
 span=1,0,0,ESF,B8ZS
 bchan=1-23
 dchan=24
 loadzone=us

I think the span line above is wrong. I think you want:

span=1,1,0,esf,b8zs

The second 1 indicates that the span should recover the clock from
the remote side (which should be your provider). However, normally
when you have the timing misconfigured like this you'll get HDLC
aborts, and not just the PRI going up and down.

So before looking into any more or contacting customer support, it
might be easy to change that one line and see if the behavior is
different.

-- 
Shaun Ruffell
Digium, Inc. | Linux Kernel Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com  www.asterisk.org

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users


Re: [asterisk-users] Dahdi interface flapping

2013-07-30 Thread Gareth Blades

On 30/07/13 15:36, Andre Goree wrote:

/etc/dahdi/system.conf:
span=1,0,0,ESF,B8ZS
bchan=1-23
dchan=24
loadzone=us

The first '0' in your span line above indicated that asterisk is 
generating the timing source. Normally the network operator provides 
timing so I would expect this to be a '1'. This can be the cause of the 
issue you are seeing as each end will be using a different clock which 
can be out of sync or drift causing data corruption, signalling errors 
and the d channel going down.


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
  http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users


Re: [asterisk-users] Dahdi interface flapping

2013-07-30 Thread Andre Goree
On Tue, Jul 30, 2013 at 10:56 AM, Shaun Ruffell sruff...@digium.com wrote:
 On Tue, Jul 30, 2013 at 10:36:58AM -0400, Andre Goree wrote:

 I seem to be having an issue with the configuration of my PRI on a new
 asterisk server I've created to replace an old install that I have.
 The card is Digium Wildcard TE133.

 In case you haven't, you should feel free to contact Digium customer
 support with installation assistance with your new card.

 http://www.digium.com/en/support/contact

 I've posted the configs and the output of a 'pri debug' below.  Please
 let me know if I should include anything else to help troubleshoot.
 I've tried both a standalone conifguration as well as the Dahdi module
 in FreePBX, results with the same error(s).

 /etc/dahdi/system.conf:
 span=1,0,0,ESF,B8ZS
 bchan=1-23
 dchan=24
 loadzone=us

 I think the span line above is wrong. I think you want:

 span=1,1,0,esf,b8zs

 The second 1 indicates that the span should recover the clock from
 the remote side (which should be your provider). However, normally
 when you have the timing misconfigured like this you'll get HDLC
 aborts, and not just the PRI going up and down.

 So before looking into any more or contacting customer support, it
 might be easy to change that one line and see if the behavior is
 different.

 --
 Shaun Ruffell
 Digium, Inc. | Linux Kernel Developer
 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
 Check us out at: www.digium.com  www.asterisk.org


Thanks for the suggestions.  I did have the following before, with
similar errors:

[root@asterisk-master dahdi]# cat system.conf.ag
loadzone = us
defaultzone=us
span=1,1,0,esf,b8zs
bchan=1-23
dchan=24

From everything I've read, what you say makes complete sense and in
fact I'm surprised that's changed (FreePBX's DAHDI module created the
current config -- i.e. the one I posted in my original email).  I'll
change that back and see if that makes a difference, but I'm pretty
sure I used the above configuration in a previous attempt with the
same results.

Also, I have indeed received the following messages prior to the
interface going down and these errors are what I was initially
researching:

[root@asterisk-master dahdi]# grep HDLC /var/log/asterisk/full
...
[2013-07-30 08:09:03] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC
Bad FCS (8) on D-channel of span 1
[2013-07-30 08:09:03] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC
Bad FCS (8) on D-channel of span 1
[2013-07-30 08:24:05] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC
Bad FCS (8) on D-channel of span 1
[2013-07-30 08:24:05] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC
Bad FCS (8) on D-channel of span 1
[2013-07-30 08:29:47] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC
Bad FCS (8) on D-channel of span 1
[2013-07-30 08:29:47] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC
Bad FCS (8) on D-channel of span 1
[2013-07-30 08:30:52] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC
Abort (6) on D-channel of span 1
[2013-07-30 08:30:52] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC
Abort (6) on D-channel of span 1
[2013-07-30 08:36:01] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC
Bad FCS (8) on D-channel of span 1
[2013-07-30 08:36:01] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC
Bad FCS (8) on D-channel of span 1
[2013-07-30 08:39:54] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC
Abort (6) on D-channel of span 1
[2013-07-30 08:39:54] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC
Abort (6) on D-channel of span 1

A lot of info I found while researching the above error mentioned
IRQ's, etc. and was one reason I posted the output of
/proc/interrupts, heh...but I'm pretty sure my issue is not one that
has to do with the IRQs.

Thanks for the suggestions!

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users


Re: [asterisk-users] Dahdi interface flapping

2013-07-30 Thread Shaun Ruffell
On Tue, Jul 30, 2013 at 11:13:55AM -0400, Andre Goree wrote:
 On Tue, Jul 30, 2013 at 10:56 AM, Shaun Ruffell sruff...@digium.com wrote:
  On Tue, Jul 30, 2013 at 10:36:58AM -0400, Andre Goree wrote:
 
   I've posted the configs and the output of a 'pri debug' below.  Please
   let me know if I should include anything else to help troubleshoot.
   I've tried both a standalone conifguration as well as the Dahdi module
   in FreePBX, results with the same error(s).
  
   /etc/dahdi/system.conf:
   span=1,0,0,ESF,B8ZS
   bchan=1-23
   dchan=24
   loadzone=us
 
  I think the span line above is wrong. I think you want:
 
  span=1,1,0,esf,b8zs
 
  The second 1 indicates that the span should recover the clock from
  the remote side (which should be your provider). However, normally
  when you have the timing misconfigured like this you'll get HDLC
  aborts, and not just the PRI going up and down.
 
  So before looking into any more or contacting customer support, it
  might be easy to change that one line and see if the behavior is
  different.
 
 Thanks for the suggestions.  I did have the following before, with
 similar errors:
 
 [root@asterisk-master dahdi]# cat system.conf.ag
 loadzone = us
 defaultzone=us
 span=1,1,0,esf,b8zs
 bchan=1-23
 dchan=24
 
 From everything I've read, what you say makes complete sense and in
 fact I'm surprised that's changed (FreePBX's DAHDI module created the
 current config -- i.e. the one I posted in my original email).  I'll
 change that back and see if that makes a difference, but I'm pretty
 sure I used the above configuration in a previous attempt with the
 same results.
 
 Also, I have indeed received the following messages prior to the
 interface going down and these errors are what I was initially
 researching:
 
 [root@asterisk-master dahdi]# grep HDLC /var/log/asterisk/full
 ...
 [2013-07-30 08:09:03] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Bad FCS 
 (8) on D-channel of span 1
 [2013-07-30 08:09:03] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Bad FCS 
 (8) on D-channel of span 1
 [2013-07-30 08:24:05] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Bad FCS 
 (8) on D-channel of span 1
 [2013-07-30 08:24:05] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Bad FCS 
 (8) on D-channel of span 1
 [2013-07-30 08:29:47] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Bad FCS 
 (8) on D-channel of span 1
 [2013-07-30 08:29:47] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Bad FCS 
 (8) on D-channel of span 1
 [2013-07-30 08:30:52] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Abort 
 (6) on D-channel of span 1
 [2013-07-30 08:30:52] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Abort 
 (6) on D-channel of span 1
 [2013-07-30 08:36:01] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Bad FCS 
 (8) on D-channel of span 1
 [2013-07-30 08:36:01] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Bad FCS 
 (8) on D-channel of span 1
 [2013-07-30 08:39:54] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Abort 
 (6) on D-channel of span 1
 [2013-07-30 08:39:54] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Abort 
 (6) on D-channel of span 1
 
 A lot of info I found while researching the above error mentioned
 IRQ's, etc. and was one reason I posted the output of
 /proc/interrupts, heh...but I'm pretty sure my issue is not one
 that has to do with the IRQs.

Ok, that makes more sense. One more thing that is quick and easy to
rule out in case there are interrupt handling issues is the check
and see if there are any error messages in dmesg related to the
driver.

  $ dmesg | grep wcte13xp

If something on the system is preventing the wcte13xp's interrupt
handler from running in a timely manner you'll see messages like:
Underrun detected by hardware.  Latency bumped to: xms

Typically I've seen this with systems that are configured to use
framebuffers, disks that are operating in combined mode, systems
with consoles on slow serial ports, or ill-behaved system management
interrupts.

A few of those messages about latency bumps are not a problem, and
it is the drivers way of accommodating systems with less than ideal
real time performance. However if you see any messages like Tried
to increase latency past buffer size then the driver will not be
able to accommodate the host system without some changes (if you're
lucky).

But...still...Digium's tech support I'm sure would be more than
happy to help you troubleshoot.

-- 
Shaun Ruffell
Digium, Inc. | Linux Kernel Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com  www.asterisk.org

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users


Re: [asterisk-users] Dahdi interface flapping

2013-07-30 Thread Andre Goree
On Tue, Jul 30, 2013 at 11:40 AM, Shaun Ruffell sruff...@digium.com wrote:
 On Tue, Jul 30, 2013 at 11:13:55AM -0400, Andre Goree wrote:
 On Tue, Jul 30, 2013 at 10:56 AM, Shaun Ruffell sruff...@digium.com wrote:
  On Tue, Jul 30, 2013 at 10:36:58AM -0400, Andre Goree wrote:
 
   I've posted the configs and the output of a 'pri debug' below.  Please
   let me know if I should include anything else to help troubleshoot.
   I've tried both a standalone conifguration as well as the Dahdi module
   in FreePBX, results with the same error(s).
  
   /etc/dahdi/system.conf:
   span=1,0,0,ESF,B8ZS
   bchan=1-23
   dchan=24
   loadzone=us
 
  I think the span line above is wrong. I think you want:
 
  span=1,1,0,esf,b8zs
 
  The second 1 indicates that the span should recover the clock from
  the remote side (which should be your provider). However, normally
  when you have the timing misconfigured like this you'll get HDLC
  aborts, and not just the PRI going up and down.
 
  So before looking into any more or contacting customer support, it
  might be easy to change that one line and see if the behavior is
  different.

 Thanks for the suggestions.  I did have the following before, with
 similar errors:

 [root@asterisk-master dahdi]# cat system.conf.ag
 loadzone = us
 defaultzone=us
 span=1,1,0,esf,b8zs
 bchan=1-23
 dchan=24

 From everything I've read, what you say makes complete sense and in
 fact I'm surprised that's changed (FreePBX's DAHDI module created the
 current config -- i.e. the one I posted in my original email).  I'll
 change that back and see if that makes a difference, but I'm pretty
 sure I used the above configuration in a previous attempt with the
 same results.

 Also, I have indeed received the following messages prior to the
 interface going down and these errors are what I was initially
 researching:

 [root@asterisk-master dahdi]# grep HDLC /var/log/asterisk/full
 ...
 [2013-07-30 08:09:03] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Bad FCS 
 (8) on D-channel of span 1
 [2013-07-30 08:09:03] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Bad FCS 
 (8) on D-channel of span 1
 [2013-07-30 08:24:05] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Bad FCS 
 (8) on D-channel of span 1
 [2013-07-30 08:24:05] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Bad FCS 
 (8) on D-channel of span 1
 [2013-07-30 08:29:47] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Bad FCS 
 (8) on D-channel of span 1
 [2013-07-30 08:29:47] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Bad FCS 
 (8) on D-channel of span 1
 [2013-07-30 08:30:52] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Abort 
 (6) on D-channel of span 1
 [2013-07-30 08:30:52] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Abort 
 (6) on D-channel of span 1
 [2013-07-30 08:36:01] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Bad FCS 
 (8) on D-channel of span 1
 [2013-07-30 08:36:01] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Bad FCS 
 (8) on D-channel of span 1
 [2013-07-30 08:39:54] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Abort 
 (6) on D-channel of span 1
 [2013-07-30 08:39:54] NOTICE[3621] chan_dahdi.c: PRI got event: HDLC Abort 
 (6) on D-channel of span 1

 A lot of info I found while researching the above error mentioned
 IRQ's, etc. and was one reason I posted the output of
 /proc/interrupts, heh...but I'm pretty sure my issue is not one
 that has to do with the IRQs.

 Ok, that makes more sense. One more thing that is quick and easy to
 rule out in case there are interrupt handling issues is the check
 and see if there are any error messages in dmesg related to the
 driver.

   $ dmesg | grep wcte13xp

 If something on the system is preventing the wcte13xp's interrupt
 handler from running in a timely manner you'll see messages like:
 Underrun detected by hardware.  Latency bumped to: xms

 Typically I've seen this with systems that are configured to use
 framebuffers, disks that are operating in combined mode, systems
 with consoles on slow serial ports, or ill-behaved system management
 interrupts.

 A few of those messages about latency bumps are not a problem, and
 it is the drivers way of accommodating systems with less than ideal
 real time performance. However if you see any messages like Tried
 to increase latency past buffer size then the driver will not be
 able to accommodate the host system without some changes (if you're
 lucky).

 But...still...Digium's tech support I'm sure would be more than
 happy to help you troubleshoot.

 --
 Shaun Ruffell
 Digium, Inc. | Linux Kernel Developer
 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
 Check us out at: www.digium.com  www.asterisk.org


Thanks I'll definitely be contacting Digium support shortly.  For the
hell of it, here's my dmesg output -- I'm seemingly safe from an IRQ
issue, thankfully, ha:

[root@asterisk-master dahdi]# dmesg | grep wcte13xp
wcte13xp :01:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16
wcte13xp :01:00.0: restoring config space 

Re: [asterisk-users] Dahdi interface flapping

2013-07-30 Thread Shaun Ruffell
On Tue, Jul 30, 2013 at 11:46:04AM -0400, Andre Goree wrote:
 
 Thanks I'll definitely be contacting Digium support shortly.  For the
 hell of it, here's my dmesg output -- I'm seemingly safe from an IRQ
 issue, thankfully, ha:
 
 [root@asterisk-master dahdi]# dmesg | grep wcte13xp
 wcte13xp :01:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16
 wcte13xp :01:00.0: restoring config space at offset 0xf (was 0x1ff, 
 writing 0x10b)
 wcte13xp :01:00.0: restoring config space at offset 0x4 (was 0x0, writing 
 0xdfb0)
 wcte13xp :01:00.0: restoring config space at offset 0x3 (was 0x0, writing 
 0x10)
 wcte13xp :01:00.0: restoring config space at offset 0x1 (was 0x10, 
 writing 0x17)
 wcte13xp :01:00.0: setting latency timer to 64
 wcte13xp :01:00.0: Firmware version: 6f0017
 wcte13xp :01:00.0: FALC version: 5
 wcte13xp :01:00.0: Setting up global serial parameters for T1
 wcte13xp :01:00.0: firmware: requesting dahdi-fw-oct6114-032.bin
 wcte13xp :01:00.0: Echo cancellation for 32 channels
 wcte13xp :01:00.0: Reset octasic
 wcte13xp :01:00.0: VPM450: Present and operational servicing 1 span
 wcte13xp :01:00.0: irq 37 for MSI/MSI-X
 wcte13xp :01:00.0: Found a Wildcard TE133 (SN: 1TE133F - DF04132035402 - 
 B1 - 20130521)
 wcte13xp :01:00.0: Span configured for ESF/B8ZS
 wcte13xp :01:00.0: Calling startup (flags is 4099)
 wcte13xp :01:00.0: Setting yellow alarm
 wcte13xp :01:00.0: Span configured for ESF/B8ZS
 wcte13xp :01:00.0: Calling startup (flags is 4099)
 wcte13xp :01:00.0: Span configured for ESF/B8ZS
 wcte13xp :01:00.0: Calling startup (flags is 4099)
 wcte13xp :01:00.0: Span configured for ESF/B8ZS
 wcte13xp :01:00.0: Calling startup (flags is 4099)
 wcte13xp :01:00.0: Clearing yellow alarm
 wcte13xp :01:00.0: Setting yellow alarm

It's hard to tell from this output, but something isn't perhaps
running dahdi_cfg in the background (or did you run it multiple
times after loading the card?)  Normally I only see one Calling
startup line.

-- 
Shaun Ruffell
Digium, Inc. | Linux Kernel Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com  www.asterisk.org

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users