[asterisk-users] Dahdi interface flapping

[Andre Goree]

On Tue, Jul 30, 2013 at 3:55 PM, Shaun Ruffell <sruffell at digium.com> wrote:
> 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 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
>
> 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

Ran through a loopback test with Digium which seemingly proved that
there was no issue with their card.  I've contacted my telco for
assistance but so far have been unable to come up with
anything...though there may be a timing slip issue.  In any case, the
D-channel will indeed come up, but then after a while (at non-regular
intervals), the D-channel goes down after this message in the logs:
[2013-08-02 09:56:23] NOTICE[8688] chan_dahdi.c: PRI got event: HDLC
Bad FCS (8) on D-channel of span 1
[2013-08-02 09:56:23] NOTICE[8688] chan_dahdi.c: PRI got event: HDLC
Bad FCS (8) on D-channel of span 1
...
[2013-08-02 09:56:26] VERBOSE[8688] chan_dahdi.c: PRI Span: 1 TEI=0
MDL-ERROR (F): SABME in state 7(Multi-frame established)
[2013-08-02 09:56:26] VERBOSE[8688] chan_dahdi.c: PRI Span: 1 TEI=0
MDL-ERROR (F): SABME in state 7(Multi-frame established)
[2013-08-02 09:56:40] VERBOSE[8688] chan_dahdi.c: PRI Span: 1 TEI=0
MDL-ERROR (I): T200 expired N200 times sending RR/RNR in state 8(Timer
recovery)
[2013-08-02 09:56:40] VERBOSE[8688] chan_dahdi.c: PRI Span: 1 TEI=0
MDL-ERROR (I): T200 expired N200 times sending RR/RNR in state 8(Timer
recovery)


In the meantime I've been trying to adjust smp_affinity for the te133
IRQ (just for the hell of it and the fact that I'm running out of
things to try)  but it apparently it's being reset automatically by
something.  I.e., I'll run this:
[root at asterisk-master ~]# echo 8 > /proc/irq/31/smp_affinity
[root at asterisk-master ~]# cat /proc/irq/31/smp_affinity
08

but then, 5-10 secs later:
[root at asterisk-master ~]# cat /proc/irq/31/smp_affinity
01

Have you ever seen something like that?  I'm using brand-newish
hardware w/both the server and the card, so I wouldn't be surprised if
I've run into some sort of new issue.  I'm about to shut the server
down now and give the BIOS settings a once-over just to make sure I'm
not actually running into something weird hardware-wise.