Using Asterisk-1.4.17, Zaptel-1.4.8, libpri-1.4.3 Upgraded this morning, now PRI channels are unstable as hell. After about 5 minutes all asterisk commands on the console refuse to respond, attached is the debug log right before and after the "lock-up", IT occurred between 9:18 and 9:20 AM at 9:20 I restarted asterisk. Box is debian w/ asterisk built from scratch. My setup is asterisk as a man-in-the-middle, Span 1 goes to Telco, Span 2 to Nortel MICS. PRI is not the problem as it's plugged into the Nortel directly for now and we have no problems. Nothing in dmesg indicates any errors. Any clue how I go about debugging this? ---- [Jan 16 09:18:41] DEBUG[10183] chan_zap.c: Unlinking slave 1 from 47 [Jan 16 09:18:41] DEBUG[10183] chan_zap.c: Removed 12 from conference 9/47 [Jan 16 09:18:41] DEBUG[10183] chan_zap.c: Removed 57 from conference 9/1 [Jan 16 09:18:41] DEBUG[10183] chan_zap.c: Set option AUDIO MODE, value: ON(1) on Zap/1-1 [Jan 16 09:18:56] DEBUG[10107] chan_zap.c: Unlinking slave 26 from 3 [Jan 16 09:18:56] DEBUG[10107] chan_zap.c: Removed 36 from conference 9/3 [Jan 16 09:18:56] DEBUG[10107] chan_zap.c: Removed 14 from conference 9/26 [Jan 16 09:18:56] DEBUG[10107] chan_zap.c: Set option AUDIO MODE, value: ON(1) on Zap/26-1 [Jan 16 09:18:56] DEBUG[10107] chan_zap.c: Not yet hungup... Calling hangup once with icause, and clearing call [Jan 16 09:18:56] DEBUG[10107] chan_zap.c: Set option AUDIO MODE, value: OFF(0) on Zap/26-1 [Jan 16 09:18:56] DEBUG[10107] chan_zap.c: Set option AUDIO MODE, value: ON(1) on Zap/3-1 [Jan 16 09:20:24] DEBUG[8430] chan_zap.c: Ring requested on channel 0/23 already in use or previously requested on span 2. Attempting to renegotiating chann el. [Jan 16 09:20:24] DEBUG[8430] chan_zap.c: Found empty available channel 0/21 [Jan 16 09:22:24] DEBUG[8430] chan_zap.c: Ring requested on channel 0/23 already in use or previously requested on span 2. Attempting to renegotiating chann el. [Jan 16 09:22:24] DEBUG[8430] chan_zap.c: Found empty available channel 0/20 [Jan 16 09:22:31] DEBUG[8430] chan_zap.c: Ring requested on channel 0/23 already in use or previously requested on span 2. Attempting to renegotiating chann el. [Jan 16 09:22:31] DEBUG[8430] chan_zap.c: Found empty available channel 0/19 [Jan 16 09:23:07] DEBUG[8430] chan_zap.c: Ring requested on channel 0/23 already in use or previously requested on span 2. Attempting to renegotiating chann el. [Jan 16 09:23:07] DEBUG[8430] chan_zap.c: Found empty available channel 0/18 ________________________________ This e-mail, facsimile, or letter and any files or attachments transmitted with it contains information that is confidential and privileged. This information is intended only for the use of the individual(s) and entity(ies) to whom it is addressed. If you are the intended recipient, further disclosures are prohibited without proper authorization. If you are not the intended recipient, any disclosure, copying, printing, or use of this information is strictly prohibited and possibly a violation of federal or state law and regulations. If you have received this information in error, please notify Texas Health Management Group immediately at 1-817-310-4999. Texas Health Management Group, its subsidiaries, and affiliates hereby claim all applicable privileges related to this information. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080116/058a139a/attachment-0001.htm
On Jan 16, 2008 10:25 AM, Jeremy Mann <jmann at txhmg.com> wrote:> Using Asterisk-1.4.17, Zaptel-1.4.8, libpri-1.4.3 > > > > Upgraded this morning, now PRI channels are unstable as hell. After about > 5 minutes all asterisk commands on the console refuse to respond, attached > is the debug log right before and after the "lock-up", IT occurred between > 9:18 and 9:20 AM at 9:20 I restarted asterisk. > > > > Box is debian w/ asterisk built from scratch. > > > > My setup is asterisk as a man-in-the-middle, Span 1 goes to Telco, Span 2 > to Nortel MICS. PRI is not the problem as it's plugged into the Nortel > directly for now and we have no problems. > > > > Nothing in dmesg indicates any errors. > > > > Any clue how I go about debugging this? > > > > ---- > > > > [Jan 16 09:18:41] DEBUG[10183] chan_zap.c: Unlinking slave 1 from 47 > > [Jan 16 09:18:41] DEBUG[10183] chan_zap.c: Removed 12 from conference 9/47 > > [Jan 16 09:18:41] DEBUG[10183] chan_zap.c: Removed 57 from conference 9/1 > > [Jan 16 09:18:41] DEBUG[10183] chan_zap.c: Set option AUDIO MODE, value: > ON(1) on Zap/1-1 > > [Jan 16 09:18:56] DEBUG[10107] chan_zap.c: Unlinking slave 26 from 3 > > [Jan 16 09:18:56] DEBUG[10107] chan_zap.c: Removed 36 from conference 9/3 > > [Jan 16 09:18:56] DEBUG[10107] chan_zap.c: Removed 14 from conference 9/26 > > [Jan 16 09:18:56] DEBUG[10107] chan_zap.c: Set option AUDIO MODE, value: > ON(1) on Zap/26-1 > > [Jan 16 09:18:56] DEBUG[10107] chan_zap.c: Not yet hungup... Calling > hangup once with icause, and clearing call > > [Jan 16 09:18:56] DEBUG[10107] chan_zap.c: Set option AUDIO MODE, value: > OFF(0) on Zap/26-1 > > [Jan 16 09:18:56] DEBUG[10107] chan_zap.c: Set option AUDIO MODE, value: > ON(1) on Zap/3-1 > > [Jan 16 09:20:24] DEBUG[8430] chan_zap.c: Ring requested on channel 0/23 > already in use or previously requested on span 2. Attempting to > renegotiating chann > > el. > > [Jan 16 09:20:24] DEBUG[8430] chan_zap.c: Found empty available channel > 0/21 > > [Jan 16 09:22:24] DEBUG[8430] chan_zap.c: Ring requested on channel 0/23 > already in use or previously requested on span 2. Attempting to > renegotiating chann > > el. > > [Jan 16 09:22:24] DEBUG[8430] chan_zap.c: Found empty available channel > 0/20 > > [Jan 16 09:22:31] DEBUG[8430] chan_zap.c: Ring requested on channel 0/23 > already in use or previously requested on span 2. Attempting to > renegotiating chann > > el. > > [Jan 16 09:22:31] DEBUG[8430] chan_zap.c: Found empty available channel > 0/19 > > [Jan 16 09:23:07] DEBUG[8430] chan_zap.c: Ring requested on channel 0/23 > already in use or previously requested on span 2. Attempting to > renegotiating chann > > el. > > [Jan 16 09:23:07] DEBUG[8430] chan_zap.c: Found empty available channel > 0/1 >Sorry I cannot be of help with your issue since I stick with 1.2.x until I stop seeing my bugs folder filling up daily and seeing posts like this and the very long running post about "Unstable Releases". I would suggest rolling back to whatever version worked and opening an issue on bugtracker. I am curious though, why did you upgrade? Were you having problems with the version you upgraded from? Thanks, Steve Totaro -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20080116/67b790ef/attachment.htm
Jeremy Mann wrote:> Using Asterisk-1.4.17, Zaptel-1.4.8, libpri-1.4.3 > > Upgraded this morning, now PRI channels are unstable as hell. After about 5 minutes all asterisk commands on the console refuse to respond, attached is the debug log right before and after the "lock-up", IT occurred between 9:18 and 9:20 AM at 9:20 I restarted asterisk. > > Box is debian w/ asterisk built from scratch. > > My setup is asterisk as a man-in-the-middle, Span 1 goes to Telco, Span 2 to Nortel MICS. PRI is not the problem as it's plugged into the Nortel directly for now and we have no problems. > > Nothing in dmesg indicates any errors. > > Any clue how I go about debugging this?The best way is to start going through versions and figuring out which version it broke at. Some other things worth checking: What versions of Zaptel/libpri/Asterisk did you upgrade from? When you upgraded, did you recompile them in the correct order (Zaptel 1st, then libpri, then Asterisk)? Matthew Fredrickson> > ---- > > [Jan 16 09:18:41] DEBUG[10183] chan_zap.c: Unlinking slave 1 from 47 > [Jan 16 09:18:41] DEBUG[10183] chan_zap.c: Removed 12 from conference 9/47 > [Jan 16 09:18:41] DEBUG[10183] chan_zap.c: Removed 57 from conference 9/1 > [Jan 16 09:18:41] DEBUG[10183] chan_zap.c: Set option AUDIO MODE, value: ON(1) on Zap/1-1 > [Jan 16 09:18:56] DEBUG[10107] chan_zap.c: Unlinking slave 26 from 3 > [Jan 16 09:18:56] DEBUG[10107] chan_zap.c: Removed 36 from conference 9/3 > [Jan 16 09:18:56] DEBUG[10107] chan_zap.c: Removed 14 from conference 9/26 > [Jan 16 09:18:56] DEBUG[10107] chan_zap.c: Set option AUDIO MODE, value: ON(1) on Zap/26-1 > [Jan 16 09:18:56] DEBUG[10107] chan_zap.c: Not yet hungup... Calling hangup once with icause, and clearing call > [Jan 16 09:18:56] DEBUG[10107] chan_zap.c: Set option AUDIO MODE, value: OFF(0) on Zap/26-1 > [Jan 16 09:18:56] DEBUG[10107] chan_zap.c: Set option AUDIO MODE, value: ON(1) on Zap/3-1 > [Jan 16 09:20:24] DEBUG[8430] chan_zap.c: Ring requested on channel 0/23 already in use or previously requested on span 2. Attempting to renegotiating chann > el. > [Jan 16 09:20:24] DEBUG[8430] chan_zap.c: Found empty available channel 0/21 > [Jan 16 09:22:24] DEBUG[8430] chan_zap.c: Ring requested on channel 0/23 already in use or previously requested on span 2. Attempting to renegotiating chann > el. > [Jan 16 09:22:24] DEBUG[8430] chan_zap.c: Found empty available channel 0/20 > [Jan 16 09:22:31] DEBUG[8430] chan_zap.c: Ring requested on channel 0/23 already in use or previously requested on span 2. Attempting to renegotiating chann > el. > [Jan 16 09:22:31] DEBUG[8430] chan_zap.c: Found empty available channel 0/19 > [Jan 16 09:23:07] DEBUG[8430] chan_zap.c: Ring requested on channel 0/23 already in use or previously requested on span 2. Attempting to renegotiating chann > el. > [Jan 16 09:23:07] DEBUG[8430] chan_zap.c: Found empty available channel 0/18 > > ________________________________ > This e-mail, facsimile, or letter and any files or attachments transmitted with it contains information that is confidential and privileged. This information is intended only for the use of the individual(s) and entity(ies) to whom it is addressed. If you are the intended recipient, further disclosures are prohibited without proper authorization. If you are not the intended recipient, any disclosure, copying, printing, or use of this information is strictly prohibited and possibly a violation of federal or state law and regulations. If you have received this information in error, please notify Texas Health Management Group immediately at 1-817-310-4999. Texas Health Management Group, its subsidiaries, and affiliates hereby claim all applicable privileges related to this information. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users-- Matthew Fredrickson Software/Firmware Engineer Digium, Inc.