Page 1 of 2
IRQ 7 fires
Posted: Sat Sep 16, 2006 4:16 am
by ces_mohab
Accidentally I added a small code to my irq handler
Code: Select all
if (handler)
{
handler(r);
}
else
printf("Unhandled IRQ %d\n",r->int_no-32) ;
And I got several IRQ 7 interrupts occur on system start up and my kernel runs normally. When I tested my kernel on real machine this irqs didn't happen. Does any body know what is IRQ7 for and why this interrupts occur in boches only?
???
Re:IRQ 7 fires
Posted: Sat Sep 16, 2006 4:50 am
by bluecode
Irq7 is normally the parallel port interrupt. Besides from that I'm also getting these only in bochs (without using the parallel port). I have already tried to find out why bochs fires these irq's, but the bochslog left me clueless.
Re:IRQ 7 fires
Posted: Sat Sep 16, 2006 4:56 am
by Candy
Google for "spurious interrupt"
Re:IRQ 7 fires
Posted: Sat Sep 16, 2006 5:11 am
by Brendan
Hi,
A faster way might be to search these forums until you find
this post about spurious IRQ 7...
Cheers,
Brendan
Re:IRQ 7 fires
Posted: Sat Sep 16, 2006 6:16 am
by Candy
I'm hereby going to vote to make google a generic verb
Re:IRQ 7 fires
Posted: Sat Sep 16, 2006 12:35 pm
by ces_mohab
I'm hereby going to vote to make google a generic verb
Has google become a verb ?
Any way spurious interrupts are unwanted and handled by simply iret. but how to detect a spurious interrupt ? and do I need to send EOI aor not?
does this code (from Bochs or me thread)detect spurious interrupts correctly . It worked well!
Code: Select all
mov al, 03h ; PIC.OCW3 set function to read ISR (In Service Register)
out 23h, al ; write to PIC.OCW3
in al, 20h ; read ISR
test al, 80h ; if the in-service register does not have IR7 bit set
jz short @RETURN ; this would be a spurious interrupt.
Re:IRQ 7 fires
Posted: Sat Sep 16, 2006 1:47 pm
by Kemp
Has google become a verb ?
We all use it as one. I don't know what their position on it is, I know Adobe had a go at magazines and stuff that used Photoshop as a verb, ie "That picture has been photoshopped"
Re:IRQ 7 fires
Posted: Sat Sep 16, 2006 3:45 pm
by gaf
Has google become a verb ?
At least it has made it to the vernerable Oxford English Dictionary. You should however be carefull using it in the more general sense as Candy did lest you might receive a cease and desist letter from the company..
BBC - Google calls in the 'language police'
cheers,
gaf
Re:IRQ 7 fires
Posted: Sat Sep 16, 2006 4:33 pm
by Ryu
ces_mohab wrote:
Any way spurious interrupts are unwanted and handled by simply iret. but how to detect a spurious interrupt ? and do I need to send EOI aor not?
You pretty much answered your own question there, when suprious interrupt occurs you just want to do an
iretd without sending EOI.
ces_mohab wrote:
does this code (from Bochs or me thread)detect spurious interrupts correctly . It worked well!
I went through a rough ride those few days stripping my code to solve whats wrong (which is why the topic was "Bochs or me?"). The spurious guard I had there is not needed, Brendan has pointed out that if interrupts are disabled even NMI's can't fire which the guard was purposely there to prevent nesting spurious interrupts, but nevered needed since the routine is installed as an interrupt gate. So basically, that should be all you need, for the mutex it was there to prevent multi-processors from reentry, if that happends one must be a spurious, but then I'm uncertain if that can actually happend on multi-processors.
Re:IRQ 7 fires
Posted: Sun Sep 17, 2006 12:37 am
by Brendan
Hi,
Ryu wrote:So basically, that should be all you need, for the mutex it was there to prevent multi-processors from reentry, if that happends one must be a spurious, but then I'm uncertain if that can actually happend on multi-processors.
The PIC chips aren't designed to handle multiple CPUs. To be honest, I'm not sure if an IRQ from the PIC would go to all CPUs at the same time (which would need to be prevented), or if it'd go to the BSP (boot CPU) only In any case, I'd completely disable the PIC chips and use the I/O APIC/s instead.
In rare cases (multi-CPU systems with broken or unusable I/O APICs, chipsets or BIOSs) it's much easier to tell the owners that their computer is broken (or more accurately, it's hard enough writing code that works on correct hardware without trying to write code that works on all possible combinations of broken hardware)....
Cheers,
Brendan
Re:IRQ 7 fires
Posted: Sun Sep 17, 2006 9:39 am
by Candy
ces_mohab wrote:
Any way spurious interrupts are unwanted and handled by simply iret. but how to detect a spurious interrupt ? and do I need to send EOI aor not?
does this code (from Bochs or me thread)detect spurious interrupts correctly . It worked well!
Yes, that's exactly what a spurious interrupt is. It's your cpu being just too slow in asking which interrupt line is high. The line went down in the meantime so the PIC can't figure out which line to signal as interrupt. It then sends you the vector for irq7 on itself, from which you can test whether actually irq7 fired or not. If it actually fired, its "in service" bit is high. If its low, the interrupt didn't actually fire and the pic won't need an EOI (since you just figured out it wasn't active).
Re:IRQ 7 fires
Posted: Sun Sep 17, 2006 11:24 am
by ces_mohab
But when I forced an interupt
Code: Select all
__asm__ __volatile__( "int %0" :: "i" (0x27) ) ;
This interupt was handled as spurious ???
Re:IRQ 7 fires
Posted: Sun Sep 17, 2006 11:46 am
by Candy
ces_mohab wrote:
But when I forced an interupt
Code: Select all
__asm__ __volatile__( "int %0" :: "i" (0x27) ) ;
This interupt was handled as spurious ???
Because it is.
A spurious interrupt is invoking a hardware interrupt handler - without hardware interrupt. Giving a software interrupt doesn't count.
Re:IRQ 7 fires
Posted: Sun Sep 17, 2006 12:26 pm
by ces_mohab
Candy wrote:
Because it is.
A spurious interrupt is invoking a hardware interrupt handler - without hardware interrupt. Giving a software interrupt doesn't count.
Then I changed my mind, not all spurious interrupts are unwanted, as a software interrupt is welcomed ::)
Thanks all
Re:IRQ 7 fires
Posted: Sun Sep 17, 2006 1:37 pm
by DynatOS
ces_mohab wrote:
Then I changed my mind, not all spurious interrupts are unwanted, as a software interrupt is welcomed ::)
Thanks all
This is where some confusion is created by using the term "interrupt" for the entire interrupt mechansim.
To be more specific, and IIRC... an
Interrupt is hardware triggered. An
Exception is software triggered. If a program triggers an Exception (INT XXh) against an ISR that is expected to handle just Interrupts, it should be ignored.
Rule of Thumb for ISR design
-Interrupt (hardware) Handler: Deny spurious triggers
-Exception (software) Handler: Accept spurious triggers (essence of a software interrupt), do some more work to determine validity of Exception
Hope this clarifies a few things for you