[asterisk-users] How to read IRQs and timing slips values

[Olivier]

I could replace the card this morning and the timing slips disappeared.

Given Adrian's testimony, that doesn't mean the card is faulty but as the
card is now off service, I'm really eagger to investigate further.

At the moment, I can't insert this card and test it again in my lab but
I'll certainly do it within a couple of hours (and report here).
Stay tuned ...



2014/1/14 Shaun Ruffell <sruffell at digium.com>

> On Mon, Jan 13, 2014 at 08:42:13PM -0500, Paul Belanger wrote:
> > > cat /proc/dahdi/2
> > > Span 2: TE2/0/2 "T2XXP (PCI) Card 0 Span 2" (MASTER) HDB3/CCS
> > >     Timing slips: 175319
> > >
> > >       32 TE2/0/2/1 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > >       33 TE2/0/2/2 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > >       34 TE2/0/2/3 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > >       35 TE2/0/2/4 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > >       36 TE2/0/2/5 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > >       37 TE2/0/2/6 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > >       38 TE2/0/2/7 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > >       39 TE2/0/2/8 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > >       40 TE2/0/2/9 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > >       41 TE2/0/2/10 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > >       42 TE2/0/2/11 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > >       43 TE2/0/2/12 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > >       44 TE2/0/2/13 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > >       45 TE2/0/2/14 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > >       46 TE2/0/2/15 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > >       47 TE2/0/2/16 HDLCFCS (In use) (EC: VPMOCT064 - INACTIVE)
> > >       48 TE2/0/2/17 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > >       49 TE2/0/2/18 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > >       50 TE2/0/2/19 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > >       51 TE2/0/2/20 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > >       52 TE2/0/2/21 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > >       53 TE2/0/2/22 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > >       54 TE2/0/2/23 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > >       55 TE2/0/2/24 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > >       56 TE2/0/2/25 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > >       57 TE2/0/2/26 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > >       58 TE2/0/2/27 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > >       59 TE2/0/2/28 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > >       60 TE2/0/2/29 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > >       61 TE2/0/2/30 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > >       62 TE2/0/2/31 Clear (In use) (EC: VPMOCT064 - INACTIVE)
> > >
> > > 3. As shown above, my box has two connections with PSTN (same provider
> for
> > > both): one direct, one through an HiPath PBX.
> > > How can I double check timing slips don't come from "inconsistency
> between
> > > both clock sources" ?
> > > My first thought would be to unplug the link between Asterisk and
> HiPath and
> > > compare two /pro/dahddi/1 outputs.
> > > Thoughts ?
> > >
> >
> > I basically had the same issue as you for one of my sites. I tried
> > everything under the sun to figure it out, change cables, loop back
> > test, change out hardware, clocking, etc.
> >
> > In the end I had to upgrade dahdi to 2.7+ and the issue went away.
> > Never did figure out the real problem, but to this day I think the
> > issue was a delay on the frames from the PCI bus into the software.
> >
> > All that to say, try upgrading DAHDI and see what happens.
>
> As far as Olivier's concern, I still vote there is some physical
> cabling issue that is causing problems.
>
> However, just for posterity, in my experience if HDLC aborts are
> occuring and there are timing slips, it does not have anything to do
> with the card / host communication, but rather the issue has more to
> do with the framer and connection to provider.
>
> This is because the timing slips are reported directly by the framer
> and that doesn't depend on the host communication.
>
> Just FYI...
>
> --
> Shaun Ruffell
> Digium, Inc. | Linux Kernel Developer
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: www.digium.com & www.asterisk.org
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>                http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20140115/35337b8b/attachment.html>