DAHDI PRI HDLC Abort on D-Channel

Asterisk Asterisk Support
1

Hi Guys,
Hope this is the right place to put this, but I’m pulling my hair out. I’m in the process of putting an Asterisk box in the front of a legacy PBX connected via a E1 (Primary Rate) link. I’m the network clocking source (the legacy equipment just sees me as the carrier). I’ve then got SIP trunks in Asterisk to route the call.

This all works swimmingly but after investigating pops / noise on the line, I found this:

PRI got event: HDLC Abort (6) on D-channel of span 1 happening fairly often on calls. (A block of between 2-10 of these errors appears every 5-10 seconds.)

I replaced the cable, same issue, so I grabbed a loopback connector and ran “patlooptest” as per the instructions here. Which returned this:

Now that doesn’t look too good to me…
I changed the legacy equipment I was connecting to to a PRI Buttset and ran some test on that, same result - Working but with crackling occurring exactly when the HDLC Aborts appeared in Monitor.

Further investigation led me to start looking at IRQs, I’ve disabled HyperThreading on the BIOS, which made it a little better, but they’re still happening like crazy, and when I set the other end to be the clock source, and the Digum card to be CPE the same issue occurs.

My system is as follows:
[ul]
[li]Digium Wildcard TE110P T1 E1 Board[/li]
[li]Dahdi Linux complete 2.9.1.12.9.1[/li]
[li]Asterisk 11.9.0[/li]
[li]Ubuntu 12.04.4 LTS[/li][/ul]
I installed Asterisk, DAHDI & libpri from source as described on this link from Digum.

Here’s the output of DAHDI’s “System.conf”

[code]# Span 1: WCT1/0 “Digium Wildcard TE110P T1/E1 Card 0” (MASTER)
span=1,1,0,ccs,hdb3,crc4

termtype: te

bchan=1-15,17-31
dchan=16
echocanceller=mg2,1-15,17-31

Global data

loadzone = au
defaultzone = au
[/code]

Does this sound like I’m on the right track hunting down IRQ related stuff? I’ve been using Asterisk for a while now but always using Gateways… So I’ve never faced this before, any links / advice would be appreciated. Could it be something to do with echo cancellation? The TE110P has no hardware echo cancellation?
Cheers,
Mike

2

When I had this problem it was primarily due to an IRQ conflict. Can you post a “cat /proc/interrupts”?

3

Howdy,

I’d also be suspicious of other devices on the PCI bus being poor citizens and blocking interrupts for too long a period for the TE110 to deal with.

This was one of the reasons we discontinued the TE110 seven years ago and introduced a new design, the TE12x (TE121, TE122), which itself has also been put to pasture for new sales, as of this past December, and replaced by the TE13x (TE131, TE132, TE133 & TE134) series.

Cheers

4

Personally I had a good experience with two TE110P cards, but “luckily” they didn’t share any IRQ with other devices. I had to modify the driver to make it compatible with Asterisk 1.8/DAHDI 2.5, but otherwise they work perfectly.

5

For anyone else looking for support for this, I’ve just booted this up on a brand new box I’ve purchased and it works a treat so far. I think it was just issues sharing an IRQ to be honest.
The board I’m using is a Gigabyte B75M-D3H with 2x PCI slots (So I can add another later) and it works a treat. I changed a few switches in the BIOS but I’m pretty sure it would’ve worked either way.

Looking for more of a robust solution in the future for us, do any of the Digum cards contain their own hardware clocks? I know having x86 hardware performing the clocking for anything can be a bit iffy, and I’d rather avoid doing it in software.

6

They’ve all got hardware clocks.

It’s not a matter of the x86 hardware providing bad clocking in the case of the TE110, it’s a case of the card being very sensitive to latency across the PCI bus; modern cards aren’t sensitive like that.

It was also a matter of compatibility (things were just weird with more modern motherboards and that PCI interface chip).