[Asterisk-Users] Possible solution to Zaptel panics

[The Traveller]

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