Re: More on Spurious Interrupt
Forgot most important thing. Kernal boot parameters kernel /vmlinuz-2.6.18-194.3.1.el5 ro root=LABEL=/ rhgb quiet nosmp noapic apm=force noapic apci=off pci=noacpi There are two that are redundant. Thank You Larry Linder On Monday 28 June 2010 09:07, Alan Bartlett wrote: > On 28 June 2010 13:52, 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? > > Would you clarify your kernel boot parameters, please? > > I would test the following four lines (and further permutations > thereof, if required) -- > > nosmp noapic nolapic > > nosmp noapic nolapic noirqbalance > > nosmp noapic nolapic irqpoll > > nosmp noapic nolapic irqfixup > > Alan.
Re: More on Spurious Interrupt
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 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. 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
Re: More on Spurious Interrupt
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 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. > > > > > 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".
Re: More on Spurious Interrupt
On Fri, 25 Jun 2010 10:16:36 -0400 Larry Linder 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. > 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".
Re: More on Spurious Interrupt
Some of these boxes are running VMware. On one box we shut down applications running VM ware and killed the daemons that start up at boot up. We still get spurious interrupts at about the same time interval. The problem with VM was interesting. Since this is a Linux install running VM ware to support some Windows apps. I would not think it is applicable. The cloks speed of this processor is 1.7G equivalent but it is a single core. Thanks Larry On Friday 25 June 2010 10:33, Mark Stodola wrote: > Is this at all related with using a VM? > > Is this of any help? http://bugs.centos.org/view.php?id=2189 > > Cheers, > Mark > > Larry Linder 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. > > What we see is: > > Jun 25 09:31:47 engr01 kernel: spurious APIC interrupt on CPU#0, should > > never happen. > > Jun 25 09:32:55 engr01 kernel: spurious APIC interrupt on CPU#0, should > > never happen. > > Jun 25 09:34:37 engr01 kernel: spurious APIC interrupt on CPU#0, should > > never happen. > > Jun 25 09:36:03 engr01 kernel: spurious APIC interrupt on CPU#0, should > > never happen. > > Jun 25 09:41:35 engr01 kernel: spurious APIC interrupt on CPU#0, should > > never happen. > > Jun 25 09:43:42 engr01 kernel: spurious APIC interrupt on CPU#0, should > > never happen. > > Jun 25 09:45:37 engr01 last message repeated 2 times > > Jun 25 09:46:56 engr01 last message repeated 2 times > > Jun 25 09:48:12 engr01 kernel: spurious APIC interrupt on CPU#0, should > > never happen. > > Jun 25 09:50:09 engr01 kernel: spurious APIC interrupt on CPU#0, should > > never happen. > > Jun 25 09:52:07 engr01 last message repeated 2 times > > Jun 25 09:54:36 engr01 kernel: spurious APIC interrupt on CPU#0, should > > never happen. > > Jun 25 10:01:00 engr01 last message repeated 4 times > > Jun 25 10:02:47 engr01 last message repeated 3 times > > Jun 25 10:04:53 engr01 last message repeated 2 times > > > > There does not seem to be much on the net that offers any advice or ??? > > > > Need to solve this problem before I have another disk to swap out. > > > > It is unique to a single core processor installation, as we have looked > > for this same activity on several boxes with multi core processor and it > > doesn't happen. > > > > Larry Linder
Re: More on Spurious Interrupt
On Friday 25 June 2010 10:33, Mark Stodola wrote: > Is this at all related with using a VM? Yes we have VM installed on these systems! A number of users on internet suspect a problem with older mother boards. I will shut down VM on a couple of boxes and see. Thanks Larry > Is this of any help? http://bugs.centos.org/view.php?id=2189 > > Cheers, > Mark > > Larry Linder 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. > > What we see is: > > Jun 25 09:31:47 engr01 kernel: spurious APIC interrupt on CPU#0, should > > never happen. > > Jun 25 09:32:55 engr01 kernel: spurious APIC interrupt on CPU#0, should > > never happen. > > Jun 25 09:34:37 engr01 kernel: spurious APIC interrupt on CPU#0, should > > never happen. > > Jun 25 09:36:03 engr01 kernel: spurious APIC interrupt on CPU#0, should > > never happen. > > Jun 25 09:41:35 engr01 kernel: spurious APIC interrupt on CPU#0, should > > never happen. > > Jun 25 09:43:42 engr01 kernel: spurious APIC interrupt on CPU#0, should > > never happen. > > Jun 25 09:45:37 engr01 last message repeated 2 times > > Jun 25 09:46:56 engr01 last message repeated 2 times > > Jun 25 09:48:12 engr01 kernel: spurious APIC interrupt on CPU#0, should > > never happen. > > Jun 25 09:50:09 engr01 kernel: spurious APIC interrupt on CPU#0, should > > never happen. > > Jun 25 09:52:07 engr01 last message repeated 2 times > > Jun 25 09:54:36 engr01 kernel: spurious APIC interrupt on CPU#0, should > > never happen. > > Jun 25 10:01:00 engr01 last message repeated 4 times > > Jun 25 10:02:47 engr01 last message repeated 3 times > > Jun 25 10:04:53 engr01 last message repeated 2 times > > > > There does not seem to be much on the net that offers any advice or ??? > > > > Need to solve this problem before I have another disk to swap out. > > > > It is unique to a single core processor installation, as we have looked > > for this same activity on several boxes with multi core processor and it > > doesn't happen. > > > > Larry Linder
Re: More on Spurious Interrupt
Is this at all related with using a VM? Is this of any help? http://bugs.centos.org/view.php?id=2189 Cheers, Mark Larry Linder 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. What we see is: Jun 25 09:31:47 engr01 kernel: spurious APIC interrupt on CPU#0, should never happen. Jun 25 09:32:55 engr01 kernel: spurious APIC interrupt on CPU#0, should never happen. Jun 25 09:34:37 engr01 kernel: spurious APIC interrupt on CPU#0, should never happen. Jun 25 09:36:03 engr01 kernel: spurious APIC interrupt on CPU#0, should never happen. Jun 25 09:41:35 engr01 kernel: spurious APIC interrupt on CPU#0, should never happen. Jun 25 09:43:42 engr01 kernel: spurious APIC interrupt on CPU#0, should never happen. Jun 25 09:45:37 engr01 last message repeated 2 times Jun 25 09:46:56 engr01 last message repeated 2 times Jun 25 09:48:12 engr01 kernel: spurious APIC interrupt on CPU#0, should never happen. Jun 25 09:50:09 engr01 kernel: spurious APIC interrupt on CPU#0, should never happen. Jun 25 09:52:07 engr01 last message repeated 2 times Jun 25 09:54:36 engr01 kernel: spurious APIC interrupt on CPU#0, should never happen. Jun 25 10:01:00 engr01 last message repeated 4 times Jun 25 10:02:47 engr01 last message repeated 3 times Jun 25 10:04:53 engr01 last message repeated 2 times There does not seem to be much on the net that offers any advice or ??? Need to solve this problem before I have another disk to swap out. It is unique to a single core processor installation, as we have looked for this same activity on several boxes with multi core processor and it doesn't happen. Larry Linder -- 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
More on Spurious Interrupt
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. What we see is: Jun 25 09:31:47 engr01 kernel: spurious APIC interrupt on CPU#0, should never happen. Jun 25 09:32:55 engr01 kernel: spurious APIC interrupt on CPU#0, should never happen. Jun 25 09:34:37 engr01 kernel: spurious APIC interrupt on CPU#0, should never happen. Jun 25 09:36:03 engr01 kernel: spurious APIC interrupt on CPU#0, should never happen. Jun 25 09:41:35 engr01 kernel: spurious APIC interrupt on CPU#0, should never happen. Jun 25 09:43:42 engr01 kernel: spurious APIC interrupt on CPU#0, should never happen. Jun 25 09:45:37 engr01 last message repeated 2 times Jun 25 09:46:56 engr01 last message repeated 2 times Jun 25 09:48:12 engr01 kernel: spurious APIC interrupt on CPU#0, should never happen. Jun 25 09:50:09 engr01 kernel: spurious APIC interrupt on CPU#0, should never happen. Jun 25 09:52:07 engr01 last message repeated 2 times Jun 25 09:54:36 engr01 kernel: spurious APIC interrupt on CPU#0, should never happen. Jun 25 10:01:00 engr01 last message repeated 4 times Jun 25 10:02:47 engr01 last message repeated 3 times Jun 25 10:04:53 engr01 last message repeated 2 times There does not seem to be much on the net that offers any advice or ??? Need to solve this problem before I have another disk to swap out. It is unique to a single core processor installation, as we have looked for this same activity on several boxes with multi core processor and it doesn't happen. Larry Linder
