hello,

this is probably a silly question.  however, i haven't found explicit
information on the web and i need straight forward clarification.

question 1:  obviously, if the PIC is initialized to require manual EOI, the
PIC must be acknowledged by sending EOI from the hardware interrupt handler.
however, i'm not sure if this is always required or only required if higher
priority hardware interrupts are to be serviced (nested). what is required
for either condition?

question 2:  do cpu exception handlers need to send and EOI to the PIC?  i
would think not, and may cause problems i would think.  i'm wondering
because i saw the unsubstantiated usage as such.

question 3:  the same question at question 2 only regarding software
interrupts called by INT n.

thanks,
bryan

"Bryan Bullard" <the_bullards@sbcglobal.net> wrote in message
news:xb28b.102$Vd1.33@newssvr24.news.prodigy.com...
> hello,
>
> this is probably a silly question.  however, i haven't found explicit
> information on the web and i need straight forward clarification.
>
> question 1:  obviously, if the PIC is initialized to require manual EOI,
the
> PIC must be acknowledged by sending EOI from the hardware interrupt
handler.
> however, i'm not sure if this is always required or only required if
higher
> priority hardware interrupts are to be serviced (nested). what is required
> for either condition?

Always required. The difference is when you send an EOI. When you want to
allow higher-priority interrupts to be serviced, you do it immediately so
your interrupt routine can be interrupted. You also need to set IF=1.

> question 2:  do cpu exception handlers need to send and EOI to the PIC?  i
> would think not, and may cause problems i would think.  i'm wondering
> because i saw the unsubstantiated usage as such.

No. Most exceptions generated by the CPU do not go through the PIC, so
sending EOI would confuse the PIC and may cause you to lose valid
interrupts. I believe one of the FPU exceptions (7??) used to require EOI
because it used to vector through the PIC, but I'm not sure how that's
changed with on-chip FP units. I *think* you still have to EOI for that. The
Intel Architecture manuals and/or APIC manual may have more information.

> question 3:  the same question at question 2 only regarding software
> interrupts called by INT n.
>
> thanks,
> bryan

Never EOI on software interrupts. EOI is just a handshake to tell the PIC
that you got the interrupt and are processing it. If you're in a software
interrupt or exception (CPU-generated interrupt), the PIC is not a part of
the picture. The PIC only handles external interrupts.

-Matt

"Matt Taylor" <para@tampabay.rr.com> wrote in message
news:Lt58b.35418$875.1539389@twister.tampabay.rr.com...

thanks matt.
-bryan

> "Bryan Bullard" <the_bullards@sbcglobal.net> wrote in message
> news:xb28b.102$Vd1.33@newssvr24.news.prodigy.com...
> > hello,
> >
> > this is probably a silly question.  however, i haven't found explicit
> > information on the web and i need straight forward clarification.
> >
> > question 1:  obviously, if the PIC is initialized to require manual EOI,
> the
> > PIC must be acknowledged by sending EOI from the hardware interrupt
> handler.
> > however, i'm not sure if this is always required or only required if
> higher
> > priority hardware interrupts are to be serviced (nested). what is
required
> > for either condition?
>
> Always required. The difference is when you send an EOI. When you want to
> allow higher-priority interrupts to be serviced, you do it immediately so
> your interrupt routine can be interrupted. You also need to set IF=1.
>
> > question 2:  do cpu exception handlers need to send and EOI to the PIC?
i
> > would think not, and may cause problems i would think.  i'm wondering
> > because i saw the unsubstantiated usage as such.
>
> No. Most exceptions generated by the CPU do not go through the PIC, so
> sending EOI would confuse the PIC and may cause you to lose valid
> interrupts. I believe one of the FPU exceptions (7??) used to require EOI
> because it used to vector through the PIC, but I'm not sure how that's
> changed with on-chip FP units. I *think* you still have to EOI for that.
The
> Intel Architecture manuals and/or APIC manual may have more information.
>
> > question 3:  the same question at question 2 only regarding software
> > interrupts called by INT n.
> >
> > thanks,
> > bryan
>
> Never EOI on software interrupts. EOI is just a handshake to tell the PIC
> that you got the interrupt and are processing it. If you're in a software
> interrupt or exception (CPU-generated interrupt), the PIC is not a part of
> the picture. The PIC only handles external interrupts.
>
> -Matt
>
>

> > question 2:  do cpu exception handlers need to send and EOI to the PIC?
i
> > would think not, and may cause problems i would think.  i'm wondering
> > because i saw the unsubstantiated usage as such.
>
> No. Most exceptions generated by the CPU do not go through the PIC, so
> sending EOI would confuse the PIC and may cause you to lose valid
> interrupts. I believe one of the FPU exceptions (7??) used to require EOI
> because it used to vector through the PIC, but I'm not sure how that's
> changed with on-chip FP units. I *think* you still have to EOI for that.
The
> Intel Architecture manuals and/or APIC manual may have more information.

CPUs with on-chip FPU determine the way of raising the FP fault  by CR0.NE
(bit 5) value. When it's clear, ints are handled in MS-DOS style (that is,
via PIC). When set, they're handled in native (internal) way. See IA-32
maunal, Vol.3, Chap. 2.5 and Vol. 1, App. D for more info.

Ivan