The PIC 8259A and spurious interrupts

[James Harris]

In another thread, "wolfgang kern" <now...@never.at> wrote ...

> What would a spurious (hardware generated) interrupt mean ?

That's a brilliant question and a topic on which I cannot find a recent
a.o.d discussion. Hence this new thread. I have an idea or two but need
to check some stuff first and it would be great to hear what others
think. AFAICT spurious interrupts are widely misunderstood but I think
between us all we can bottom out what causes there are for spurious
interrupts and what we should do about them.

> you messed up either with timing or your IRQ-respond code was inable
> to allow nested IRQ,

Are you sure? Apart from very special circumstances involving the PIT
(i.e. timer) and long periods of having interrupts disabled I don't see
how the things you mention could cause a spurious interrupt.

> or more worse you made the IRQ-routine call the
> event-handler before other IRQs were reenabled and accepted.

I don't follow. Could you say a bit more about what you mean there?

James

[Rod Pemberton]

On Fri, 04 Sep 2015 16:47:04 -0400, James Harris <james.h...@gmail.com> wrote:

> In another thread, "wolfgang kern" <now...@never.at> wrote ...

>> What would a spurious (hardware generated) interrupt mean ?
>
> That's a brilliant question and a topic on which I cannot find a recent
> a.o.d discussion.

I wrote some replies early in the day to the thread from which this
was spawned, but I didn't send them out immediately. They may have
some discussion related to this.


Rod Pemberton



--
Just how many texting and calendar apps does humanity need?

[CN]

On 9/4/2015 1:47 PM, James Harris wrote:
> In another thread, "wolfgang kern" <now...@never.at> wrote ...
>
>> What would a spurious (hardware generated) interrupt mean ?
>
> That's a brilliant question and a topic on which I cannot find a recent
> a.o.d discussion. Hence this new thread. I have an idea or two but need
> to check some stuff first and it would be great to hear what others
> think. AFAICT spurious interrupts are widely misunderstood but I think
> between us all we can bottom out what causes there are for spurious
> interrupts and what we should do about them.

A spurious interrupt is a consequence of the x86 platform having
hardware interrupt vectors. So, interrupt delivery becomes non-atomic:

PIC: Hey, CPU, I have an interrupt for you!
(a bit later) CPU: Yeah, which vector?
PIC: Lemme see, uh, vector 39!

Because it's not atomic, someone can make the interrupt non-deliverable
in the meantime. For example, mask it or, in the Local APIC's case,
raise TPR to a higher priority. I think, with the 8259, lowering a
level-triggered interrupt level has the same effect, but I'm not 100%
sure. So, the PIC goes "Lemme see, uh... nevermind!" Except it wishes it
could do that, but there is no "nevermind": by protocol, it has to
report a vector, because the CPU has already committed to interrupting
the code. So, the PIC reports a special "spurious" vector. That's all
there is to it.

What do to about them? The software should ignore spurious interrupts.

[Alexei A. Frounze]

On Friday, September 4, 2015 at 7:26:15 PM UTC-7, CN wrote:
...

> A spurious interrupt is a consequence of the x86 platform having
> hardware interrupt vectors. So, interrupt delivery becomes non-atomic:
>
> PIC: Hey, CPU, I have an interrupt for you!
> (a bit later) CPU: Yeah, which vector?
> PIC: Lemme see, uh, vector 39!
>
> Because it's not atomic, someone can make the interrupt non-deliverable
> in the meantime. For example, mask it or, in the Local APIC's case,
> raise TPR to a higher priority. I think, with the 8259, lowering a
> level-triggered interrupt level has the same effect, but I'm not 100%
> sure. So, the PIC goes "Lemme see, uh... nevermind!" Except it wishes it
> could do that, but there is no "nevermind": by protocol, it has to
> report a vector, because the CPU has already committed to interrupting
> the code. So, the PIC reports a special "spurious" vector. That's all
> there is to it.
>
> What do to about them? The software should ignore spurious interrupts.

That matches my understanding of spurious interrupts. Either an
interrupt request is withdrawn by the I/O device when it's too late
or there's indeed some noise on the input lines that does not correspond
to any actual interrupt request. Either way there isn't anything for
the CPU to do.

Alex

[wolfgang kern]

As CN, Mike and Alex already mentioned: it's a PIC timing issue.
If you disable IRQs for too long then you'll miss events from some
devices and the PIC is still in busy state so it may forget which
vector to report next and use a default one.
__
wolfgang

[James Harris]

"CN" <qmbmn...@pacbell.net> wrote in message
news:msdjoo$kjk$1...@dont-email.me...

> On 9/4/2015 1:47 PM, James Harris wrote:
>> In another thread, "wolfgang kern" <now...@never.at> wrote ...
>>
>>> What would a spurious (hardware generated) interrupt mean ?
>>
>> That's a brilliant question and a topic on which I cannot find a
>> recent
>> a.o.d discussion. Hence this new thread. I have an idea or two but
>> need
>> to check some stuff first and it would be great to hear what others
>> think. AFAICT spurious interrupts are widely misunderstood but I
>> think
>> between us all we can bottom out what causes there are for spurious
>> interrupts and what we should do about them.
>
> A spurious interrupt is a consequence of the x86 platform having
> hardware interrupt vectors. So, interrupt delivery becomes non-atomic:
>
> PIC: Hey, CPU, I have an interrupt for you!
> (a bit later) CPU: Yeah, which vector?
> PIC: Lemme see, uh, vector 39!

I like your antropomorphic way of describing it ... though I am not sure
what you mean in the final statement. I guess you mean to describe
*normal* operation.

An 80x86 CPU issues two interrupt acks to the PIC so I think there is a
bit more to it. Based on the data sheet how about this (again to
describe normal operation):

PIC (after seeing a low-to-high transition on one of its IR lines) Hey,
CPU, I have an interrupt for you (and sets the corresponding bit in its
interrupt request register, IRR)

CPU: Ack

PIC "transfers" the bit from the IRR to the in-service register, ISR
(i.e. it clears the IRR bit back to zero and sets the ISR bit).

CPU: Ack (the second one)

PIC: Here's the 8-bit vector (39 or whatever).

> Because it's not atomic, someone can make the interrupt
> non-deliverable in the meantime. For example, mask it or, in the Local
> APIC's case, raise TPR to a higher priority. I think, with the 8259,
> lowering a level-triggered interrupt level has the same effect, but
> I'm not 100% sure. So, the PIC goes "Lemme see, uh... nevermind!"
> Except it wishes it could do that, but there is no "nevermind": by
> protocol, it has to report a vector, because the CPU has already
> committed to interrupting the code. So, the PIC reports a special
> "spurious" vector. That's all there is to it.

That's good but what specifically would cause a spurious interrupt from
the 8259? Noise, certainly, but what else? In the other thread Mike
wrote

> Of course it could mean many things, but in this case it was a
> hardware
> "feature" of the PIC 8259A which would sometimes assert an interrupt
> on IRQ 7 if there was too much activity on the other lines.

I am not sure whether Mike means PIC too busy or too many requests at
once or something else? If CPU too long not servicing a certain
interrupt (which I think is most likely) why would that cause a spurious
interrupt? I can only think of one potential and off-field case where
that might happen but maybe someone can think of some real examples...?

> What do to about them? The software should ignore spurious interrupts.

Sorry, I didn't simply mean the response but what we should do overall.
For example, the spurious interrupt vector is normally the same as the
lowest priority vector, i.e. IRQ7. If a PIC has its priority
reprogrammed does the spurious interrupt vector change too? That's been
a question in the back of my mind for a while. Now I am pretty sure that
the spurious interrupt vector does *not* change but stays at 7. Anyone
disagree?

As another example, what if we want to distinguish between a real
interrupt on IR7 and a spurious one? The datasheet recommends to check
the ISR but we could be using the IRR and a comment in the Linux source
says that switching between IRR and ISR is very slow. So are there other
ways to distinguish between real and spurious interrupts?

Finally, as mentioned above I think there might be a case involving the
PIT timer wherein we could get a spurious interrupt but still want to
handle its proper source. I'll need to give that some more thought and
get back to you.

James

[James Harris]

"wolfgang kern" <now...@never.at> wrote in message
news:msedci$beg$1...@speranza.aioe.org...

>
> James Harris wrote:
>
>> In another thread, "wolfgang kern" <now...@never.at> wrote ...

...

>>> or more worse you made the IRQ-routine call the
>>> event-handler before other IRQs were reenabled and accepted.
>
>> I don't follow. Could you say a bit more about what you mean there?
>
> As CN, Mike and Alex already mentioned: it's a PIC timing issue.
> If you disable IRQs for too long then you'll miss events from some
> devices and the PIC is still in busy state so it may forget which
> vector to report next and use a default one.

Well, say you are a device that needs a response. You assert your output
IR line. Wouldn't you then wait until you got a response? Why would you
give up waiting and deassert the line? AFAIK, at this level devices
don't time-out their interrupt requests ... but they might do.

I have to say, at least just now, that if a device doesn't time out its
interrupt requests then I don't think the time taken to start servicing
the request would cause a spurious interrupt.

James

[Alexei A. Frounze]

On Saturday, September 5, 2015 at 8:00:06 AM UTC-7, James Harris wrote:
> Well, say you are a device that needs a response. You assert your output
> IR line. Wouldn't you then wait until you got a response? Why would you
> give up waiting and deassert the line? AFAIK, at this level devices
> don't time-out their interrupt requests ... but they might do.

What about devices that issue interrupts at fixed intervals, like a
timer or your sound card chip? E.g. at 1+KHz rate. Should they stick
until their request is serviced? If you are unable to keep up with the
rate, it's a problem anyway. But it's an example of a situation where
waiting buys nothing. I can imagine that the request signal can be
tied to the device clock and just last for a number of cycles. Why not?

Alex

[James Harris]

"Alexei A. Frounze" <alexf...@gmail.com> wrote in message
news:6922f234-d45d-4e76...@googlegroups.com...

That's what I was thinking of wrt the PIT clock. It is not a normal
interrupting device in that it doesn't assert an interrupt request and
then sit and wait to be acknowledged. It simply outputs a square wave
and so as far as the PIC is concerned the IRQ0 signal will be
"deasserted" when the PIT clock switches to the second half of its
cycle.

I have been going through the standard devices to see how they behave
and, AFAICT so far, the PIT timer is unusual. I hadn't thought about
sound cards and really know nothing about them.

*If* the only type of device that can cause a spurious IRQ is a
free-running timer then that helps define the cause of these beasties a
lot. Rather than just a vague idea that a spurious interrupt might occur
if the PIC or CPU is busy or overloaded etc, perhaps we can say:

"a spurious IRQ will be generated if a square-wave timer interrupt is
not acknowledged within half of its cycle time".

Better? I think so.

Incidentally, PIT timer 0 can be changed from mode 3 to mode 2. I have
now found that, contrary to what I thought before, the polarity actually
helps here, rather than hinders, as follows.

In mode 2 a PIT timer will output a high signal most of the time. As the
count changes from 2 to 1 the output signal drops low for one cycle
only. After 1 the counter resets to its loaded value and as it does so
the output signal raises again back up to high. It is this low-to-high
transition that triggers an edge-sensitive interrupt on the PIC. Since
the signal remains high for a long time - about twice as long as in mode
3 - this mode would give us longer to respond before the interrupt is
lost and declared spurious.

All good!

James

[Rod Pemberton]

On Sat, 05 Sep 2015 10:41:55 -0400, James Harris <james.h...@gmail.com> wrote:

> I like your antropomorphic way of describing it ...

s/antropomorphic/anthropomorphic ?


RP

[Rod Pemberton]

On Sat, 05 Sep 2015 10:41:55 -0400, James Harris <james.h...@gmail.com> wrote:

> "CN" <qmbmn...@pacbell.net> wrote in message
> news:msdjoo$kjk$1...@dont-email.me...

>> Of course it could mean many things, but in this case it was a
>> hardware "feature" of the PIC 8259A which would sometimes assert
>> an interrupt on IRQ 7 if there was too much activity on the other
>> lines.
>
> I am not sure whether Mike means PIC too busy or too many requests at
> once or something else?

Feature is in quotes. So, I think he means a known defect,
and not something intentional or designed, like software
"bugs" being a feature ...

I thought those in the U.K. were good with sarcasm.
What happened? :-)

> For example, the spurious interrupt vector is normally the same as
> the lowest priority vector, i.e. IRQ7.

I'm not sure you can reliably make that correlation.
At this point, it seems to be just rumors and speculation
to me, even though it's very plausible that the chip had
a defect.

> If a PIC has its priority reprogrammed does the spurious interrupt
> vector change too? That's been a question in the back of my mind
> for a while. Now I am pretty sure that the spurious interrupt
> vector does *not* change but stays at 7. Anyone disagree?

I don't know.

It depends on what is causing the spurious interrupt. It might
be "locked" to lowest IRQ or it might "follow" IRQ7 with a
change in priority.

Hey, didn't you ask this once before?

You'd probably need to track down the circuit designer who
either designed the defect, or the one who fixed it in the
next version.

Since that's not such a realistic option, the next best thing
would be to find someone who could reliably duplicate the issue.
Then, send them some code to test.

It's possible that this issue has been fixed for many decades
now and is therefore insignificant. There are numerous processor
bugs. Do you plan to "fix" them too? E.g., Pentium math bug,
Cyrix and Pentium halt bugs, etc.


Rod Pemberton

[Alexei A. Frounze]

On Saturday, September 5, 2015 at 11:51:14 AM UTC-7, James Harris wrote:
> I hadn't thought about
> sound cards and really know nothing about them.

They are continuously doing analog to digital and digital to analog
conversions at a fixed (programmable) rate. When a new input sample
is available or when the card can take a new sample from your for
output, you get an interrupt. These could be separate rx and tx
interrupts or one for both. The card usually operates in a DMA mode
and so you get those interrupts for a buffer of samples instead of
for every single one. The DMA almost certainly waits for interrupt
acknowledgement, but the ADC/DAC typically just keeps running even
if you don't handle interrupts and don't restart the DMA. It keeps
playing the same buffer over and over again and whatever comes from
the mic keeps overwriting previous input samples that you didn't
get out in time. A timer is effectively a sound card that operates
not with 16-bit, but with 0-bit samples. :)

Alex

[wolfgang kern]

James Harris wrote:

>>> In another thread, "wolfgang kern" <now...@never.at> wrote ...
> ...
>>>> or more worse you made the IRQ-routine call the
>>>> event-handler before other IRQs were reenabled and accepted.

>>> I don't follow. Could you say a bit more about what you mean there?

>> As CN, Mike and Alex already mentioned: it's a PIC timing issue.
>> If you disable IRQs for too long then you'll miss events from some
>> devices and the PIC is still in busy state so it may forget which
>> vector to report next and use a default one.

> Well, say you are a device that needs a response.
> You assert your output IR line.
> Wouldn't you then wait until you got a response?

Yes, some devices need an EOI or a port-access to release the signal.

> Why would you give up waiting and deassert the line?

Mouse and KBD are an example for this, it releases the IRQ-line only
after port 0x60 is read (or by a reset-cmd which may raise it again).
But the RTCL may stop fireing interrupts if not acknowledged in time.

> AFAIK, at this level devices don't time-out their interrupt requests ...
> but they might do.

> I have to say, at least just now, that if a device doesn't time out its
> interrupt requests then I don't think the time taken to start servicing
> the request would cause a spurious interrupt.

I know only the PIT which time-out it's signal (either square or pulse).

I cant remember where I read the recommendation to set all legacy
IRQs to edge-triggered. But I remember the olde IRQ_9 VGA-retrace
problem where the graphic-card got stuck if the IRQ werent handled
in time.

[James Harris]

"Rod Pemberton" <b...@fasdfrewar.cdm> wrote in message
news:op.x4ikpfi8yfako5@localhost...

> On Sat, 05 Sep 2015 10:41:55 -0400, James Harris
> <james.h...@gmail.com> wrote:
>
>> "CN" <qmbmn...@pacbell.net> wrote in message
>> news:msdjoo$kjk$1...@dont-email.me...

(Mike's words, not CN's, in the next paragraph)

>>> Of course it could mean many things, but in this case it was a
>>> hardware "feature" of the PIC 8259A which would sometimes assert
>>> an interrupt on IRQ 7 if there was too much activity on the other
>>> lines.
>>
>> I am not sure whether Mike means PIC too busy or too many requests at
>> once or something else?
>
> Feature is in quotes. So, I think he means a known defect,
> and not something intentional or designed, like software
> "bugs" being a feature ...

I don't know that it is a bug/defect/feature. From what we have
discussed in this thread it seems that a spurious interrupt would
correctly be generated if an IRQ from the PIT timer was not serviced
until the PIT's output had returned to zero. No bug or failing on the
PIC's part. That would just be the PIC doing what it is supposed to do.

...

>> For example, the spurious interrupt vector is normally the same as
>> the lowest priority vector, i.e. IRQ7.
>
> I'm not sure you can reliably make that correlation.
> At this point, it seems to be just rumors and speculation
> to me, even though it's very plausible that the chip had
> a defect.
>
>> If a PIC has its priority reprogrammed does the spurious interrupt
>> vector change too? That's been a question in the back of my mind
>> for a while. Now I am pretty sure that the spurious interrupt
>> vector does *not* change but stays at 7. Anyone disagree?

I am not sure whether I already pasted this but from the 8259A
datasheet: "In both the edge and level triggered modes the IR inputs
must remain high until after the falling edge of the first INTA. If the
IR input goes low before this time a DEFAULT IR7 will occur when the CPU
acknowledges the interrupt."

WRT which line is used for a spurious IRQ I think that 7 is likely to be
the fixed line for this for these reasons:

* The wording in the datasheet is clear.

* The wording is, frankly, unlikely to be wrong.

* PICs can run in a dynamic priority fashion where the lowest priority
line *changes*. It would be no good if the default line were to change
like that so it is unlikely they would tie the default to the lowest
priority.

So I think now that a spurious IRQ will always appear on line 7
irrespective of any changes in the priority order.

James

[CN]

I think the software masking a pending interrupt before it is accepted
by the CPU.

>> Of course it could mean many things, but in this case it was a hardware
>> "feature" of the PIC 8259A which would sometimes assert an interrupt
>> on IRQ 7 if there was too much activity on the other lines.
>
> I am not sure whether Mike means PIC too busy or too many requests at
> once or something else? If CPU too long not servicing a certain
> interrupt (which I think is most likely) why would that cause a spurious
> interrupt? I can only think of one potential and off-field case where
> that might happen but maybe someone can think of some real examples...?

I don't really think that's a correct understanding of what's happening.
It certainly wasn't in the spec. The 8259 is a very simple state
machine, it doesn't operate in categories of too many of something or
too busy; it simply doesn't have anything that can overflow or become busy.

>> What do to about them? The software should ignore spurious interrupts.
>
> Sorry, I didn't simply mean the response but what we should do overall.
> For example, the spurious interrupt vector is normally the same as the
> lowest priority vector, i.e. IRQ7. If a PIC has its priority
> reprogrammed does the spurious interrupt vector change too? That's been
> a question in the back of my mind for a while. Now I am pretty sure that
> the spurious interrupt vector does *not* change but stays at 7. Anyone
> disagree?

The doc says it is IRQ7, unconditionally.

> As another example, what if we want to distinguish between a real
> interrupt on IR7 and a spurious one? The datasheet recommends to check
> the ISR but we could be using the IRR and a comment in the Linux source
> says that switching between IRR and ISR is very slow. So are there other
> ways to distinguish between real and spurious interrupts?

Not that I know of.

[CN]

On 9/6/2015 1:09 AM, James Harris wrote:

>>>> Of course it could mean many things, but in this case it was a
>>>> hardware "feature" of the PIC 8259A which would sometimes assert
>>>> an interrupt on IRQ 7 if there was too much activity on the other
>>>> lines.
>>>
>>> I am not sure whether Mike means PIC too busy or too many requests at
>>> once or something else?
>>
>> Feature is in quotes. So, I think he means a known defect,
>> and not something intentional or designed, like software
>> "bugs" being a feature ...
>
> I don't know that it is a bug/defect/feature. From what we have
> discussed in this thread it seems that a spurious interrupt would
> correctly be generated if an IRQ from the PIT timer was not serviced
> until the PIT's output had returned to zero. No bug or failing on the
> PIC's part. That would just be the PIC doing what it is supposed to do.

An interesting question, but I think this is all purely theoretical now;
modern hardware doesn't have the original PIT with a wire going to the
original 8259. Both are internal chipset devices. PIT interrupts are
reported to the 8259 using a digital protocol called SERIRQ.

[Rod Pemberton]

On Sun, 06 Sep 2015 04:09:05 -0400, James Harris <james.h...@gmail.com> wrote:

> I am not sure whether I already pasted this but from the 8259A
> datasheet: "In both the edge and level triggered modes the IR inputs
> must remain high until after the falling edge of the first INTA. If the
> IR input goes low before this time a DEFAULT IR7 will occur when the CPU
> acknowledges the interrupt."
>

> [...]

>
> So I think now that a spurious IRQ will always appear on line 7
> irrespective of any changes in the priority order.
>

Of course, the AT has two chained PICs, so IRQ7 for the first
and IRQ15 for the second, then ... Yes?


Rod Pemberton
Sorry for the delay. Textnews went offline. So, I'm just now
picking up the last few days ... It's still offline though.
Reading from AIOE makes a mess of my newsreader. Sigh ...