[asterisk-users] PRI DCHAN Errors

[Scott Lykens]

On 4/5/07, Rob Schall <rschall at callone.net> wrote:


> Apr  4 12:13:03 WARNING[6670] chan_zap.c: No D-channels available!
> Using Primary channel 28 as D-channel anyway!
> Apr  4 12:13:05 WARNING[6660] channel.c: Avoided initial deadlock for
> '0x82b8430', 10 retries!
> Apr  4 12:13:05 WARNING[6660] channel.c: Avoided initial deadlock for
> '0x82d9920', 10 retries!
> Apr  4 12:13:05 WARNING[6660] channel.c: Avoided initial deadlock for
> '0x82369f0', 10 retries!
> Apr  4 12:13:05 WARNING[6660] channel.c: Avoided initial deadlock for
> '0x8242968', 10 retries!
> Apr  4 12:13:06 WARNING[6670] chan_zap.c: No D-channels available!
> Using Primary channel 28 as D-channel anyway!
> Apr  4 12:13:09 NOTICE[15466] app_dial.c: Unable to create channel of
> type 'Zap' (cause 34 - Circuit/channel congestion)
> Apr  4 12:13:11 NOTICE[6670] chan_zap.c: PRI got event: HDLC Abort (6)
> on Primary D-channel of span 2
>
> I have read that some people believe this is a driver problem, which
> others believe something could be wrong with the PRI itself. I did a
> zttool and there are and haven't been any red alarms. I also read some
> people believe this issue can be caused by another card in the box
> taking too long to respond, such as an IDE card. We have 2 sangoma PRI
> cards and 1 sangoma FXO/FXS card.
>
> Any thoughts?

FWIW I recently had some real troubles with something very similar,
including the HDLC aborts, congestion, and terrible voice quality.
Fortunately I caught the problem before the workweek so I could get it
working.

A little backstory: I had been running Linux 2.6.17-gentoo-r8 with
Asterisk 1.2.14, Zaptel 1.2.12, libpri 1.2.4 and iaxmodem 0.2.0. As I
was preparing to move all of my users over to Asterisk I wanted to
upgrade before I moved them over so that I was on 1.4.x first.

I also figured it wouldn't be a bad time to upgrade the kernel. (I
know, one thing at a time) I upgraded to 2.6.19-gentoo-r5, Asterisk
1.4.2, Zaptel 1.4.1, libpri 1.4.0, and iaxmodem 0.2.1. After
completing the upgrade the system would occasionally appear to
hardware lock only to return to normal after 15-20 seconds. No process
accounted for 100% cpu, however. It didn't do this all the time, maybe
once every few hours. Of course this "lockup" would cause the PRIs on
the system (quad port T1 card) to go a little nuts. VoIP calls would
stutter terribly.

I ended up in a rollback-reupgrade process that left me with kernel
2.6.17-gentoo-r8, the original kernel, but with the upgraded
applications and libraries. I'm not convinced the problem was
2.6.19-gentoo-r5 as I also tried a 2.6.20 kernel and I have not seen
anyone else asking about this problem but the evidence is pointing
that way. During this process I thought for a moment I had lost my
TE410P as it stopped talking to Asterisk but would talk to
ztcfg/zttool/etc. Debug on the span showed "Sending Set Asynchronous
Balanced Mode Extended" endlessly. I rolled back to my previous
application setup and the server came up fine. So I rolled forward
again with the apps without the kernel upgrade and it appears to work
fine now.

I'm running * on an IBM x306 server, 8836-1SU, specifically, with a
TE410P. At some point I will attempt to upgrade the kernel again and
see if that was the problem or I just had something screwed up.

I don't know if that will help you but that was last weekend's hours
of fun for me. :)