[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