Recently I started getting weird errors. All of a sudden I see the
harddrive of my box glowing steadily and syslog is getting filled (and the
cpu hogged) with these errors:
It seems to start with this line:
Jan 1 03:28:04 kernel: FXO PCI Master abort
Jan 1 03:28:04 last message repeated 12 times
Jan 1 03:28:06 kernel: CI Master abort
Jan 1 03:28:06 kernel: FXO PCI Master abort
and seems to go on forever
Jan 1 12:00:20 kernel: FXO PCI Master abort
Jan 1 12:00:20 last message repeated 168 times
Jan 1 12:00:20 kernel: FXO PCI Master abortCI Master abort
Jan 1 12:00:20 kernel: FXO PCI Master abort
Jan 1 12:00:20 last message repeated 168 times
Jan 1 12:00:20 kernel: FXO PCI Master abortCI Master abort
Jan 1 12:00:20 kernel: FXO PCI Master abort
Jan 1 12:00:20 last message repeated 168 times
What's going on? This is asterisk/zaptel 1.0.3 stable, running on Gentoo
with IOAPIC and LOCAL APIC enabled. The FXO device is a Wildcard X101P.
cat/proc/interrupts:
CPU0
0: 100221473 IO-APIC-edge timer
1: 17 IO-APIC-edge i8042
4: 68502 IO-APIC-edge serial
8: 2 IO-APIC-edge rtc
9: 0 IO-APIC-level acpi
12: 66 IO-APIC-edge i8042
15: 24 IO-APIC-edge ide1
16: 716211 IO-APIC-level 3ware Storage Controller
18: 14610651 IO-APIC-level SysKonnect SK-98xx, eth1
19: 100191376 IO-APIC-level wcfxo
NMI: 0
LOC: 100225869
ERR: 0
MIS: 0
cat /proc/version
Linux version 2.6.9-gentoo-r13 (root@) (gcc version 3.3.4 20040623
(Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)) #1 Sun Jan 2 23:28:22 CET
2005
Thanks!
Remco
Hi, I have the following configuration, which doesn't seem to work, any help much appreciated Linux 2.6.11 used to run asterisk CVS version of zaptel X101P So far, so easy. However, whenever I turn the machine on with the card in, I get FXO PCI Master abort errors. Depending on the way it feels, either these are repeated till /var/log/ is full, or I get one and then the thing hangs. This may, or may not, have something to do with a message Uhhuh. NMI received. Dazed and confused, but trying to continue You probably have a hardware problem with your RAM chips I have tried all 4 combinations of a) stock debian builds of zaptel, and cvs head versions b) an old pentium 2 machine, and a new (ish) P4 mahcine In all cases with the same result. I have also tried the new machine with linux 2.6.8 -- yup -- same result... I've mucked with the IRQ's till they dont conflict.. no change... So, I'm clearly deluded as everybody else seems to have no problem. Can anybody help - what silly thing have I done? Cheers Mark.
Mark Burton
2005-Aug-13 06:24 UTC
[Asterisk-Users] [Asterisk-Dev] Re: FXO PCI Master abort
Dear Zaptel and wcfxo devellopers,
Hi, so far I have had no success moving this issue forward. Carl
Andersson has been kind enough to help build various kernels to try,
but with no success.
So, I have tried to debug the problem directly. So far I have applied
the patch below to wcfxo.c. (on the latest CVS head) This makes my
system stable again (in that I dont have to keep pressing the big red
button).
In principle I can not see how this patch would harm a working system,
and seems to me to be the right thing to do anyway. I would love to
know why not.
However, of course, this does not fix the problem.
Firstly the watchdog never re-starts the DMA engine (even with the
watchdog enabled in zaptel). This means that the driver sits there
"impotent" and in order to recover you have to unload and reload the
module.
Hardly ideal.
Second, of course, I am no nearer finding out why I am getting the
erroneous IRQ in the first place!
Any help much appreciated...
Cheers
Mark.
--- wcfxo.c 2005-08-13 14:16:44.690969912 +0100
+++ wcfxo.c.old 2005-08-13 08:51:00.000000000 +0100
@@ -726,18 +726,11 @@
/* Reset Master and TDM */
outb(0x01, wc->ioaddr + WC_CNTL);
outb(0x01, wc->ioaddr + WC_OPER);
-
- printk("UnMasking IRQ\n");
- outb(0x3f, wc->ioaddr + WC_MASK0);
}
static void wcfxo_stop_dma(struct wcfxo *wc)
{
- /* Enable interrupts (we care about all of them, except the one
that gave us the abort) */
- printk("Masking IRQ's, waiting for watchdog to
restart\n");
- outb(0x2f, wc->ioaddr + WC_MASK0);
-
outb(0x00, wc->ioaddr + WC_OPER);
}
On 2 Aug 2005, at 13:56, Mark Burton wrote:
> [posted here as well as -users as the situation is stranger than I had
> first thought... and I'm running standard parts... ]
>
> Hi, I have the following configuration, which doesn't seem to work,
> any help much appreciated
>
> I am trying to get a X101P FXO card working AT ALL!
> (It has the Ambient chip on it)
>
> All I get is:
>
> FXO PCI Master abort errors.
>
> Depending on the way it feels, either these are repeated till
> /var/log/ is full, or I get one and then the thing hangs.
> This may, or may not, have something to do with a message
>
> Uhhuh. NMI received. Dazed and confused, but trying to continue
> You probably have a hardware problem with your RAM chips
>
> I have tried all combinations of
> Debian builds of Linux 2.4.27, 2.6.8 and 2.6.11
> Debian builds of Zaptel
> CVS builds of Zaptel
>
> I have tried it on an old P2 and a newer P4
>
> I have switch off asterisk to make sure it's not in the asterisk
> configuration...
>
> In all cases with the same result.
>
> I've mucked with the IRQ's till they dont conflict.. no change...
>
> I've tried 2 different cards....
>
> So, I'm clearly deluded as everybody else seems to have no problem.
>
> Can anybody help - what silly thing have I done?
>
> Cheers
>
> Mark.
>
>
>
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users@lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users
>
_______________________________________________
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
Does anyone know how to fix this error message? Is it a fault with the card? The symptoms are excessive disk access and then Asterisk stops responding, a powerdown and restart is generally required to resolve the issue. I'm running 2.6.13.1 with a P4 processor, Slackware Linux. -- John