Are IRQ7 and IRQ15 unreliable?

From the “Building Embedded Systems” Appendix A in the QNX web site.
It is stated that the IRQ7 and IRQ15 are unreliable. Can someone explain
why. Here is a copy of the text.
"On an x86 design, the QNX default startup supports two Programmable
Interrupt Controllers (PICs). These must be 8259-compatible, with the
standard configuration of a secondary 8259 connected to the IRQ2 line of the
primary interrupt controller.

Beware of hanging devices off IRQ7 and IRQ15 on an 8259 chip – these
are generally known as the “glitch interrupts” and can be unreliable."

Rejean Senecal <rsenecal@oerlikon.ca-no-spam> wrote:

From the “Building Embedded Systems” Appendix A in the QNX web site.
It is stated that the IRQ7 and IRQ15 are unreliable. Can someone explain
why. Here is a copy of the text.
"On an x86 design, the QNX default startup supports two Programmable
Interrupt Controllers (PICs). These must be 8259-compatible, with the
standard configuration of a secondary 8259 connected to the IRQ2 line of the
primary interrupt controller.

Beware of hanging devices off IRQ7 and IRQ15 on an 8259 chip – these
are generally known as the “glitch interrupts” and can be unreliable."

It’s because they’re generally known as the glitch interrupts and can be
unreliable :slight_smile:

Seriously, though, I believe that it stems from the design of the 8259 chip,
wherein any interrupt that cannot (for whatever reason) be identified as
originating on a particular IRQ channel are assigned to the last channel.
IRQ 7 is the last channel on the 1st controller, and IRQ 15 is the last
channel on the 2nd controller.

I think that on today’s “modern hardware” you might be safe, but a hardware
expert will need to comment. Or, look at the i8259 datasheet…

Cheers,
-RK

\

Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

Robert Krten <nospam88@parse.com> wrote in article <acjh7b$b4c$1@inn.qnx.com>…

Rejean Senecal <> rsenecal@oerlikon.ca-no-spam> > wrote:
From the “Building Embedded Systems” Appendix A in the QNX web site.
It is stated that the IRQ7 and IRQ15 are unreliable. Can someone explain
why. Here is a copy of the text.
"On an x86 design, the QNX default startup supports two Programmable
Interrupt Controllers (PICs). These must be 8259-compatible, with the
standard configuration of a secondary 8259 connected to the IRQ2 line of the
primary interrupt controller.

Beware of hanging devices off IRQ7 and IRQ15 on an 8259 chip – these
are generally known as the “glitch interrupts” and can be unreliable."


It’s because they’re generally known as the glitch interrupts and can be
unreliable > :slight_smile:

Seriously, though, I believe that it stems from the design of the 8259 chip,
wherein any interrupt that cannot (for whatever reason) be identified as
originating on a particular IRQ channel are assigned to the last channel.
IRQ 7 is the last channel on the 1st controller, and IRQ 15 is the last
channel on the 2nd controller.

I think that on today’s “modern hardware” you might be safe, but a hardware
expert will need to comment. Or, look at the i8259 datasheet…

Well, here is piece of Intel Peripheral Components book, p. 3-177:
“If no interrupt request is present at step 4 of either sequence (i.e. the request was too short
in duration) the 8259A will issue an interrupt level 7. Both the vectoring bytes and the CAS lines
will look like an interrupt level 7 was requested.”

There is the same information for 82C59A-2 on page 3-200.

An interrupt request is executed by raising an IR input (low to high), and holding it high until it
is acknowledged (Pay attention - the CPU has to set INTA pulse twice and only during second pulse
the 8259A releases an 8 bit pointer for interrupt) in Edge Triggered Mode, or just by high level on
an IR input in Level Trigered Mode.

So, if any device in your system put short interrupt request pulse - the interrupt 7
occurs for first interrupt controller, and the interrupt 15 occurs for second one.
Good hardware design is the way to avoid this situation. From other hand, you can run into it under
heavy radio interference, you have to know it and you’ll safe. I don’t think IRQ7 and IRQ15 are
“unreliable”, just they share “glitch interrupt requests” as well. Modern hardware “All-in-chip”
just doesn’t issue wrong requests inside itself, IMO :wink:

I’m surprised by QNX document which covers such specific aspect. (I did not read that appendix yet
:slight_smile:) Good work, guys. Nice to have such documentations. Thanks.

Eduard.
ed1k at ukr dot net


Cheers,
-RK

\

Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at > www.parse.com> .
Email my initials at parse dot com.

ed1k <ed1k@spamerstrap.com> wrote:
: I’m surprised by QNX document which covers such specific aspect. (I did not read that appendix yet
: :slight_smile:) Good work, guys. Nice to have such documentations. Thanks.

Thanks for the nice comment – it’s gratifying to know that the docs do
help! Thanks also to the developers who provided the information (the
developers in the hardware group are especially good at helping us create
the docs).


Steve Reid stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems

On each 8259a chip, if something happens and it doesn’t know what else to do
it generates an interrupt as if it came from it’s IRQ7 (IRQ15 on the second
PIC).

I have had no problems with using these interrupts. The software driver
must be smart enough to handle being triggered from an interrupt that didn’t
really happen. Most hardware can be queried from it’s driver without any
harm if there wasn’t an interrupt. Some older hardware can’t.

BTW, the same is absolutely true when PCI devices share an interrupt, so
most PCI hardware will handle this scenario correctly.

“Robert Krten” <nospam88@parse.com> wrote in message
news:acjh7b$b4c$1@inn.qnx.com

Rejean Senecal <> rsenecal@oerlikon.ca-no-spam> > wrote:
From the “Building Embedded Systems” Appendix A in the QNX web site.
It is stated that the IRQ7 and IRQ15 are unreliable. Can someone explain
why. Here is a copy of the text.
"On an x86 design, the QNX default startup supports two Programmable
Interrupt Controllers (PICs). These must be 8259-compatible, with the
standard configuration of a secondary 8259 connected to the IRQ2 line of
the
primary interrupt controller.

Beware of hanging devices off IRQ7 and IRQ15 on an 8259 chip –
these
are generally known as the “glitch interrupts” and can be unreliable."


It’s because they’re generally known as the glitch interrupts and can be
unreliable > :slight_smile:

Seriously, though, I believe that it stems from the design of the 8259
chip,
wherein any interrupt that cannot (for whatever reason) be identified as
originating on a particular IRQ channel are assigned to the last channel.
IRQ 7 is the last channel on the 1st controller, and IRQ 15 is the last
channel on the 2nd controller.

I think that on today’s “modern hardware” you might be safe, but a
hardware
expert will need to comment. Or, look at the i8259 datasheet…

Cheers,
-RK

\

Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at > www.parse.com> .
Email my initials at parse dot com.

“Bill Caroselli (Q-TPS)” wrote:

On each 8259a chip, if something happens and it doesn’t know what else to do
it generates an interrupt as if it came from it’s IRQ7 (IRQ15 on the second
PIC).

Instead of rewriting Eduard’s message, a copy and paste would have been faster.

Michel Belanger

Michel Belanger <micbel@videotron.ca> wrote in article <3CEFA1A2.C975BFF2@videotron.ca>…

“Bill Caroselli (Q-TPS)” wrote:

On each 8259a chip, if something happens and it doesn’t know what else to do
it generates an interrupt as if it came from it’s IRQ7 (IRQ15 on the second
PIC).

Instead of rewriting Eduard’s message, a copy and paste would have been faster.

Michel, that was Robert’s message originally in this thread. I only tried to say more, and Bill did
as well :wink:
Cheers,

Eduard.
ed1k at ukr dot net

I would also say that if two people start composing a reply at the same time
to the same message they will have no way of knowing that someone has
replied as well. This has happened to me on occasion. You’ll notice that
both replies are to the same message so there’s no evidence to suggest that
either of these men read each other’s replies first.

cheers,

Kris

“Michel Belanger” <micbel@videotron.ca> wrote in message
news:3CEFA1A2.C975BFF2@videotron.ca

“Bill Caroselli (Q-TPS)” wrote:

On each 8259a chip, if something happens and it doesn’t know what else
to do
it generates an interrupt as if it came from it’s IRQ7 (IRQ15 on the
second
PIC).

Instead of rewriting Eduard’s message, a copy and paste would have been
faster.

Michel Belanger

Also, some news clients will queue posted messages and send them at a later
time.

“Kris Warkentin” <kewarken@qnx.com> wrote in message
news:actpbi$doi$1@nntp.qnx.com

I would also say that if two people start composing a reply at the same
time
to the same message they will have no way of knowing that someone has
replied as well. This has happened to me on occasion. You’ll notice that
both replies are to the same message so there’s no evidence to suggest
that
either of these men read each other’s replies first.