System is built on a SuperMicro motherboard with Serverworks chipset, IRQ is not shared. Have a dialplan that worked for 8 months without errors, tried reverting to older release then upgraded to 1.0.3 stable release, currently running on fedora core 1 kernel 2.4.22-nptl.2199 (have tried plain jayne), telco says "it's not us", HDLC abort seems to occur when when a Zap channel hangs up... no luck in searching the list, no luck on google, ready to scrap the T400p card, waitin on callback from digium, thought I'd post this log. Anyone make any sense of these errors? http://www.florida4x4.com/images/new-errors By the way, we take V.90 callers and bridge them to our modem servers. (Digium T400P) <----> <ASTERISK> <----> SIP/VoIP/etc. | LEC-PRI IN ---> (Port1) | (Port2) ---> <Max 4004 Dial-up/V.90> | (Port3) ---> <Microcom isPorte Dial-up/FAX> | (Port4) ---- <Currently unused> -- Andrew McRory - President/CTO Linux Systems Engineers, Inc. - http://www.linuxsys.com Slowly going crazy in beautiful Tallahassee, Florida Office 850-224-5737 Office 850-575-7213 Mobile 850-294-7567
On December 29, 2004 07:52 pm, Andrew McRory wrote:> System is built on a SuperMicro motherboard with Serverworks chipset, IRQ > is not shared. Have a dialplan that worked for 8 months without errors, > tried reverting to older release then upgraded to 1.0.3 stable release, > currently running on fedora core 1 kernel 2.4.22-nptl.2199 (have tried > plain jayne), telco says "it's not us", HDLC abort seems to occur when > when a Zap channel hangs up... no luck in searching the list, no luck on > google, ready to scrap the T400p card, waitin on callback from digium, > thought I'd post this log. Anyone make any sense of these errors?1. Have you reverted back to the EXACT configuration that worked for 8 months? 2. Have you plugged in a "cheap" T100P to see if the T400P has gone bad? Basic troubleshooting skills here -- it worked, you changed something, and it no longer works. Go back to what works and see if it still works. -A.
On December 29, 2004 20:33 pm, Andrew Kohlsmith wrote:> 1. Have you reverted back to the EXACT configuration that worked for 8 > months? > 2. Have you plugged in a "cheap" T100P to see if the T400P has gone bad? > > Basic troubleshooting skills here -- it worked, you changed something, > and it no longer works. Go back to what works and see if it still > works.Well it is hard to go back to a specific configuration since I have used the system to test the rpm packages I compile. Nothing like using a production server for testing, eh? I have reverted to a (actually several) pre 1.0 release that worked well, changed the port, moved the PCI slot, changed out the motherboard three times, enabled and disabled onboard devices, tried several kernels, rerun the cabling from the smart jack, checked the powersupply voltages, UPS, power cabling, etc etc etc. Basic troubleshooting? yeah man. I dont have a T100P lying around so I cant do much in the way of changing the interface. Yet. Before I commit to changing that I want to rule out any other possibilities... How can one determine without a shadow of a doubt that it is the card or otherwise? I have enabled all the debugging I can find BUT the output is foriegn to me... <shrug> This is what I set: pri intense debug span 1 set verbose 10 set debug 10 Is there a way to log all communication on the D Channel? Have I missed some critical debugging reference? I'm going crosseyed looking, tweaking and trying the same things over again. Thnx! -- Andrew McRory - President/CTO Linux Systems Engineers, Inc. - http://www.linuxsys.com Located in beautiful Tallahassee, Florida Office 850-224-5737 Office 850-575-7213 Mobile 850-294-7567
Sometimes it helps to put a screwdriver and a hammer on the computer case. Muttering the phrase outloud "I'll fix this server yet" while shaking the tools above the server is said to frighten IT demons. Is there anything in the logs that says "error" "warning" or anything of a vaguely similar manner? In otherwords have you performed "blond analysis" on the logs yet? i.e. look at them for a normal event (such as boot up) and then look for anything but normal? My main purpose in responding was to share a bit of humor with you because it can help when your irritated and frustrated. :) Brian Greul Texas Shirt Company www.txshirts.com 713-802-0369 / 713-861-6261 (fax) -----Original Message----- From: Andrew McRory [mailto:amcrory@linuxsys.com] Sent: Wednesday, December 29, 2004 8:42 PM To: asterisk-users@lists.digium.com Subject: Re: [Asterisk-Users] PRI Woes continue On December 29, 2004 20:33 pm, Andrew Kohlsmith wrote:> 1. Have you reverted back to the EXACT configuration that worked for 8> months? > 2. Have you plugged in a "cheap" T100P to see if the T400P has gonebad?> > Basic troubleshooting skills here -- it worked, you changed something,> and it no longer works. Go back to what works and see if it still > works.Well it is hard to go back to a specific configuration since I have used the system to test the rpm packages I compile. Nothing like using a production server for testing, eh? I have reverted to a (actually several) pre 1.0 release that worked well, changed the port, moved the PCI slot, changed out the motherboard three times, enabled and disabled onboard devices, tried several kernels, rerun the cabling from the smart jack, checked the powersupply voltages, UPS, power cabling, etc etc etc. Basic troubleshooting? yeah man. I dont have a T100P lying around so I cant do much in the way of changing the interface. Yet. Before I commit to changing that I want to rule out any other possibilities... How can one determine without a shadow of a doubt that it is the card or otherwise? I have enabled all the debugging I can find BUT the output is foriegn to me... <shrug> This is what I set: pri intense debug span 1 set verbose 10 set debug 10 Is there a way to log all communication on the D Channel? Have I missed some critical debugging reference? I'm going crosseyed looking, tweaking and trying the same things over again. Thnx! -- Andrew McRory - President/CTO Linux Systems Engineers, Inc. - http://www.linuxsys.com Located in beautiful Tallahassee, Florida Office 850-224-5737 Office 850-575-7213 Mobile 850-294-7567 _______________________________________________ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
> Thnx! > >-- Andrew McRory - President/CTO Linux Systems Engineers, Inc. - http://www.linuxsys.com Located in beautiful Tallahassee, Florida Office 850-224-5737 Office 850-575-7213 Mobile 850-294-7567
> On December 29, 2004 22:35 pm, Andrew Kohlsmith wrote: > > > Well it is hard to go back to a specific configuration since I have > > used the system to test the rpm packages I compile. > > Yikes.Yep. But there is only one way to "know for sure" that a new package is working. I have had much success in 2004. So much that I figured all the warnings on the list to "not upgrade a working system" were for the ultra paranoid. Still think that is mostly true.> > Nothing like using a production server for testing, eh? I have > > reverted to a (actually several) pre 1.0 release that worked well, > > changed the port, moved the PCI slot, changed out the motherboard > > three times, enabled and disabled onboard devices, tried several > > kernels, rerun the cabling from the smart jack, checked the > > powersupply voltages, UPS, power cabling, etc etc etc. Basic > > troubleshooting? yeah man. > > That wasn't meant to be flip -- Perhaps I've just been bitten too many > times myself by doing the exact same thing you just did -- I back up my > config (going as far as to rsync or image the partition if I need) > before changing something like that on a production system... especially > something as important as our main telephone system. :-)Understood. I want to believe that each day will only bring improvements to the code. Sure, I know that bugs can slip in to the updates but that should be temporary if it happens at all... right? hahahahaha! Perhaps my doctor is right and I am crazy.> > I dont have a T100P lying around so I cant do much in the way of > > changing the interface. Yet. Before I commit to changing that I want > > to rule out any other possibilities... How can one determine without a > > shadow of a doubt that it is the card or otherwise? I have enabled all > > the debugging I can find BUT the output is foriegn to me... <shrug> > > Yeah -- I don't know -- I am the last to blame hardware (10 years as an > embedded electronics designer does that to you) but failing everything > else it really does seem that this is the issue, does it not?Yes it does, but I still want to think it is me. After all, I have spent more time compiling RPMS than I have learning the dialplan. With that said my production dialplan is the most basic you can get. I have an alternate, more complicated dialplan that I am developing but I only switch that in for brief periods testing during low traffic hours. My plan is to move the complicated part of the dialplan to a secondary server that will handle the the real work - VoIP calls, AVR, Voicemail, etc. over TDMoE or IAX2... still thinking that one out.> Something else I learned the hard way -- have any criticial hardware > available onhand, not at a distributor, even if they can ship overnight > -- I have a story about a DS3 MUX that had both controllers die and the > manufacturer shipped one overnight but UPS lost it... true story. > It's expensive to have hardware sitting on the shelf idle but better > that than be without phone service or whatever other critical system > you've got. :-)yep I need another T400p, a spare engine for my truck and not one, but two legal age females on hand in case my wife gets the flu, or worse. Of course I have a 7206VXR here sitting on a shelf with a lot of pretty cards stuffed in it just waiting for a chance to prove itself... but thats a different story altogether.> > Is there a way to log all communication on the D Channel? Have I > > missed some critical debugging reference? I'm going crosseyed looking, > > tweaking and trying the same things over again. > > pri debug span 1 will show you all q.931 traffic and intense will show > you the q.921 traffic too, but this seems deeper than that -- I am not a > telco expert but it certainly seems like something very low level is > buggered. I am sorry I can't be more help.Well you tried and I commend you for that. I wouldn't even be asking here if I had even the slightest clue on what to do next. Perhaps Digium will come through with some testing tomorow / err / I mean today. I have to do whatever it takes to regain 99.999% reliability for my dial-up customers. I would like to accomplish this with Asterisk, as a proof of concept if for nothing else, but I will be forced to pull it out of the chain if a resolution can't be found in the next couple days. This has gone on toooo long and I am looking bad. oops. Gotta get some sleep. Thanks for you comments! Regards, -- Andrew McRory - President/CTO Linux Systems Engineers, Inc. - http://www.linuxsys.com Located in beautiful Tallahassee, Florida Office 850-224-5737 Office 850-575-7213 Mobile 850-294-7567