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
Brancaleoni Matteo
2003-Jun-25 13:18 UTC
[Asterisk-Users] Possible solution to Zaptel panics
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@lists.digium.com > http://lists.digium.com/mailman/listinfo/asterisk-users
I've had problems with RedHat 9 and Asterisk... You might want to try downgrading to RedHat 8 or using another distribution. (I think the problems might be related to the NPTL threads stuff.) Jared On Wed, 2003-06-25 at 13:52, The Traveller wrote:> 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@lists.digium.com > http://lists.digium.com/mailman/listinfo/asterisk-users