Posted: Fri Nov 04, 2005 9:31 pm Post subject: [Asterisk-Users] HDLC errors on PRI
I have looked through other postings to the user group for HDLC errors, went
through what worked for other people, and still can not seem to get past
this issue.
For 3 days, I have been getting HDLC abort(6) errors in *. Prior to Tuesday,
the circuits were clean...I had maybe 10 HDLC abort messages since August
10th.
Here are my specs:
1 Gig IBM x300 w/ 1 Gig Ram
1 Quad TE405P card
No errors on IRQs
IRQs are separated with NO sharing
hdparm for irq and dma are set to 'on'
Software -
FC1 with -1 updates to kernel, etc.
Asterisk v 1.0.9, libpri 1.0.9, zaptel 1.0.9.2
1 T1 is a tieline to our Nortel Meridian
3 T1s are a PRI trunk group with D chans on 24 and 48. The third T1 only has
b channels.
No alarms from zttool.
Calls go through, inbound and outbound.
About every 5 seconds, I get the following on the console:
Nov 4 21:10:37 NOTICE[9693]: PRI got event: Alarm (4) on Secondary
D-channel of span 1
Nov 4 21:10:37 NOTICE[9693]: PRI got event: HDLC Abort (6) on Primary
D-channel of span 1
The errors seem to increase as calls come in and out. There is also a
noticable "popping" when the error happens.
Posted: Sun Nov 06, 2005 10:32 pm Post subject: [Asterisk-Users] HDLC errors on PRI
Sounds like a timing issue or interop issue. Get rid of the NFAS (3rd t1 with all B channels) and make them all plain PRIs without D channel sharing.
Jason Walker <desktophero@gmail.com> wrote:
I have looked through other postings to the user group for HDLC errors, went through what worked for other people, and still can not seem to get past this issue.
For 3 days, I have been getting HDLC abort(6) errors in *. Prior to Tuesday, the circuits were clean...I had maybe 10 HDLC abort messages since August 10th.
Here are my specs:
1 Gig IBM x300 w/ 1 Gig Ram
1 Quad TE405P card
No errors on IRQs
IRQs are separated with NO sharing
hdparm for irq and dma are set to 'on'
Software -
FC1 with -1 updates to kernel, etc.
Asterisk v 1.0.9, libpri 1.0.9, zaptel 1.0.9.2
1 T1 is a tieline to our Nortel Meridian
3 T1s are a PRI trunk group with D chans on 24 and 48. The third T1 only has b channels.
No alarms from zttool.
Calls go through, inbound and outbound.
About every 5 seconds, I get the following on the console:
Nov 4 21:10:37 NOTICE[9693]: PRI got event: Alarm (4) on Secondary D-channel of span 1
Nov 4 21:10:37 NOTICE[9693]: PRI got event: HDLC Abort (6) on Primary D-channel of span 1
The errors seem to increase as calls come in and out. There is also a noticable "popping" when the error happens.
Any suggestions are welcome.
thank you
Jason
_______________________________________________
--Bandwidth and Colocation sponsored by Easynews.com --
Posted: Tue Nov 08, 2005 10:57 am Post subject: [Asterisk-Users] HDLC errors on PRI
Yeah, post your relevant portions of zaptel.conf. Usually it's a
timing problem if you have HDLC abort errors.
Matthew Fredrickson
On Nov 6, 2005, at 11:32 PM, kurt turner wrote:
Quote:
Sounds like a timing issue or interop issue.? Get rid of the NFAS (3rd
t1 with all B channels) and make them all plain PRIs without D channel
sharing.
Jason Walker <desktophero@gmail.com> wrote:
> ?
> ?
> I have looked through other postings to the user group for HDLC
> errors, went through what worked for other people, and still can not
> seem to get past this issue.
> ?
> For 3 days, I have been getting HDLC abort(6) errors in *. Prior to
> Tuesday, the circuits were clean...I had maybe 10 HDLC abort messages
> since August 10th.
> ?
> Here are my specs:
> ?
> ?
> 1 Gig IBM x300 w/ 1 Gig Ram
> 1 Quad TE405P card
> No errors on IRQs
> IRQs are separated with NO sharing
> hdparm for irq and dma are set to 'on'
> ?
> Software -
> ?
> FC1 with -1 updates to kernel, etc.
> Asterisk v 1.0.9, libpri 1.0.9, zaptel 1.0.9.2
> ?
> 1 T1 is a tieline to our Nortel Meridian
> 3 T1s are a PRI trunk group with D chans on 24 and 48. The third T1
> only has b channels.
> ?
> No alarms from zttool.
> ?
> Calls go through, inbound and outbound.
> ?
> About every 5 seconds, I get the following on the console:
> Nov? 4 21:10:37 NOTICE[9693]: PRI got event: Alarm (4) on Secondary
> D-channel of span 1
> Nov? 4 21:10:37 NOTICE[9693]: PRI got event: HDLC Abort (6) on
> Primary D-channel of span 1
> ?
> The errors seem to increase as calls come in and out. There is also a
> noticable "popping" when the error happens.
> ?
> Any suggestions are welcome.
> ?
> thank you
> ?
> Jason
> ?
> _______________________________________________
> --Bandwidth and Colocation sponsored by Easynews.com --
>
> 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-usersYahoo!
> FareChase - Search multiple travel sites in one click.
> _______________________________________________
--Bandwidth and Colocation sponsored by Easynews.com --
Posted: Tue Nov 08, 2005 11:46 am Post subject: [Asterisk-Users] HDLC errors on PRI
Matthew Fredrickson wrote:
Quote:
Yeah, post your relevant portions of zaptel.conf. Usually it's a timing
problem if you have HDLC abort errors.
Actually, it's usually a motherboard or card problem that causes HDLC
errors. Frequent causes are SATA controllers, IDE controllers, graphics
modes, RAID controllers, GIGE controllers, etc. See the mailing list
archives for the extensive discussions on this issue.
Posted: Tue Nov 08, 2005 5:56 pm Post subject: [Asterisk-Users] HDLC errors on PRI
The blanket statement that it's a motherbord or card problem is thrown around
far too readily IMO. This is often just another way of saying that I have two
(or more) pieces of hardware that don't play partucilarly nicely together in
their default configuration, but I'm too lazy/busy/scared (I'm not accusing
anyone here!) to sort it out.
Linux offers a great deal of fine-tuning of the PCI bus and the interrupt
subsystem, and you can get asterisk/zaptel to work well on most hardware with a
little effort.
Over the last six months, I have been through this extensively, and lost a lot
of sleep in the process. I now have systems that I'd call solid.
Start with digium's recommendations with regard to IDE tuning (HDPARM),
framebuffer support, ACPI, and APIC. There is a document on their website about
optimising your system to support their hardware. Then, look into SMP IRQ
Affinity (if you have an SMP system, and wish to leave APIC enabled). You can
also search for PCI latency, and see if this helps.
Also, different versions of asterisk and zaptel can make a HUGE difference. I
have had most success with 1.2Beta2 on my PSTN gateways, whilst still running
STABLE on my IVR and VOIP servers.
If you have a card that can be upgraded to the new firmware, do it. I've had all
3 of my 405P cards upgraded, and have noticed dramatic improvements in both
performance and reliability.
Use zttest every time you make a change, and also make sure that you
unload/reload zaptel, the card drivers and asterisk each time you make a change.
==========================================
Rod Bacon
Empowered Communications
Ground Floor, 102 York St. South Melbourne
Victoria, Australia. 3205
Phone: +613 99401600 Fax: +613 99401650
FWD: 512237 ICQ: 5662270
==========================================
Eric "ManxPower" Wieling wrote:
Quote:
Matthew Fredrickson wrote:
> Yeah, post your relevant portions of zaptel.conf. Usually it's a
> timing problem if you have HDLC abort errors.
Actually, it's usually a motherboard or card problem that causes HDLC
errors. Frequent causes are SATA controllers, IDE controllers, graphics
modes, RAID controllers, GIGE controllers, etc. See the mailing list
archives for the extensive discussions on this issue.
_______________________________________________
--Bandwidth and Colocation sponsored by Easynews.com --
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
