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 <[log in to unmask]> 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