Zap Calls Dropped after after 30-45 mins

Hi Group
I have a PBXinaflash Asterisk (Ver. 1.4.21.2). This system has been functional since November 5th.
I have a Digium TDM401B.
The VOIP system is on its own LAN with its own dedicated Firewall. It has 4 phones, 2 voip connections and a PSTN connection.

I don’t have many calls of this length (over 30 mins) and in the past have not worried too much about them (occasional dropout), but now as I’m aware of this problem I’m paying more attention to it.

How do I go about fault finding this problem?
Thoughts/Suggestions?

Thanks
Mark

Below is a copy of the Asterisk log file:-

[Jan 12 14:01:18] DEBUG[12743] dsp.c: ast_dsp_busydetect detected busy, avgtone: 85, avgsilence 85
[Jan 12 14:01:18] VERBOSE[12743] logger.c: == Spawn extension (macro-dial, s, 7) exited non-zero on ‘Zap/1-1’ in macro ‘dial’
[Jan 12 14:01:18] VERBOSE[12743] logger.c: == Spawn extension (macro-dial, s, 7) exited non-zero on ‘Zap/1-1’
[Jan 12 14:01:18] VERBOSE[12743] logger.c: – Executing [[email protected]:1] Macro(“Zap/1-1”, “hangupcall”) in new stack
[Jan 12 14:01:18] VERBOSE[12743] logger.c: – Executing [[email protected]:1] ResetCDR(“Zap/1-1”, “w”) in new stack
[Jan 12 14:01:18] DEBUG[12743] app_macro.c: Executed application: ResetCDR
[Jan 12 14:01:18] VERBOSE[12743] logger.c: – Executing [[email protected]:2] NoCDR(“Zap/1-1”, “”) in new stack
[Jan 12 14:01:18] DEBUG[12743] app_macro.c: Executed application: NoCDR
[Jan 12 14:01:18] VERBOSE[12743] logger.c: – Executing [[email protected]:3] GotoIf(“Zap/1-1”, “1?skiprg”) in new stack
[Jan 12 14:01:18] VERBOSE[12743] logger.c: – Goto (macro-hangupcall,s,6)
[Jan 12 14:01:18] DEBUG[12743] app_macro.c: Executed application: GotoIf
[Jan 12 14:01:18] VERBOSE[12743] logger.c: – Executing [[email protected]:6] GotoIf(“Zap/1-1”, “0?skipblkvm”) in new stack
[Jan 12 14:01:18] DEBUG[12743] app_macro.c: Executed application: GotoIf
[Jan 12 14:01:18] VERBOSE[12743] logger.c: – Executing [[email protected]:7] NoOp(“Zap/1-1”, “Cleaning Up Block VM Flag: BLKVM/600/Zap/1-1”) in new stack
[Jan 12 14:01:18] DEBUG[12743] app_macro.c: Executed application: Noop
[Jan 12 14:01:18] VERBOSE[12743] logger.c: – Executing [[email protected]:8] DBdel(“Zap/1-1”, “BLKVM/600/Zap/1-1”) in new stack
[Jan 12 14:01:18] VERBOSE[12743] logger.c: – DBdel: family=BLKVM, key=600/Zap/1-1
[Jan 12 14:01:18] VERBOSE[12743] logger.c: – DBdel: Error deleting key from database.
[Jan 12 14:01:18] DEBUG[12743] app_macro.c: Executed application: DBDel
[Jan 12 14:01:18] VERBOSE[12743] logger.c: – Executing [[email protected]:9] GotoIf(“Zap/1-1”, “1?theend”) in new stack
[Jan 12 14:01:18] VERBOSE[12743] logger.c: – Goto (macro-hangupcall,s,11)
[Jan 12 14:01:18] DEBUG[12743] app_macro.c: Executed application: GotoIf
[Jan 12 14:01:18] VERBOSE[12743] logger.c: – Executing [[email protected]:11] Hangup(“Zap/1-1”, “”) in new stack
[Jan 12 14:01:18] VERBOSE[12743] logger.c: == Spawn extension (macro-hangupcall, s, 11) exited non-zero on ‘Zap/1-1’ in macro ‘hangupcall’
[Jan 12 14:01:18] VERBOSE[12743] logger.c: == Spawn extension (macro-hangupcall, s, 11) exited non-zero on ‘Zap/1-1’
[Jan 12 14:01:18] VERBOSE[12743] logger.c: – Hungup ‘Zap/1-1’

Is your zap card sharing interrupts with any other device? If so that could be the cause, a interrupt occurring at just the wrong moment and it’s attempting to read something that is not fully there or interrupted from normal processing by that other piece of hardware and then it’s to late to process by the time it get control back.

Thanks for reply,
I checked for Interrupt sharing when built and another check sayes no.
See Below:-
[email protected]:~ $ cat /proc/interrupts
CPU0 CPU1
0: 8720768 2782093 IO-APIC-edge timer
1: 2 7 IO-APIC-edge i8042
6: 2 3 IO-APIC-edge floppy
7: 0 0 IO-APIC-edge parport0
8: 0 1 IO-APIC-edge rtc
9: 0 0 IO-APIC-level acpi
12: 74 40 IO-APIC-edge i8042
14: 41 109122 IO-APIC-edge ide0
177: 56862 2322 IO-APIC-level ida0
185: 21 54232 IO-APIC-level eth0
193: 2754027 8735821 IO-APIC-level wctdm24xxp0
NMI: 0 0
LOC: 11503688 11503687
ERR: 0
MIS: 0

00: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 5
I/O ports at 2c00
Memory at c4dfe800 (32-bit, non-prefetchable)
Capabilities: [c0] Power Management version 2