TE410P (1st) without cables always green

Helo,

I am upgrading a linux box ( Slackware + asterisk 1.0 + zaptel 0.9 ) to
new asterisk 1.8 + dahdi.

– In old softwares versions the box is working well.

– After upgrade to slackware 13.37 + dahdi ( 2.3.X to SVN ) + asterisk ,
before asterisk is loaded and PRI/E1 Cables ( Span 1/2 ) + T1 ( Span 3/4
for Addtran channels banks ) ,
all Spans are in OK ( Green ) mode.

– I go to another developer box, and the same problems cames up, is very
dificult for me work in the productions box ( only 02:00 am to 04:00 am ).

– Follwing my developer box setup :

1) System.conf ( I am working at this time with only 1 spam )

span=1,1,0,ccs,hdb3,crc4
# termtype: te
bchan=1-15,17-31
dchan=16
echocanceller=mg2,1-15,17-31

loadzone = us
defaultzone = us

2)
modprobe wct4xxp debug=3
root@zap4:~# dahdi_cfg -v
DAHDI Tools Version – 2.3.0

DAHDI Version: 2.3.0.1
Echo Canceller(s):
Configuration
======================

SPAN 1: CCS/HDB3 Build-out: 0 db (CSU)/0-133 feet (DSX-1)

31 channels to configure.

Setting echocan for channel 1 to mg2
Setting echocan for channel 2 to mg2
Setting echocan for channel 3 to mg2
Setting echocan for channel 4 to mg2
Setting echocan for channel 5 to mg2
Setting echocan for channel 6 to mg2
Setting echocan for channel 7 to mg2
Setting echocan for channel 8 to mg2
Setting echocan for channel 9 to mg2
Setting echocan for channel 10 to mg2
Setting echocan for channel 11 to mg2
Setting echocan for channel 12 to mg2
Setting echocan for channel 13 to mg2
Setting echocan for channel 14 to mg2
Setting echocan for channel 15 to mg2
Setting echocan for channel 16 to none
Setting echocan for channel 17 to mg2
Setting echocan for channel 18 to mg2
Setting echocan for channel 19 to mg2
Setting echocan for channel 20 to mg2
Setting echocan for channel 21 to mg2
Setting echocan for channel 22 to mg2
Setting echocan for channel 23 to mg2
Setting echocan for channel 24 to mg2
Setting echocan for channel 25 to mg2
Setting echocan for channel 26 to mg2
Setting echocan for channel 27 to mg2
Setting echocan for channel 28 to mg2
Setting echocan for channel 29 to mg2
Setting echocan for channel 30 to mg2
Setting echocan for channel 31 to mg2

3) dahdi_scan

dahdi_scan |more
[1]
active=yes
alarms=OK =================================> Here is the proble, the
span is without cables.
description=T4XXP (PCI) Card 0 Span 1
name=TE4/0/1
manufacturer=Digium
devicetype=Wildcard TE410P/TE405P (1st Gen)
location=Board ID Switch 0
basechan=1
totchans=31
irq=20
type=digital-E1
syncsrc=0
lbo=0 db (CSU)/0-133 feet (DSX-1)
coding_opts=HDB3
framing_opts=CCS,CRC4
coding=HDB3
framing=CCS

4) dmesg , I put some informantion in bold.

dahdi: Telephony Interface Unloaded
dahdi: Telephony Interface Registered on major 196
dahdi: Version: 2.3.0.1
Found TE4XXP at base address e9100000, remapped to f895a000
DMA memory base of size 4096 at f6513000. Read: f6513800 and Write f6513000
TE4XXP version c01a009b, burst OFF
card 0: FALC framer is v2.1 or earlier.
FALC version: 00000005, Board ID: 00
Reg 0: 0x36513800
Reg 1: 0x36513000
Reg 2: 0x07fc07fc
Reg 3: 0x00000000
Reg 4: 0x00000000
Reg 5: 0x00000000
Reg 6: 0xc01a009b
Reg 7: 0x00001300
Reg 8: 0x010200ff
Reg 9: 0x00fd0000
Reg 10: 0x0000004a
*IRQ 20/wct4xxp: IRQF_DISABLED is not guaranteed on shared IRQs
wct4xxp 0000:05:00.0: Enabled 1sec error counter interrupt
wct4xxp 0000:05:00.0: Enabled errored second interrupt
wct4xxp 0000:05:00.0: Enabled 1sec error counter interrupt
wct4xxp 0000:05:00.0: Enabled errored second interrupt
wct4xxp 0000:05:00.0: Enabled 1sec error counter interrupt
wct4xxp 0000:05:00.0: Enabled errored second interrupt
wct4xxp 0000:05:00.0: Enabled 1sec error counter interrupt
wct4xxp 0000:05:00.0: Enabled errored second interrupt
*Found a Wildcard: Wildcard TE410P/TE405P (1st Gen)
TE4XXP: Launching card: 0
TE4XXP: Setting up global serial parameters
Successfully initialized serial bus for unit 0
Successfully initialized serial bus for unit 1
Successfully initialized serial bus for unit 2
Successfully initialized serial bus for unit 3
About to enter spanconfig!
TE4XXP: Configuring span 1
Done with spanconfig!
TE4XXP: Configured channel 1 (TE4/0/1/1) sigtype 128
dahdi_echocan_mg2: Registered echo canceler ‘MG2′
TE4XXP: Configured channel 2 (TE4/0/1/2) sigtype 128
TE4XXP: Configured channel 3 (TE4/0/1/3) sigtype 128
TE4XXP: Configured channel 4 (TE4/0/1/4) sigtype 128
TE4XXP: Configured channel 5 (TE4/0/1/5) sigtype 128
TE4XXP: Configured channel 6 (TE4/0/1/6) sigtype 128
TE4XXP: Configured channel 7 (TE4/0/1/7) sigtype 128
TE4XXP: Configured channel 8 (TE4/0/1/8) sigtype 128
TE4XXP: Configured channel 9 (TE4/0/1/9) sigtype 128
TE4XXP: Configured channel 10 (TE4/0/1/10) sigtype 128
TE4XXP: Configured channel 11 (TE4/0/1/11) sigtype 128
TE4XXP: Configured channel 12 (TE4/0/1/12) sigtype 128
TE4XXP: Configured channel 13 (TE4/0/1/13) sigtype 128
TE4XXP: Configured channel 14 (TE4/0/1/14) sigtype 128
TE4XXP: Configured channel 15 (TE4/0/1/15) sigtype 128
TE4XXP: Configured channel 16 (TE4/0/1/16) sigtype 896
TE4XXP: Configured channel 17 (TE4/0/1/17) sigtype 128
TE4XXP: Configured channel 18 (TE4/0/1/18) sigtype 128
TE4XXP: Configured channel 19 (TE4/0/1/19) sigtype 128
TE4XXP: Configured channel 20 (TE4/0/1/20) sigtype 128
TE4XXP: Configured channel 21 (TE4/0/1/21) sigtype 128
TE4XXP: Configured channel 22 (TE4/0/1/22) sigtype 128
TE4XXP: Configured channel 23 (TE4/0/1/23) sigtype 128
TE4XXP: Configured channel 24 (TE4/0/1/24) sigtype 128
TE4XXP: Configured channel 25 (TE4/0/1/25) sigtype 128
TE4XXP: Configured channel 26 (TE4/0/1/26) sigtype 128
TE4XXP: Configured channel 27 (TE4/0/1/27) sigtype 128
TE4XXP: Configured channel 28 (TE4/0/1/28) sigtype 128
TE4XXP: Configured channel 29 (TE4/0/1/29) sigtype 128
TE4XXP: Configured channel 30 (TE4/0/1/30) sigtype 128
TE4XXP: Configured channel 31 (TE4/0/1/31) sigtype 128
dahdi: Registered tone zone 0 (United States / North America)
About to enter startup!
TE4XXP: Span 1 configured for CCS/HDB3/CRC4
wct4xxp 0000:05:00.0: timing source auto
wct4xxp 0000:05:00.0: Evaluating spans for timing source
wct4xxp 0000:05:00.0: span 1 is green : syncpos 1
*wct4xxp 0000:05:00.0: RCLK source set to span 1
wct4xxp 0000:05:00.0: Recovered timing mode, RCLK set to span 1
wct4xxp: LOF/LFA detected on span 1 but debouncing for 2500 ms
wct4xxp: LOS detected on span 1 but debouncing for 2500 ms*
SPAN 1: Primary Sync Source
VPM400: Not Present
OCT Result: 0000/000a
VPM450: Not Present
Completed startup!
Detected loss of E1 alignment on span 0!

5) cat /proc/interrupts

cat /proc/interrupts 1
CPU0 CPU1
0: 598466 686790 IO-APIC-edge timer
1: 4 4 IO-APIC-edge i8042
8: 0 0 IO-APIC-edge rtc0
9: 0 0 IO-APIC-fasteoi acpi
16: 0 0 IO-APIC-fasteoi pata_jmicron
19: 488966 400468 IO-APIC-fasteoi ata_piix, ata_piix
20: 20 8 IO-APIC-fasteoi wct4xxp
28: 3267 3254 PCI-MSI-edge eth0
NMI: 1285298 1285102 Non-maskable interrupts
LOC: 686792 598229 Local timer interrupts
SPU: 0 0 Spurious interrupts
PMI: 0 0 Performance monitoring interrupts
PND: 0 0 Performance pending work
RES: 535 493 Rescheduling interrupts
CAL: 25 36 Function call interrupts
TLB: 136 124 TLB shootdowns
TRM: 0 0 Thermal event interrupts
THR: 0 0 Threshold APIC interrupts
MCE: 0 0 Machine check exceptions
MCP: 5 5 Machine check polls
ERR: 1
MIS: 0

best regards,

Marcio Gomes

7 Responses to “TE410P (1st) without cables always green”

  1. Patrick Lists said:

    Feb 07, 12 at 2:07 pm

    [snip]

    [snip]

    Thank you for your elaborate feedback. It’s clear why you are the one
    developing and I send my 0.02 to the mailinglist :) I see your point.
    Digging in logfiles it is.

    Regards,
    Patrick

  2. Marcio Gomes said:

    Feb 07, 12 at 3:05 pm

    Hello All,

    I forget to say,

    In production BOX, I “only” do a linux -R newconfig && reboot ,

    slots , hardware, setup, etc.. is the same.. no changes. It’s give me a
    confirmation about it is not a hardware issue, the only changes
    are in software.

    In the development box, a hardware problem iss possible, I will make a
    copy of the working software and put in it to clarify this
    doubt.

    Regards,

    Marcio Gomes

  3. Marcio Gomes said:

    Feb 07, 12 at 3:38 pm

    News from Zaptel..

    I patch the last zaptel.1.2.27 to compiles in 2.6.33 kernels series….
    Surprise !!!!!!

    20: 68011 71871 IO-APIC-fasteoi wct4xxp

    in zttool the spans are RED, all is working with pre 1.4 zaptel and dahdi.

    The problems are in changes between zaptel.1.2.X and zaptel.1.4.X.

    I thinking now that is an old issue added from 1.2 to 1.4 branches and
    sucessivily to dahdi branches,
    and I lost something in past.

    But I want go to asterisk 1.8 and greater with new drivers , Can anyone
    help me in this ?

  4. Marcio Gomes said:

    Feb 09, 12 at 8:45 am

    Hello Shaun,

    I take this approach :

    – zaptel 1.2.XX , 1.4.XX I can see interrupts working , I made some
    patches to compile in 2.6.32 kernel tree.

    patches to compile in 2.6.32 kernel tree

    IRQs/Second
    Device (IRQ) CPU0 CPU1 TOTAL
    rtc0 ( 8): 0 0 0
    i8042 ( 1): 0 0 0
    eth0 ( 28): 3 3 6
    timer ( 0): 435 566 1001
    ata_piix, ata_piix ( 19): 2 1 3
    pata_jmicron ( 16): 0 0 0
    cascade ( 2): 0 0 0
    wct4xxp ( 20): 566 435 1001

    As you can see, I am having 1K int/s

    , wct4xxp.c and wctdm.c , and comment out the lines relative to others
    drivers ( I only needs wcfxo, wctdm and wct4xxp
    to this box )

    – 2.2.1 and greater -> Compiles without patches, but not working, int/s = 0

    I do not knows the main changes from 2.2.0 to to 2.2.1 dahdi-tree , but
    it is clear to me that problems are in this changes. I can goes up and
    down between versions
    with same issues, I do this because initially suspected from da dead
    lock in hardware create for some tests I have do.

    Regards,

    Marcio Gomes

    Em 07/02/2012 17:38, Marcio Gomes escreveu:

  5. Shaun Ruffell said:

    Feb 09, 12 at 2:20 pm

    Marcio,

    My understanding is that (and I don’t have the spec in front of me)
    is that AT&T 54016 defines a standard for how long a red alarm
    condition should be on the span before the framer sends yellow alarm
    to the remote side. Those changes for alarm debounce were put in to
    comply with that standard.

    It does surprise me to learn that on Gen1 cards, setting the
    alarmdebounce module parameter to 0 allows those boards to function
    normally. After looking through the differences between 2.2.0.2 and
    2.2.1 the only change that looks related at the hardware level in
    that case is whether the framer is commanded to send yellow alarm or
    not when in alarm. When alarmdebounce is 0, the framer will start
    sending yellow right after the first interrupts where red alarm is
    detected. Perhaps the gen1 cards stop interrupting the host when in
    alarm, so the driver debounce never trips, never starts sending
    yellow, which *may* be what causes the interrupts to keep flowing
    in?

    Just thinking out loud here but I’m guessing it may be fair to just
    set alarmdebounce to 0 by default on gen1 cards.

    With dahdi-linux 2.2.0.2 does your card function if you set alarm
    debounce to 2500?

  6. Marcio Gomes said:

    Feb 09, 12 at 6:30 pm

    Shaun,

    set alarmdebounce to 0 by default on gen1 cards.
    debounce to 2500?
    /etc/init.d/dahdi stop
    sleep 3
    modprobe dahdi
    modprobe wct4xxp debug=1 alarmdebounce=2500
    dahdi_cfg
    cat /proc/interrupts | grep wct4xxp; sleep 5 ; cat /proc/interrupts |
    grep wct4xxp

    20: 62045611 62097065 IO-APIC-fasteoi wct4xxp
    20: 62045613 62097065 IO-APIC-fasteoi wct4xxp

    No interrupts, I do some tests and alarmdebounce should be 0 or 1 to
    generate interrupts correctly.

    Yeah, it’s correct IMO.

    After working hours ( until next monday ) I will do some tests in
    production box.. ( I have to change the kernel config and others small
    things I have modified
    in last week and are generating some Kpanic’s in module load ). I can
    only do this in time slot 00:00 – 07:00 am

  7. Marcio Gomes said:

    Feb 10, 12 at 9:36 am

    Shaun,

    Follwing more tests :

    1) In production box asterisk works with 2.4.X dahdi tree + kernel
    2.33.x tree. I can put the trunk up and recieve some calls .

    2) In the same box I had tested dahdi 2.6.X + same kernel, when run
    dahdi_cfg this error messages comes , in dahdi_cfg running and
    no interrupts are in dmesg .. Any idea ?

    Loading DAHDI hardware modules:
    wct4xxp: [ OK ]
    wcfxo: [ OK ]

    Running dahdi_cfg: DAHDI startup failed: Input/output error

    Please see the follwing quoted ( in old messages ) text about 2.6
    dahdis, as you can see in devel box, dahdi_cfg works in new dadhdi ( I
    not know if pri goes
    up in asterisk, because this box are without )

    Any idea here ?

    3) I remember some problems in dahdi< =2.6 our 2.5 with newer kernel
    trees. This issue ( new dahd’s not works and old dahd’s not compile in new
    kerne tree) will be a problem in future time. A brazilian guy post to me
    that are problems in new dahdi and old boards.. , can you confirm any issue
    in this points ?

    Regards,

    Em 09/02/2012 20:30, Marcio Gomes escreveu: