Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Thanks for the information. Sort of bizarre that someone named a site of this error message. One thing I had done prior to the interrupt was to blacklist the pciehp driver (PCI Hotplug) to prevent it from loading during boot due to some errors. I wonder if the server was trying to access that and couldn't because the software driver had been unloaded. Who knows...
I'll keep an eye on it and post more to this forum if I find additional information.
Well, for a quick update, I had an idea. I read that this can occur on motherboards with APIC that are running with a uniprocessor kernel. The PDSMi Supermicro motherboard can run Pentium Dual Core chips which will run with an SMP kernel as they are two logical processors. However, this particular server is running a Celeron D 3.06GHz processor which, despite the misleading D, only has 1 logical processor and is not dual core.
I noticed on Wikipedia: http://en.wikipedia.org/wiki/Intel_APIC_Architecture that this sort of configuration can cause the interrupts to occur. So I set the noapic and nolapic flags in grub.conf and rebooted. It looks like the interrupt is back this morning though. Only one, as always and apparently several hours after the last boot. Bizarre. I'm running the latest kernel for CentOS 4.3: 2.6.9-34.0.2.EL so am hoping it is just some bug that will get resolved and not indicative of an actual hardware problem.
Let me know if you make any headway on this, and I'll do the same.
Okay, so we know it is not only Intel based. The trouble with a 'spurious' error is that we have no idea where to start looking. Anyway, adding noapic and nolapic to the boot line had no impact, I received the spurious interrupt several hours after boot.
I still think that this has something to do with running a uniprocessor kernel on a board that can handle Pentium D chips. I think the PDSMi board from Supermicro uses APIC and that is what creates these interrupts. Note, I do have a support line opened with Supermicro but haven't made much headway.
Last night I installed an SMP kernel on the machine (even though it only has 1 processor) and rebooted with that kernel. As of this morning, there is no spurious interrupt. So, maybe that is what is going on. Time will tell. I'll wait another day or so, then boot back with a uniprocessor kernel and let all know.
I will be on vacation, up in the moutains for the rest of the week. It is doubtful (and probably a good thing) that I'll have much internet access... but I'll post the state of the server when I get back.
Anyway, I have defeated the spurious interrupt. I actually went ahead and loaded an SMP kernel on the system, waited a day and no interrupt. In addition, I am now seeing proper APIC entries in dmesg:
[ter@neon ~]$ dmesg | grep -i apic
Using APIC driver default
ACPI: MADT (v001 PTLTD APIC 0x06040000 LTP 0x00000000) @ 0x7fee9f0f
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:4 APIC version 20
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
Enabling APIC mode: Flat. Using 0 I/O APICs
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base)
IOAPIC: apic_id 1, version 32, address 0xfec00000, GSI 0-23
ACPI: IOAPIC (id[0x02] address[0xfec10000] gsi_base)
IOAPIC: apic_id 2, version 32, address 0xfec10000, GSI 24-47
ENABLING IO-APIC IRQs
ACPI: Using IOAPIC for interrupt routing
So now the only silly thing is that I have to run an SMP kernel on a motherboard with a Celeron D processor in order to get APIC running okay. Seems mostly harmless though. I should have forked over the extra 50 bucks and bought a Pentium D! Ah well, live and learn.
Anyway thanks for all of the help and suggestions with this issue. I have sent an email to SuperMicro tech support regarding incompatibilities with APIC on their MB and uniprocessor linux kernels so, hopefully, they'll take action and fix it. Other than that, am running SMP fine and will just leave it like that.