IRQ 7 fires

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
User avatar
ces_mohab
Member
Member
Posts: 77
Joined: Wed Oct 18, 2006 3:08 am

IRQ 7 fires

Post 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?
???
To write an OS you need 2 minds one for coding and other for debugging.
bluecode

Re:IRQ 7 fires

Post 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.
User avatar
Candy
Member
Member
Posts: 3882
Joined: Tue Oct 17, 2006 11:33 pm
Location: Eindhoven

Re:IRQ 7 fires

Post by Candy »

Google for "spurious interrupt"
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re:IRQ 7 fires

Post by Brendan »

Hi,

A faster way might be to search these forums until you find this post about spurious IRQ 7... :)


Cheers,

Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
User avatar
Candy
Member
Member
Posts: 3882
Joined: Tue Oct 17, 2006 11:33 pm
Location: Eindhoven

Re:IRQ 7 fires

Post by Candy »

I'm hereby going to vote to make google a generic verb :)
User avatar
ces_mohab
Member
Member
Posts: 77
Joined: Wed Oct 18, 2006 3:08 am

Re:IRQ 7 fires

Post 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.
:P
To write an OS you need 2 minds one for coding and other for debugging.
Kemp

Re:IRQ 7 fires

Post 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"
User avatar
gaf
Member
Member
Posts: 349
Joined: Thu Oct 21, 2004 11:00 pm
Location: Munich, Germany

Re:IRQ 7 fires

Post 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
Ryu

Re:IRQ 7 fires

Post 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.
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re:IRQ 7 fires

Post 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
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
User avatar
Candy
Member
Member
Posts: 3882
Joined: Tue Oct 17, 2006 11:33 pm
Location: Eindhoven

Re:IRQ 7 fires

Post 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).
User avatar
ces_mohab
Member
Member
Posts: 77
Joined: Wed Oct 18, 2006 3:08 am

Re:IRQ 7 fires

Post by ces_mohab »

But when I forced an interupt

Code: Select all

__asm__ __volatile__( "int %0" :: "i" (0x27) ) ;
This interupt was handled as spurious ???
To write an OS you need 2 minds one for coding and other for debugging.
User avatar
Candy
Member
Member
Posts: 3882
Joined: Tue Oct 17, 2006 11:33 pm
Location: Eindhoven

Re:IRQ 7 fires

Post 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.
User avatar
ces_mohab
Member
Member
Posts: 77
Joined: Wed Oct 18, 2006 3:08 am

Re:IRQ 7 fires

Post 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
To write an OS you need 2 minds one for coding and other for debugging.
DynatOS

Re:IRQ 7 fires

Post 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 :)
Post Reply