Larry Linder wrote:
Nothing seems to prevent the Spurious Interrupt.
Jun 28 08:08:42 engr01 kernel: spurious APIC interrupt on CPU#0, should never
happen.
Jun 28 08:09:57 engr01 kernel: spurious APIC interrupt on CPU#0, should never
happen.
Jun 28 08:11:23 engr01 kernel: spurious APIC interrupt on CPU#0, should never
happen.
Jun 28 08:12:53 engr01 kernel: spurious APIC interrupt on CPU#0, should never
happen.
Jun 28 08:13:59 engr01 last message repeated 2 times
Jun 28 08:15:29 engr01 last message repeated 2 times
Jun 28 08:18:45 engr01 last message repeated 2 times
Jun 28 08:20:15 engr01 last message repeated 3 times
Jun 28 08:22:08 engr01 last message repeated 2 times
Jun 28 08:25:40 engr01 kernel: spurious APIC interrupt on CPU#0, should never
happen.
Jun 28 08:28:46 engr01 last message repeated 2 times
Jun 28 08:30:16 engr01 kernel: spurious APIC interrupt on CPU#0, should never
happen.
Jun 28 08:34:02 engr01 last message repeated 3 times
Jun 28 08:36:57 engr01 kernel: spurious APIC interrupt on CPU#0, should never
happen.
Jun 28 08:39:26 engr01 last message repeated 2 times
There has got to be rational explanation or this is a Kernal bug.
The suggestions, the last change seems to slow it down but not remove the
problem. It appears to happen every minute instead of every couple of
seconds.
Is there some solution to the problem?
Thank You All for suggestions.
Larry Linder
On Friday 25 June 2010 20:04, Isaac wrote:
On Fri, 25 Jun 2010 10:16:36 -0400
Larry Linder <[email protected]> wrote:
Adding "nosmp apm=force noapic api=off pci=noacpi" after a reboot of
system appeared to work on first inspection. Some time after reboot
there are more interrupts and a write to /var/log/messages. Hard on
a disk to say the least.
<snip>
Larry Linder
I wonder if the "api=off" should be "acpi=off". If that's what it
should be, the kernel would just ignore "api=off".
Other things to check would be BIOS revision, are you running the latest?
Also, just cruising through the kernel-paremeters.txt file, I see these
which might be of interest:
I've only played around with noirqbalance and irqpoll myself, but the
rest look like they might affect your problem.
enable_timer_pin_1 [i386,x86-64]
Enable PIN 1 of APIC timer
Can be useful to work around chipset bugs
(in particular on some ATI chipsets).
The kernel tries to set a reasonable default.
disable_timer_pin_1 [i386,x86-64]
Disable PIN 1 of APIC timer
Can be useful to work around chipset bugs.
noirqbalance [IA-32,SMP,KNL] Disable kernel irq balancing
irqfixup [HW]
When an interrupt is not handled search all handlers
for it. Intended to get systems with badly broken
firmware running.
irqpoll [HW]
When an interrupt is not handled search all handlers
for it. Also check all handlers each timer
interrupt. Intended to get systems with badly broken
firmware running.
lapic [IA-32,APIC] Enable the local APIC even if BIOS
disabled it.
maxcpus= [SMP] Maximum number of processors that an SMP kernel
should make use of
noirqdebug [IA-32] Disables the code which attempts to detect and
disable unhandled interrupt sources.
nointroute [IA-64]
nolapic [IA-32,APIC] Do not enable or use the local APIC.
Why can't computer hardware and software stand still for a few years so
we can catch up with it?
Cheers,
Mark
--
Mr. Mark V. Stodola
Digital Systems Engineer
National Electrostatics Corp.
P.O. Box 620310
Middleton, WI 53562-0310 USA
Phone: (608) 831-7600
Fax: (608) 831-9591
