Hey all, I had a user complaining of calls which were dropping mid-conversation. I looked into the time of one of the calls, and saw the following: 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?
On 4/5/07, Rob Schall <rschall@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. :)
On 4/5/07, Rob Schall <rschall@callone.net> wrote:> Hey all, > > I had a user complaining of calls which were dropping mid-conversation. > I looked into the time of one of the calls, and saw the following: > > 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?1) Check the connection between the demarc and your card. Is the cable the proper specification? 2) Have you updated zaptel or wanpipe recently? If you created a symlink to /usr/src/zaptel make sure its correct. If its not correct and reinstall. 3) Do you have the correct FE_LCODE, FE_FRAME, TE_CLOCK and TDMV_DCHAN in your wanpipe1.conf? Do you have the correct signalling in zapata.conf. Do you have the correct span definition and fcshdlc=24, fcshdlc=48 (unless those analog ports are defined first!) in zaptel.conf 4) Use wanpipemon -g instead of zttool. See if you are getting any errors 5) Contact your telco have them check the line Take a look at this as well: http://www.voip-info.org/wiki/view/Asterisk+PCI+bus+Troubleshooting I found it rather interesting.