On 4/5/07, Rob Schall <[EMAIL PROTECTED]> 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. :) _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
