[asterisk-dev] possible zaptel problem with SMP and RAID1

Tzafrir Cohen tzafrir.cohen at xorcom.com
Mon Jul 9 06:09:02 CDT 2007


Hi

On Mon, Jul 09, 2007 at 12:29:30PM +0200, François Delawarde wrote:
> Hello,
> 
> I thought this mail would be more appropriate in this mailing list, if 
> not sorry about it.
> 
> I've been having interrupt problems since I'm trying to use analog 
> zaptel hardware (mainly openvox A400 and OPVXA1200) on two dual core 
> machines (AMD64 X2, different motherboards and network cards) with 
> software RAID1 in two SATA drives. These problems didn't occur on my 
> previous setups without any RAID.

What version of Zaptel do you use?

Is it patched in any way?

OPVXA1200 uses its own driver, originally based on wctdm.

> 
> The problem appears to happen randomly, a few times per minute (or 
> sometimes per 5 minutes), zttest utility drops to 60-90%, saying that I 
> had too many interrupts (showing lines like "8192 samples in 7212 sample 
> interval"). Along with that come an audible "bip" and some rare times a 
> small cut in conversation, or a small bit of echo during a very short 
> time. I'll add that a higher disk load (running dbench) appears to 
> increase a little the frequence of those problems (but not totally sure).
> 
> zttool show no missed interrupts with watchdog option enable before 
> compilation. No shared interrupts. No IDE drives (related to possible 
> DMA problem). No frame buffer, console only server. Tried with all 
> PREEMPT kernel options, all HZ options, with and without IRQ balance, 
> trying SMP afinity to switch interrupts to another core, all without 
> result, except for PREEMPT options that makes zttest constantly report 
> 99.975586% instead of 100% when there are no problems.
> 
> I'm no kernel expert, but since the only pattern I found in all tests 
> seemed to be related to RAID, I was wondering if spinlocks disabling 
> interrupts like RAID drivers seem to be doing in SMP configuration would 
> be the cause of delaying of zaptel interrupts, leading to the kind of 
> problems I have. Any idea on that?

First off, better preemption should generally help you. You need timely
response (be that at the price of some throughput performance).

> 
> 
> For info, the problem occurred on these combinations of setups:
> - OS: Debian etch (tested on sarge)
> - Processors: two different AMD64 X2, one of each is in AM2 socket.
> - Partitions: ext3 on RAID1 (tested with ext3 on LVM on RAID1 and ext3 
> on Encrypted LVM on RAID1)
> - Custom kernel 2.6.21.6 with IMQ and Layer 7 (tested with 2.6.18 and 
> with/without these two patches, also tested with XEN kernel with 
> horrible, but expected results).
> - zaptel 1.4.3 (tried 1.2 series, and 1.4 since 1.4.1).
> - a few services: DNS, DHCP, Samba, PHP/MySQL interface, astmanproxy 
> (tested without any).
> 
> Worked well on:
> - OS: Debian etch
> - AMD64 Sempron
> - Kernel 2.6.18 with IMQ and Layer 7
> - No RAID
> - zaptel 1.4 series
> - same services as above

-- 
               Tzafrir Cohen       
icq#16849755                    jabber:tzafrir at jabber.org
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com       
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir



More information about the asterisk-dev mailing list