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

[Dimitri Prado]

Hello,

this is probably not related, but we had tons of interrupt problems
when we used zaptel compiled with ECHO_CAN_MG2. When we reverted to
ECHO_CAN_KB1 everything worked fine again. Both setups had no IDE,
framebuffer, shared irqs etc.

regards
Dimitri

On 7/9/07, François Delawarde <fdelawarde at wirelessmundi.com> wrote:
> Hi again,
>
> Tzafrir Cohen wrote:
> > 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.
> >
>
> Zaptel 1.4.3 with 1 line hookstate patch from bug 0008290 (adapted from
> 1.2.10 to 1.4.3)
>
> I also tried non-patched Zaptels from 1.2 and 1.4 series.
>
>
> >> 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).
> >
> That's what I originally thought and thus tried those options to see if
> it could resolve my problem. Right now, running on 2.6.21.6 with "Low
> latency Desktop", and HZ=1000, without success.
>
> Any idea?
>
> >
> >> 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
> >>
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>