[asterisk-users] Dahdi interface flapping

[Andre Goree]

On Tue, Jul 30, 2013 at 11:40 AM, Shaun Ruffell <sruffell at 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 <sruffell at 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 at 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 at 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 at 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