On Tue, Jul 30, 2013 at 11:40 AM, Shaun Ruffell <[email protected]> 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 <[email protected]> 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: <x>ms" > > 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 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 wcte13xp 0000:01:00.0: restoring config space at offset 0xf (was 0x1ff, writing 0x10b) wcte13xp 0000:01:00.0: restoring config space at offset 0x4 (was 0x0, writing 0xdfb00000) wcte13xp 0000:01:00.0: restoring config space at offset 0x3 (was 0x0, writing 0x10) wcte13xp 0000:01:00.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100007) wcte13xp 0000:01:00.0: setting latency timer to 64 wcte13xp 0000:01:00.0: Firmware version: 6f0017 wcte13xp 0000:01:00.0: FALC version: 5 wcte13xp 0000:01:00.0: Setting up global serial parameters for T1 wcte13xp 0000:01:00.0: firmware: requesting dahdi-fw-oct6114-032.bin wcte13xp 0000:01:00.0: Echo cancellation for 32 channels wcte13xp 0000:01:00.0: Reset octasic wcte13xp 0000:01:00.0: VPM450: Present and operational servicing 1 span wcte13xp 0000:01:00.0: irq 37 for MSI/MSI-X wcte13xp 0000:01:00.0: Found a Wildcard TE133 (SN: 1TE133F - DF04132035402 - B1 - 20130521) wcte13xp 0000:01:00.0: Span configured for ESF/B8ZS wcte13xp 0000:01:00.0: Calling startup (flags is 4099) wcte13xp 0000:01:00.0: Setting yellow alarm wcte13xp 0000:01:00.0: Span configured for ESF/B8ZS wcte13xp 0000:01:00.0: Calling startup (flags is 4099) wcte13xp 0000:01:00.0: Span configured for ESF/B8ZS wcte13xp 0000:01:00.0: Calling startup (flags is 4099) wcte13xp 0000:01:00.0: Span configured for ESF/B8ZS wcte13xp 0000:01:00.0: Calling startup (flags is 4099) wcte13xp 0000:01:00.0: Clearing yellow alarm wcte13xp 0000:01:00.0: Setting yellow alarm -- _____________________________________________________________________ -- 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
