One Way Audio on TDM410

[FitnessPlus]

It seems that about once a week I have to reboot our server because our TDM410 card decides that it no longer wants to receive audio properly from the caller.

The caller will call in, and clearly hear instructions given, but if they try to press buttons on their phone to choose an extension, our server does not respond because it cannot "hear" the tones. If the caller waits long enough, the phones in the office start ringing by default, and if we pick up the phone the caller can hear us, but we cannot hear anything the caller says.

Meanwhile our VOIP lines are working perfectly fine, so I believe it is with our configuration of the card, or the card itself.

Where to I start trying to figure out this problem?

 

[jroper]

Hi

Next time it does it, try and collect as much information from the logs as possible.

I would also be interested to know whether a "amportal stop" or amportal kill followed by amportal start or the above followed by service zaptel restart followed by amportal start clears the problem.

Additionally, if you have brought the card in the last 12 months, then i am sure that Digium support will be happy to help you.

You still need to find out the circumstances of what happens just before it all goes wrong though to give them the best chance of fixing it.

Yours

Joe

 

[Bart]

you might want to run cat /proc/interrupts to see if there is any IRQ sharring with card

Bart

 

[FitnessPlus]

Bart, thanks for the pointer.

I did a little reading on http://www.voip-info.org/wiki/view/Asterisk+PCI+bus+Troubleshooting
and ran: [FONT=&quot]lspci -vb

This showed me that the USB controller and the Digium card are both using IRQ 5.

There are a few things (like the sound card and on board NIC that's not being used) that I'm going to disable tomorrow once I get to the office, and then move the card to a different slot. I sure hope this clears up the problem.
[/FONT]

 

[euser4life]

Not sure which version of Asterisk you are running but if you are currently on 1.4.21 then maybe this applies:

The Asterisk.org development team has released Asterisk version 1.4.21.1.

This release includes a critical bug fix for 1.4.21. All users that experienced lockups when upgrading to 1.4.21 should have their issues resolved with this update.

 

[FitnessPlus]

I do have 1.4.21.

This release is only a couple of days old. If I run update-source will it upgrade me to 1.4.21.1?

I put the card on it's own IRQ this morning, I'm crossing my fingers and hoping that the system works properly today.

 

[Bart]

I'm sort of wondering which MotherBoard you are using and how old it might be?

Bart

 

[FitnessPlus]

http://www.newegg.com/Product/Product.aspx?Item=N82E16813135082


I haven't been real happy with it since I bought it...it was cheap...

The first problem I had was that the MAC address of the onboard NIC would randomly change on each reboot, which means I couldn't just use the router to assign an IP to that MAC address. I just used a PCI NIC instead and disabled the onboard NIC.

What I ran into this morning was that there are only two PCI slots and they wanted to use IRQ 5 and 10, the USB controller also wanted to use 5 and 10.

The solutution to the problem was to disable USB 2.0 from the BIOS, which freed IRQ 10 up, then I had to switch the PCI slots between the TDM410 and the NIC so that the TDM410 was in the slot using IRQ 10.

So at this point IRQ 5 is still shared between the NIC and the USB 1.1 controller.

 

[euser4life]

I do have 1.4.21.

This release is only a couple of days old. If I run update-source will it upgrade me to 1.4.21.1?

I put the card on it's own IRQ this morning, I'm crossing my fingers and hoping that the system works properly today.

If you run update-source it will pick up 1.4.21.1. I did this on two boxes last night.

 

[FitnessPlus]

Still experiencing problem

I've upgraded to the newest source, and I'm pretty sure I've corrected the IRQ problems. The problems seems to have reduced, but I'm still getting one way audio on the TDM410 about once a day. When this happens I have to reboot to get it to come back.

When the one way audio happens, are there specific tests I should be running at that point before I reboot?

Where do I look next?

Does the fact that I'm running a SATA hard drive present a problem?

The Machine is running a 3200+

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 44
model name      : AMD Athlon(tm) 64 Processor 3200+
stepping        : 2
cpu MHz         : 1000.000
cache size      : 512 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow up pni lahf_lm
bogomips        : 2011.32
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc

lspci -vb yeilds the following:

[EMAIL="root@pbx:/proc"]root@pbx:/proc[/EMAIL] $ lspci -vb
00:00.0 RAM memory: nVidia Corporation MCP61 Memory Controller (rev a1)
        Subsystem: Elitegroup Computer Systems Unknown device 2151
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 255
        Capabilities: [44] HyperTransport: Slave or Primary Interface
        Capabilities: [dc] HyperTransport: MSI Mapping
00:01.0 ISA bridge: nVidia Corporation MCP61 LPC Bridge (rev a2)
        Subsystem: Elitegroup Computer Systems Unknown device 2151
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 255
00:01.1 SMBus: nVidia Corporation MCP61 SMBus (rev a2)
        Subsystem: Elitegroup Computer Systems Unknown device 2151
        Flags: 66MHz, fast devsel, IRQ 7
        I/O ports at fc00
        I/O ports at 1c00
        I/O ports at f400
        Capabilities: [44] Power Management version 2
00:01.2 RAM memory: nVidia Corporation MCP61 Memory Controller (rev a2)
        Subsystem: Elitegroup Computer Systems Unknown device 2151
        Flags: 66MHz, fast devsel
00:02.0 USB Controller: nVidia Corporation MCP61 USB Controller (rev a3) (prog-if 10 [OHCI])
        Subsystem: Elitegroup Computer Systems Unknown device 2151
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 5
        Memory at fe02f000 (32-bit, non-prefetchable)
        Capabilities: [44] Power Management version 2
00:04.0 PCI bridge: nVidia Corporation MCP61 PCI bridge (rev a1) (prog-if 01 [Subtractive decode])
        Flags: bus master, 66MHz, fast devsel, latency 0
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
        I/O behind bridge: 0000c000-0000cfff
        Memory behind bridge: fde00000-fdefffff
        Prefetchable memory behind bridge: fd700000-fd7fffff
        Capabilities: [b8] #0d [0000]
        Capabilities: [8c] HyperTransport: MSI Mapping
00:06.0 IDE interface: nVidia Corporation MCP61 IDE (rev a2) (prog-if 8a [Master SecP PriP])
        Subsystem: Elitegroup Computer Systems Unknown device 2151
        Flags: bus master, 66MHz, fast devsel, latency 0
        I/O ports at f000
        Capabilities: [44] Power Management version 2
00:08.0 IDE interface: nVidia Corporation MCP61 SATA Controller (rev a2) (prog-if 85 [Master SecO PriO])
        Subsystem: Elitegroup Computer Systems Unknown device 2151
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 11
        I/O ports at 09f0
        I/O ports at 0bf0
        I/O ports at 0970
        I/O ports at 0b70
        I/O ports at dc00
        Memory at fe02d000 (32-bit, non-prefetchable)
        Capabilities: [44] Power Management version 2
        Capabilities: [b0] Message Signalled Interrupts: 64bit+ Queue=0/2 Enable-
        Capabilities: [cc] HyperTransport: MSI Mapping
00:09.0 PCI bridge: nVidia Corporation MCP61 PCI Express bridge (rev a2) (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0
        Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
        I/O behind bridge: 0000b000-0000bfff
        Memory behind bridge: fdd00000-fddfffff
        Prefetchable memory behind bridge: 00000000fdc00000-00000000fdc00000
        Capabilities: [40] #0d [0000]
        Capabilities: [48] Power Management version 2
        Capabilities: [50] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable+
        Capabilities: [60] HyperTransport: MSI Mapping
        Capabilities: [80] Express Root Port (Slot+) IRQ 0
        Capabilities: [100] Virtual Channel
00:0b.0 PCI bridge: nVidia Corporation MCP61 PCI Express bridge (rev a2) (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0
        Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
        I/O behind bridge: 0000a000-0000afff
        Memory behind bridge: fdb00000-fdbfffff
        Prefetchable memory behind bridge: 00000000fda00000-00000000fda00000
        Capabilities: [40] #0d [0000]
        Capabilities: [48] Power Management version 2
        Capabilities: [50] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable+
        Capabilities: [60] HyperTransport: MSI Mapping
        Capabilities: [80] Express Root Port (Slot+) IRQ 0
        Capabilities: [100] Virtual Channel
00:0c.0 PCI bridge: nVidia Corporation MCP61 PCI Express bridge (rev a2) (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0
        Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
        I/O behind bridge: 00009000-00009fff
        Memory behind bridge: fd900000-fd9fffff
        Prefetchable memory behind bridge: 00000000fd800000-00000000fd800000
        Capabilities: [40] #0d [0000]
        Capabilities: [48] Power Management version 2
        Capabilities: [50] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable+
        Capabilities: [60] HyperTransport: MSI Mapping
        Capabilities: [80] Express Root Port (Slot+) IRQ 0
        Capabilities: [100] Virtual Channel
00:0d.0 VGA compatible controller: nVidia Corporation GeForce 6100 nForce 405 (rev a2) (prog-if 00 [VGA controller])
        Subsystem: Elitegroup Computer Systems Unknown device 2151
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 7
        Memory at fb000000 (32-bit, non-prefetchable)
        Memory at 00000000e0000000 (64-bit, prefetchable)
        Memory at 00000000fc000000 (64-bit, non-prefetchable)
        Capabilities: [48] Power Management version 2
        Capabilities: [50] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
        Flags: fast devsel
        Capabilities: [80] HyperTransport: Host or Secondary Interface
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
        Flags: fast devsel
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
        Flags: fast devsel
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
        Flags: fast devsel
01:05.0 Ethernet controller: Digium, Inc. Unknown device 8005 (rev 11)
        Subsystem: Digium, Inc. Unknown device 8005
        Flags: bus master, medium devsel, latency 64, IRQ 10
        I/O ports at cc00
        Memory at fdeff000 (32-bit, non-prefetchable)
        Capabilities: [c0] Power Management version 2
01:06.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10)
        Subsystem: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet
        Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 5
        I/O ports at c800
        Memory at fdefe000 (32-bit, non-prefetchable)
        Capabilities: [dc] Power Management version 2

running zttest for a few minutes give me:

--- Results after 729 passes ---
Best: 99.998 -- Worst: 98.108 -- Average: 99.981908, Difference: 99.996319

And hdparm /dev/hda and hdparm -i /dev/hda give me:

[EMAIL="root@pbx"]root@pbx[/EMAIL]:~ $ hdparm  /dev/hda
/dev/hda:
 IO_support   =  1 (32-bit)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    = 256 (on)
 HDIO_GETGEO failed: Inappropriate ioctl for device
[EMAIL="root@pbx"]root@pbx[/EMAIL]:~ $ hdparm -i /dev/hda
/dev/hda:
 Model=16X10, FwRev=G.CJ, SerialNo=
 Config={ Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
 RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
 BuffType=DualPortCache, BuffSize=1024kB, MaxMultSect=0
 (maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4
 DMA modes:  sdma0 sdma1 sdma2 mdma0 mdma1 *mdma2
 AdvancedPM=no
 * signifies the current active mode

 

[Bart]

Is there anything in your logs at the time it happens?
When new calls come in and they are also 1-way? Which way?
How about SIP to SIP calls? Are the problem calls SIP to ZAP only? Any Alarms (yellow/red)?

Bart

 

[FitnessPlus]

Is there anything in your logs at the time it happens?
When new calls come in and they are also 1-way? Which way?
How about SIP to SIP calls? Are the problem calls SIP to ZAP only? Any Alarms (yellow/red)?

Bart

Being a newbie, which logs should I take a look at?
When this happens, I've tested a little with my cell phone... I call into the system and the call connects and I can hear the IVR on my cell phone, but when I punch in numbers on my cell, the IVR does not respond. Eventually with my setup, the IVR fails over to the receptionist, and when she picks up the phone I can hear her fine on my cell phone, but she cannot hear me. So audio comes out the system, but any inbound audio is not picked up by the PiaF system.

The SIP channels all behave normally when this occurs.

I haven't seen any alarms on the admin webpage when this happens.

 

[FitnessPlus]

I think it's Fixed

After talking with support at www.8774e4voip.com where I bought the card, they only suggestion they could make when looking at my configuration was removing the echotraining=800 line from my zapata.conf file and replacing it with echotraining=no.

That was Thursday of last week and they system hasn't shown the same problem since...I believe it has been corrected.

Apparently the echotraining was interfering with the hardware echo canceling.