Re: [asterisk-users] asterisk 1.4 freezes with queues and iax after virtualization
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
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
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
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
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
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
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
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
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
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
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