[asterisk-users] How to read IRQs and timing slips values
Olivier
oza.4h07 at gmail.com
Mon Feb 3 06:52:36 CST 2014
Follow up on this thread:
Today, I could at last insert the TE220 board into an other machine in my
lab.
1. For the moment, I plugged the card into an available PCIe x1 slot and
checked IRQs with:
# dmesg
...
[ 42.969568] dahdi: Version: SVN-trunk-r10414
[ 43.281832] wct4xxp 0000:04:08.0: PCI INT A -> GSI 17 (level, low) ->
IRQ 17
[ 43.281855] wct4xxp 0000:04:08.0: 5th gen card with initial latency of 2
and 1 ms per IRQ
[ 43.281861] wct4xxp 0000:04:08.0: Firmware Version: c01a016d
[ 43.284411] wct4xxp 0000:04:08.0: FALC Framer Version: 3.1
[ 43.284420] IRQ 17/wct2xxp: IRQF_DISABLED is not guaranteed on shared
IRQs
[ 43.284465] wct4xxp 0000:04:08.0: Found a Wildcard: Wildcard TE220 (5th
Gen)
[ 43.306504] wct4xxp 0000:04:08.0: firmware: requesting
dahdi-fw-oct6114-064.bin
[ 43.568475] VPM450: echo cancellation for 64 channels
[ 48.722467] wct4xxp 0000:04:08.0: VPM450: hardware DTMF disabled.
[ 48.722471] wct4xxp 0000:04:08.0: VPM450: Present and operational
servicing 2 span(s)
[ 50.304512] wct4xxp 0000:04:08.0: TE2XXP: Span 1 configured for CCS/HDB3
[ 50.304543] wct4xxp 0000:04:08.0: RCLK source set to span 1
[ 50.304547] wct4xxp 0000:04:08.0: Recovered timing mode, RCLK set to
span 1
[ 50.304615] wct4xxp 0000:04:08.0: SPAN 1: Primary Sync Source
# cat /proc/interrupts
CPU0 CPU1
0: 46 24 IO-APIC-edge timer
1: 0 2 IO-APIC-edge i8042
7: 1 0 IO-APIC-edge parport0
8: 0 1 IO-APIC-edge rtc0
9: 0 0 IO-APIC-fasteoi acpi
12: 0 6 IO-APIC-edge i8042
14: 0 0 IO-APIC-edge pata_atiixp
15: 0 0 IO-APIC-edge pata_atiixp
16: 1 339 IO-APIC-fasteoi xhci_hcd:usb3,
ohci_hcd:usb4, ohci_hcd:usb5, HDA Intel
17: 2216 7235841 IO-APIC-fasteoi ehci_hcd:usb1, wct2xxp
...
Does it qualify as "incompatible with Dahdi because of shared IRQ" or can I
get along and keep testing on this machine ?
2. I plugged a straight patch cord into one E1 port and the other cord's
plug into the small socket provided with card.
(I'm referring here to a female RJ45 socket mounted on a 1cm x 2cm PCB)
The port light turns green and dahdi_tool says status is OK.
At the same time, I'm seeing timing slips as with:
# cat /proc/dahdi/1
Span 1: TE2/0/1 "T2XXP (PCI) Card 0 Span 1" (MASTER) HDB3/CCS ClockSource
Timing slips: 75
The rate is 3 slips/minute.
Has this figure any meaning (I don't have any other card to compare with) ?
3. When I'm plugging the same E1 port into a Smartnode E1 gateway port
(then using an E1 crossover cable), dahdi_tool tells status is OK
but asterisk logs are full of lines such as (~ 20 occurences per second)):
[2014-02-03 13:46:04] NOTICE[2076]: chan_dahdi.c:3099
my_handle_dchan_exception: PRI got event: HDLC Abort (6) on D-channel of
span 1
Sometimes, a line like the one bellow slides between the above ones.
[2014-02-03 13:50:24] NOTICE[2076]: chan_dahdi.c:3099
my_handle_dchan_exception: PRI got event: HDLC Bad FCS (8) on D-channel of
span 1
Thoughts ?
2014-01-15 Olivier <oza.4h07 at gmail.com>:
> 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/20140203/08a6a704/attachment.html>
More information about the asterisk-users
mailing list