IRQs are messed up. Please Help.

[System123]

Hi

I recently encountered a problem with my OS where after oi enable interrupts it goes into some infinite loop. After stripping my OS down again and adding some code to locate what was going wrong I found out that on my PC after I enable Interrupts the interrupt number 39 (IRQ 7) fires so many times a second that it eats my CPU time.

This problem is only when I run it on my PC all other PC's and emulators work and run my OS perfectly. On other PC's the interrupt 32 (IRQ 0) fires a lot as this is the timer. I was wondering what is IRQ 7, I haven't used it I currently only use IRQ 0 & 1. And why does my PC fire it so often? Its not a fault in my OS, and if it is my computers fault then how come it can run Windows, Linux and Brans kernel(The kernel mine is based on)?

Please Help

[01000101]

If an IRQ is firing rapidly, and you have no idea what it is / or don't need it enabled, then mask that interrupt through the IO-APIC. You shouldn't have "all" interrupts allowed through the IO-APIC's redirection tables. They should all be masked, and then enabled when needed. What is most likely happening, is that you have some interrupt that you have no driver/handler for and you are only ACK'ing the IO-APIC and not the device, therefor it keeps trying to get your attention through an IRQ.

[Combuster]

Maybe it helps to mask the IRQ at the PIC rather than the IOAPIC (especially if don't use the IOAPIC anyway)

[01000101]

Maybe it helps to mask the IRQ at the PIC rather than the IOAPIC (especially if don't use the IOAPIC anyway)

that too.
All the PIC mask bits should be set (masking all interrupts from the PIC) before using the IO-APIC to handle the interrupt routing.

[System123]

Thanks I thought I had already masked them off thats why I was confused. It turns out I had set the code up but I forgot to call it

It works now. Thanks

[jal]

Its not a fault in my OS, and if it is my computers fault then how come it can run Windows, Linux and Brans kernel?

Google for "spurious interrupt", and you'll find sites like this one. Appearently, it is a common problem in at least Linux as well. Personally I've even had bochs generate this interrupt if I didn't handle regular interrupts fast enough. Haven't bothered checking what the background of all this is. Maybe somebody else knows?


JAL

[Mike]

Yeah, I've had the same problem.

So here's the story. Sometimes for various reasons (exactly why I do not know), the PIC needs to trigger a "spurious interrupt". When an interrupt occurs, the interrupt pin of the CPU is pulled high, and then it communicates with the PIC to get the interrupt number. Now, sometimes the interrupt status may be cleared between telling the CPU an interrupt occurred and the CPU asking what interrupt fired. When this happens, the PIC needs to give some response, so it gives IRQ 7.

But what if you have a device on IRQ 7? How do you detect whether you're dealing with a spurious interrupt or a real interrupt? The PIC has an In-Service Register (I believe that's the name). Also known as the ISR. So, when you get interrupt 7 (spurious interrupt on the master) or interrupt 15 (spurious interrupt on the slave), check the ISR's bit in the appropriate PIC. If the bit indicates that no interrupt fired, then you got a spurious interrupt and can move along with life.

Good luck OSDeving!

- Michael (a former OSDever who is trying to get back into it)