<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div>Follow up on this thread:<br><br></div>Today, I could at last insert the TE220 board into an other machine in my lab.<br><br></div>1. For the moment, I plugged the card into an available PCIe x1 slot and checked IRQs with:<br>
<br></div><div># dmesg<br>...<br>[ 42.969568] dahdi: Version: SVN-trunk-r10414<br>[ 43.281832] wct4xxp 0000:04:08.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17<br>[ 43.281855] wct4xxp 0000:04:08.0: 5th gen card with initial latency of 2 and 1 ms per IRQ<br>
[ 43.281861] wct4xxp 0000:04:08.0: Firmware Version: c01a016d<br>[ 43.284411] wct4xxp 0000:04:08.0: FALC Framer Version: 3.1<br>[ 43.284420] IRQ 17/wct2xxp: IRQF_DISABLED is not guaranteed on shared IRQs<br>[ 43.284465] wct4xxp 0000:04:08.0: Found a Wildcard: Wildcard TE220 (5th Gen)<br>
[ 43.306504] wct4xxp 0000:04:08.0: firmware: requesting dahdi-fw-oct6114-064.bin<br>[ 43.568475] VPM450: echo cancellation for 64 channels<br>[ 48.722467] wct4xxp 0000:04:08.0: VPM450: hardware DTMF disabled.<br>[ 48.722471] wct4xxp 0000:04:08.0: VPM450: Present and operational servicing 2 span(s)<br>
[ 50.304512] wct4xxp 0000:04:08.0: TE2XXP: Span 1 configured for CCS/HDB3<br>[ 50.304543] wct4xxp 0000:04:08.0: RCLK source set to span 1<br>[ 50.304547] wct4xxp 0000:04:08.0: Recovered timing mode, RCLK set to span 1<br>
[ 50.304615] wct4xxp 0000:04:08.0: SPAN 1: Primary Sync Source<br><br><br></div><div># cat /proc/interrupts <br> CPU0 CPU1 <br> 0: 46 24 IO-APIC-edge timer<br> 1: 0 2 IO-APIC-edge i8042<br>
7: 1 0 IO-APIC-edge parport0<br> 8: 0 1 IO-APIC-edge rtc0<br> 9: 0 0 IO-APIC-fasteoi acpi<br> 12: 0 6 IO-APIC-edge i8042<br>
14: 0 0 IO-APIC-edge pata_atiixp<br> 15: 0 0 IO-APIC-edge pata_atiixp<br> 16: 1 339 IO-APIC-fasteoi xhci_hcd:usb3, ohci_hcd:usb4, ohci_hcd:usb5, HDA Intel<br>
17: 2216 7235841 IO-APIC-fasteoi ehci_hcd:usb1, wct2xxp<br>...<br><br></div>Does it qualify as "incompatible with Dahdi because of shared IRQ" or can I get along and keep testing on this machine ?<br>
<br><br></div>2. I plugged a straight patch cord into one E1 port and the other cord's plug into the small socket provided with card.<br></div>(I'm referring here to a female RJ45 socket mounted on a 1cm x 2cm PCB)<br>
<br></div>The port light turns green and dahdi_tool says status is OK.<br><br></div>At the same time, I'm seeing timing slips as with:<br># cat /proc/dahdi/1<br>Span 1: TE2/0/1 "T2XXP (PCI) Card 0 Span 1" (MASTER) HDB3/CCS ClockSource <br>
Timing slips: 75<br><br></div>The rate is 3 slips/minute.<br></div>Has this figure any meaning (I don't have any other card to compare with) ?<br><br><br></div>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<br>
</div>but asterisk logs are full of lines such as (~ 20 occurences per second)):<br>[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<br>
<br></div>Sometimes, a line like the one bellow slides between the above ones.<br><div><div><div><div>[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<br>
<div><div><div><div><div><div><div><div><br></div><div>Thoughts ?<br></div><div><br><div><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
2014-01-15 Olivier <span dir="ltr"><<a href="mailto:oza.4h07@gmail.com" target="_blank">oza.4h07@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div><div>I could replace the card this morning and the timing slips disappeared.<br><br></div>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.<br>
<br></div>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).<br></div>Stay tuned ...<br><br></div><div class="HOEnZb"><div class="h5">
<div class="gmail_extra"><br>
<br><div class="gmail_quote">2014/1/14 Shaun Ruffell <span dir="ltr"><<a href="mailto:sruffell@digium.com" target="_blank">sruffell@digium.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>On Mon, Jan 13, 2014 at 08:42:13PM -0500, Paul Belanger wrote:<br>
> > cat /proc/dahdi/2<br>
> > Span 2: TE2/0/2 "T2XXP (PCI) Card 0 Span 2" (MASTER) HDB3/CCS<br>
> > Timing slips: 175319<br>
> ><br>
> > 32 TE2/0/2/1 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> > 33 TE2/0/2/2 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> > 34 TE2/0/2/3 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> > 35 TE2/0/2/4 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> > 36 TE2/0/2/5 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> > 37 TE2/0/2/6 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> > 38 TE2/0/2/7 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> > 39 TE2/0/2/8 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> > 40 TE2/0/2/9 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> > 41 TE2/0/2/10 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> > 42 TE2/0/2/11 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> > 43 TE2/0/2/12 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> > 44 TE2/0/2/13 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> > 45 TE2/0/2/14 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> > 46 TE2/0/2/15 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> > 47 TE2/0/2/16 HDLCFCS (In use) (EC: VPMOCT064 - INACTIVE)<br>
> > 48 TE2/0/2/17 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> > 49 TE2/0/2/18 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> > 50 TE2/0/2/19 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> > 51 TE2/0/2/20 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> > 52 TE2/0/2/21 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> > 53 TE2/0/2/22 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> > 54 TE2/0/2/23 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> > 55 TE2/0/2/24 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> > 56 TE2/0/2/25 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> > 57 TE2/0/2/26 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> > 58 TE2/0/2/27 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> > 59 TE2/0/2/28 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> > 60 TE2/0/2/29 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> > 61 TE2/0/2/30 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> > 62 TE2/0/2/31 Clear (In use) (EC: VPMOCT064 - INACTIVE)<br>
> ><br>
> > 3. As shown above, my box has two connections with PSTN (same provider for<br>
> > both): one direct, one through an HiPath PBX.<br>
> > How can I double check timing slips don't come from "inconsistency between<br>
> > both clock sources" ?<br>
> > My first thought would be to unplug the link between Asterisk and HiPath and<br>
> > compare two /pro/dahddi/1 outputs.<br>
> > Thoughts ?<br>
> ><br>
><br>
</div></div><div>> I basically had the same issue as you for one of my sites. I tried<br>
> everything under the sun to figure it out, change cables, loop back<br>
> test, change out hardware, clocking, etc.<br>
><br>
> In the end I had to upgrade dahdi to 2.7+ and the issue went away.<br>
> Never did figure out the real problem, but to this day I think the<br>
> issue was a delay on the frames from the PCI bus into the software.<br>
><br>
> All that to say, try upgrading DAHDI and see what happens.<br>
<br>
</div>As far as Olivier's concern, I still vote there is some physical<br>
cabling issue that is causing problems.<br>
<br>
However, just for posterity, in my experience if HDLC aborts are<br>
occuring and there are timing slips, it does not have anything to do<br>
with the card / host communication, but rather the issue has more to<br>
do with the framer and connection to provider.<br>
<br>
This is because the timing slips are reported directly by the framer<br>
and that doesn't depend on the host communication.<br>
<br>
Just FYI...<br>
<div><br>
--<br>
Shaun Ruffell<br>
Digium, Inc. | Linux Kernel Developer<br>
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>
Check us out at: <a href="http://www.digium.com" target="_blank">www.digium.com</a> & <a href="http://www.asterisk.org" target="_blank">www.asterisk.org</a><br>
<br>
</div><div><div>--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
New to Asterisk? Join us for a live introductory webinar every Thurs:<br>
<a href="http://www.asterisk.org/hello" target="_blank">http://www.asterisk.org/hello</a><br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-users" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>