[Asterisk-Users] Possible solution to Zaptel panics

[Brancaleoni Matteo]

I can confirm that. Seems that the diva server 4bri 'hates'
any zaptel hardware. 
I had it running on a rather new box, where it caused
a lot of T100P 'slips' . Same conf on another box
is pretty stable. (the T100P slips anyway some only
2/3 times in a day... before it slipped continuosly).

Matteo.

Il mer, 2003-06-25 alle 21:52, The Traveller ha scritto:
> Heya Mark (and others),
> 
> Here's an update on my adventures while trying to debug the Zaptel-related
> panics, as discussed on this list a while back.
> 
> While debugging the problem, I completely swapped the machine for an
> entirely different model (Supermicro dual Xeon 2.4GHz with 2Gb of RAM),
> put the cards in, recompiled * + Zaptel and administered my stress-test.
> The machine stayed up in excess of 15 minutes, so I assumed a hardware
> or timing-problem had caused the panics on the old box and continued
> installing the other components (Kernel v2.4.21, with Eicon Diva Server-
> drivers, for the Diva Server 4BRI PCI v2.0 in that box, amongst others).
> 
> After I had it up and running like the old server, I gave the stress-test
> another go, just to be sure, and sure enough, after just 1 or 2 minutes,
> it croaked again, with the familiar panic.  I was quick to diagnose that
> the most probable difference that could cause this was that the Eicon
> Diva-drivers where now loaded.  And indeed, after I unloaded them,
> started * without chan_capi and administered the stress-test again,
> it didn't panic.  In fact, it has been running under the load for
> around 20 minutes now.  I just loaded the Eicon-drivers and
> it crashed again, in under a minute.
> 
> So, it seems like the Eicon Diva Server 4BRI PCI and Zaptel (at least
> with the E100P-hardware that I'm using) don't like eachother very much.
> I checked "/proc/interrupts" and these devices aren't sharing any IRQ's:
> 
>            CPU0       CPU1       CPU2       CPU3
>   0:     151846          0          0          0    IO-APIC-edge  timer
>   1:          3          0          0          0    IO-APIC-edge  keyboard
>   2:          0          0          0          0          XT-PIC  cascade
>   4:         46          0          0          0    IO-APIC-edge  serial
>   8:          1          0          0          0    IO-APIC-edge  rtc
>   9:          0          0          0          0    IO-APIC-edge  acpi
>  15:          2          0          0          0    IO-APIC-edge  ide1
>  16:          0          0          0          0   IO-APIC-level  usb-uhci
>  18:          0          0          0          0   IO-APIC-level  usb-uhci
>  19:          0          0          0          0   IO-APIC-level  usb-uhci
>  24:    1433575          0          0          0   IO-APIC-level  t1xxp
>  28:       7387          0          0          0   IO-APIC-level  aic7xxx
>  29:         15          0          0          0   IO-APIC-level  aic7xxx
>  31:       4810          0          0          0   IO-APIC-level  eth0
>  48:         65          0          0          0   IO-APIC-level  DIVA 4BRI 6261
> NMI:          0          0          0          0
> LOC:     151337     151329     151330     151353
> ERR:          0
> MIS:          0
> 
> I'm using a stock v2.4.21-kernel, with the Eicon-drivers from
> "http://www.melware.de/" with the RH8.0 Diva Server software from
> "http://www.eicon.com/" (a bit tweaked to use the aforementioned
> drivers, instead of the ones shipped with it).  The kernel currently
> also has FreeS/WAN v2.0 in it, but it doesn't seem to be related to
> my problems and it's module wasn't loaded during any of my tests.
> The box is running an "up2date" Redhat 9.  The Eicon card and E100P
> are currently the only cards in the system.
> 
> I'm going to try the ACPI-patch (http://sourceforge.net/projects/acpi/)
> again and see if that changes anything and play a bit with the BIOS,
> but it might be a good idea for someone with more knowledge of the
> internals of kernel and drivers to have a good look at this problem.
> I'm willing to assist in producing the right debugging-info, as I can
> reliably reproduce the problem.
> 
> 
> 
>     Grtz,
> 
>       Oliver
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users