Interrupt Handler

QNX Newsgroups (Archives) qdn.public.qnx4
1

I have attached an interrupt handler to an IRQL (9) using
qnx_hint_attach but the interrupt handler never gets called. The
interrupt is generated from an external PCI board. I’m positive the
board is correctly generating interrupts because I have probed its
IRQL. I’m fairly sure the interrupt handler works correctly because I
have tested it with IRQL -1 which calls the interrupt handler every
50ms. So, there seems to be a problem between the hardware interrupt
being generated and my interrupt handler being called - which leads me
to the OS. I have followed the examples that are contained in the
documentation and they work fine except for PCI generated interrupts.

Do I have to do anything special to tell the OS that the interrupt is
being generated from a PCI board?

Do I have to do any other interrupt setup other than qnx_hint_attach and
masking the interrupts on?

Any help would be appreciated.

2

Steve <stlang@vt.edu> wrote:

Interrupt 9 is the re-directed interrupt 2, do to the cascaded secondary
pic on the pc architecture. This can cause problems on the hardware side.
Can you put your card on some other irq? (If this is configured by the
PCI bios, you might try marking irq 9 as reserved for ISA, and then it
won’t assign it to a PCI card.)

I have attached an interrupt handler to an IRQL (9) using
qnx_hint_attach but the interrupt handler never gets called. The
interrupt is generated from an external PCI board. I’m positive the
board is correctly generating interrupts because I have probed its
IRQL. I’m fairly sure the interrupt handler works correctly because I
have tested it with IRQL -1 which calls the interrupt handler every
50ms. So, there seems to be a problem between the hardware interrupt
being generated and my interrupt handler being called - which leads me
to the OS. I have followed the examples that are contained in the
documentation and they work fine except for PCI generated interrupts.

Do I have to do anything special to tell the OS that the interrupt is
being generated from a PCI board?

No.

Do I have to do any other interrupt setup other than qnx_hint_attach and
masking the interrupts on?

No – in fact you don’t even have to explicitly unmask the interrupt, the
OS does that as well.

-David

3

Yes, IRQ 9 is assigned by the bios and determined by reading the PCI
configuration space.

I just tried to reserve IRQ 9 for ISA in the BIOS. This left me with only 1
IRQ for PCI which is presently being used by a network card. The remainder of
the IRQ are all reserved for ISA so I assumed that I had to toggle one of the
other IRQs to PCI. I then tried switching (one at at time) all the other
available IRQs to PCI and rebooting the machine. Every other configuration
caused the BIOS to not assign an IRQ to my board at all! I also received
errors on startup such as: “Unable to map extended memory”, and Floating
point exceptions. The only configuration that actually starts the machine is
when IRQ 9 is set to handle PCI devices.

Any other thoughts?

David Gibbs wrote:

Steve <> stlang@vt.edu> > wrote:

Interrupt 9 is the re-directed interrupt 2, do to the cascaded secondary
pic on the pc architecture. This can cause problems on the hardware side.
Can you put your card on some other irq? (If this is configured by the
PCI bios, you might try marking irq 9 as reserved for ISA, and then it
won’t assign it to a PCI card.)

I have attached an interrupt handler to an IRQL (9) using
qnx_hint_attach but the interrupt handler never gets called. The
interrupt is generated from an external PCI board. I’m positive the
board is correctly generating interrupts because I have probed its
IRQL. I’m fairly sure the interrupt handler works correctly because I
have tested it with IRQL -1 which calls the interrupt handler every
50ms. So, there seems to be a problem between the hardware interrupt
being generated and my interrupt handler being called - which leads me
to the OS. I have followed the examples that are contained in the
documentation and they work fine except for PCI generated interrupts.

Do I have to do anything special to tell the OS that the interrupt is
being generated from a PCI board?

No.

Do I have to do any other interrupt setup other than qnx_hint_attach and
masking the interrupts on?

No – in fact you don’t even have to explicitly unmask the interrupt, the
OS does that as well.

-David

4

What exactly does this mean? The -T1 option should be used when compiling
modules, but not used when the modules are linked?

Andrej Lucny wrote:

Maybe, you haven’t used option -T1 for compiling only.

Andy

Steve <> stlang@vt.edu> > wrote:
I have attached an interrupt handler to an IRQL (9) using
qnx_hint_attach but the interrupt handler never gets called. The
interrupt is generated from an external PCI board. I’m positive the
board is correctly generating interrupts because I have probed its
IRQL. I’m fairly sure the interrupt handler works correctly because I
have tested it with IRQL -1 which calls the interrupt handler every
50ms. So, there seems to be a problem between the hardware interrupt
being generated and my interrupt handler being called - which leads me
to the OS. I have followed the examples that are contained in the
documentation and they work fine except for PCI generated interrupts.

Do I have to do anything special to tell the OS that the interrupt is
being generated from a PCI board?

Do I have to do any other interrupt setup other than qnx_hint_attach and
masking the interrupts on?

Any help would be appreciated.

5

Hmm, right now I compile and link with that option because my ISR is within my
driver. Any other ideas?

Mario Charest wrote:

You only need to link with -T1. For compile it’s useless.

“Steve” <> stlang@vt.edu> > wrote in message news:> 3A14F4FE.166E32D3@vt.edu> …
What exactly does this mean? The -T1 option should be used when compiling
modules, but not used when the modules are linked?

Andrej Lucny wrote:

Maybe, you haven’t used option -T1 for compiling only.

Andy

Steve <> stlang@vt.edu> > wrote:
I have attached an interrupt handler to an IRQL (9) using
qnx_hint_attach but the interrupt handler never gets called. The
interrupt is generated from an external PCI board. I’m positive the
board is correctly generating interrupts because I have probed its
IRQL. I’m fairly sure the interrupt handler works correctly because I
have tested it with IRQL -1 which calls the interrupt handler every
50ms. So, there seems to be a problem between the hardware interrupt
being generated and my interrupt handler being called - which leads me
to the OS. I have followed the examples that are contained in the
documentation and they work fine except for PCI generated interrupts.

Do I have to do anything special to tell the OS that the interrupt is
being generated from a PCI board?

Do I have to do any other interrupt setup other than qnx_hint_attach
and
masking the interrupts on?

Any help would be appreciated.

6

Maybe, you haven’t used option -T1 for compiling only.

Andy

Steve <stlang@vt.edu> wrote:

I have attached an interrupt handler to an IRQL (9) using
qnx_hint_attach but the interrupt handler never gets called. The
interrupt is generated from an external PCI board. I’m positive the
board is correctly generating interrupts because I have probed its
IRQL. I’m fairly sure the interrupt handler works correctly because I
have tested it with IRQL -1 which calls the interrupt handler every
50ms. So, there seems to be a problem between the hardware interrupt
being generated and my interrupt handler being called - which leads me
to the OS. I have followed the examples that are contained in the
documentation and they work fine except for PCI generated interrupts.

Do I have to do anything special to tell the OS that the interrupt is
being generated from a PCI board?

Do I have to do any other interrupt setup other than qnx_hint_attach and
masking the interrupts on?

Any help would be appreciated.

7

I think maybe you might have misunderstood me. In this BIOS, IRQs are set to be
reserved for either PCI or ISA. My system does not have ANY ISA cards at all and
only ONE PCI card but there are other PCI devices (video, and ethernet). The only
other PCI device that requires an interrupt is the ethernet card (IRQ 9).
Therefore, there are plenty of unused IRQs: 2, 7, 8, and 14. The BIOS has no
problem with switching the extra IRQs from ISA to PCI. It only has problems when I
switch IRQ 9 to ISA. My gut feeling is that IRQ 9 is the only IRQ that can be used
for PCI devices. I’m not quite sure why that is, but the BIOS will not assign my
PCI device to another IRQ. For example, If I have every available IRQ reserved for
PCI and only IRQ 9 reserved for ISA, the BIOS does not assign the device an IRQ and
the system crashes on startup.

I admit the above scenario is not the greatest, but I would still think that the OS
would not have a problem registering an ISR to IRQ9. As I mentioned before, I know
there is no problem with the way I have my software project set up because
everything works with the minor adjustment of registering my ISR to IRQ -1 instead
of IRQ 9. I also know that the hardware interrupt line is being triggered because I
have probed the board and seen the interrupt line go to 0V (active low) when
expected. I also now know that the system is attaching my device to IRQ 9 because
it is displayed via “sin irq.”

Why would the ISR not get called if the OS knows that this PCI device is attached to
IRQ 9, and I have correctly attached an ISR to IRQ 9, and the interrupt line is
asserted?

David Gibbs wrote:

Steve <> stlang@vt.edu> > wrote:
Yes, IRQ 9 is assigned by the bios and determined by reading the PCI
configuration space.

I just tried to reserve IRQ 9 for ISA in the BIOS. This left me with only 1
IRQ for PCI which is presently being used by a network card. The remainder of
the IRQ are all reserved for ISA so I assumed that I had to toggle one of the
other IRQs to PCI. I then tried switching (one at at time) all the other
available IRQs to PCI and rebooting the machine. Every other configuration
caused the BIOS to not assign an IRQ to my board at all! I also received
errors on startup such as: “Unable to map extended memory”, and Floating
point exceptions. The only configuration that actually starts the machine is
when IRQ 9 is set to handle PCI devices.

Any other thoughts?

Try attaching to irq 2 instead of 9?

What sort of box is this that not reserving all the irq for ISA causes
problems? Do you actually have a huge whack of cards on the ISA bus
that need all those irqs? If not, I might begin to wonder about the
PCI BIOS, or the BIOS or hardware setup on this machine. It sure doesn’t
sound healthy to me. (And, if it is as unhealthy as it seems, that could
be causing your problem as well.)

-David

8

You only need to link with -T1. For compile it’s useless.

“Steve” <stlang@vt.edu> wrote in message news:3A14F4FE.166E32D3@vt.edu…

What exactly does this mean? The -T1 option should be used when compiling
modules, but not used when the modules are linked?

Andrej Lucny wrote:

Maybe, you haven’t used option -T1 for compiling only.

Andy

Steve <> stlang@vt.edu> > wrote:
I have attached an interrupt handler to an IRQL (9) using
qnx_hint_attach but the interrupt handler never gets called. The
interrupt is generated from an external PCI board. I’m positive the
board is correctly generating interrupts because I have probed its
IRQL. I’m fairly sure the interrupt handler works correctly because I
have tested it with IRQL -1 which calls the interrupt handler every
50ms. So, there seems to be a problem between the hardware interrupt
being generated and my interrupt handler being called - which leads me
to the OS. I have followed the examples that are contained in the
documentation and they work fine except for PCI generated interrupts.

Do I have to do anything special to tell the OS that the interrupt is
being generated from a PCI board?

Do I have to do any other interrupt setup other than qnx_hint_attach
and
masking the interrupts on?

Any help would be appreciated.

9

Andrej Lucny <andy@nod10.mstep> wrote:

Maybe, you haven’t used option -T1 for compiling only.

You don’t need -T1 to attach an irq handler. But, if you’re
going to talk to the hardware anywhere but in the handler, you
do need it. Of course, the usual effect of forgetting -T1 is
pretty obvious – your program will SIGSEGV.

-David


Steve <> stlang@vt.edu> > wrote:
I have attached an interrupt handler to an IRQL (9) using
qnx_hint_attach but the interrupt handler never gets called. The
interrupt is generated from an external PCI board. I’m positive the
board is correctly generating interrupts because I have probed its
IRQL. I’m fairly sure the interrupt handler works correctly because I
have tested it with IRQL -1 which calls the interrupt handler every
50ms. So, there seems to be a problem between the hardware interrupt
being generated and my interrupt handler being called - which leads me
to the OS. I have followed the examples that are contained in the
documentation and they work fine except for PCI generated interrupts.

Do I have to do anything special to tell the OS that the interrupt is
being generated from a PCI board?

Do I have to do any other interrupt setup other than qnx_hint_attach and
masking the interrupts on?

Any help would be appreciated.

10

Steve <stlang@vt.edu> wrote:

Hmm, right now I compile and link with that option because my ISR is within my
driver. Any other ideas?

Probably not an issue, but I would strongly suggest putting the ISR in a
different .c file from the rest of your code. The ISR needs to be
compiled with the options “-Wc,-s -zu” to disable stack checking and
tell the compiler that SS != DS. But, the rest of your code need not
be compiled without the stack checking disabled, and should not be
compiled with the -zu flag.

Probably not your problem in this case, but if your handler did get
attached and called, and it wasn’t compiled properly, it could crash
the kernel (whole OS).

-David

11

Steve <stlang@vt.edu> wrote:

Yes, IRQ 9 is assigned by the bios and determined by reading the PCI
configuration space.

I just tried to reserve IRQ 9 for ISA in the BIOS. This left me with only 1
IRQ for PCI which is presently being used by a network card. The remainder of
the IRQ are all reserved for ISA so I assumed that I had to toggle one of the
other IRQs to PCI. I then tried switching (one at at time) all the other
available IRQs to PCI and rebooting the machine. Every other configuration
caused the BIOS to not assign an IRQ to my board at all! I also received
errors on startup such as: “Unable to map extended memory”, and Floating
point exceptions. The only configuration that actually starts the machine is
when IRQ 9 is set to handle PCI devices.

Any other thoughts?

Try attaching to irq 2 instead of 9?

What sort of box is this that not reserving all the irq for ISA causes
problems? Do you actually have a huge whack of cards on the ISA bus
that need all those irqs? If not, I might begin to wonder about the
PCI BIOS, or the BIOS or hardware setup on this machine. It sure doesn’t
sound healthy to me. (And, if it is as unhealthy as it seems, that could
be causing your problem as well.)

-David

12

Steve <stlang@vt.edu> wrote:

There shouldn’t be any problem with irq 9, at least not from the OS
side of things. On my desktop, where I’m typing right now, my Network
card is using irq 9 quite happily – and it is a PCI network card.

My “sin irq” output includes:

9 4 /bin/Net 0015:0077F5 001D

So, the OS is quite happy with this.

I think if you attach to irq 2, you’ll get irq 9 instead – so irq 9
is shared between 2 & 9, but that shouldn’t be an issue here.

I think maybe you might have misunderstood me. In this BIOS, IRQs are set to be
reserved for either PCI or ISA. My system does not have ANY ISA cards at all and
only ONE PCI card but there are other PCI devices (video, and ethernet). The only
other PCI device that requires an interrupt is the ethernet card (IRQ 9).
Therefore, there are plenty of unused IRQs: 2, 7, 8, and 14. The BIOS has no
problem with switching the extra IRQs from ISA to PCI. It only has problems when I
switch IRQ 9 to ISA. My gut feeling is that IRQ 9 is the only IRQ that can be used
for PCI devices. I’m not quite sure why that is, but the BIOS will not assign my
PCI device to another IRQ. For example, If I have every available IRQ reserved for
PCI and only IRQ 9 reserved for ISA, the BIOS does not assign the device an IRQ and
the system crashes on startup.

That does not sound healthy. The problem is, that sounds like pooched
hardware – if it is pooched in one way, how many other ways is it
pooched?

Why would the ISR not get called if the OS knows that this PCI device is attached to
IRQ 9, and I have correctly attached an ISR to IRQ 9, and the interrupt line is
asserted?

Hardware problems?

Can you try installing QNX & your IO card on a totally different machine,
and try testing it there?

-David

13

May i suggest using irqmon.

It’s a little utility that monitors irq activity on QNX4 machines. You can
run it with a driver attached or not to the irq.
If the card needs setup to generate irqs, then you probably have to set it
up.

You can found it on www.disableu.net/qnx

Hope this will help you to find if the os is seeing the irq or not.

I cannot guarantee this soft, but if it sees the irq 9 activity, then you’re
problem is in your soft.

–
Arnauld Disableu
arnauld@disableu.net
http://www.disableu.net

Compatible an 2000
Year 2000 compliant
“Steve” <stlang@vt.edu> a écrit dans le message news:
3A1406C5.7EB35C85@vt.edu…

I have attached an interrupt handler to an IRQL (9) using
qnx_hint_attach but the interrupt handler never gets called. The
interrupt is generated from an external PCI board. I’m positive the
board is correctly generating interrupts because I have probed its
IRQL. I’m fairly sure the interrupt handler works correctly because I
have tested it with IRQL -1 which calls the interrupt handler every
50ms. So, there seems to be a problem between the hardware interrupt
being generated and my interrupt handler being called - which leads me
to the OS. I have followed the examples that are contained in the
documentation and they work fine except for PCI generated interrupts.

Do I have to do anything special to tell the OS that the interrupt is
being generated from a PCI board?

Do I have to do any other interrupt setup other than qnx_hint_attach and
masking the interrupts on?

Any help would be appreciated.

14

Steve,

don’t forget to enable irq generation and call qnx_hint_mask() before
checking your irq handler. for sure, disable stack checking, don’t call
non-reentrant functions from handler, link with -T1 option and so on.

ps: irq 9 works perfect under qnx4. for example right now my pci intel
pro/100+ uses irq9 and works ok with Net.ether82557 driver.

// wbr

“Steve” <stlang@vt.edu> wrote in message news:3A15007A.18880699@vt.edu…

Hmm, right now I compile and link with that option because my ISR is
within my
driver. Any other ideas?

Mario Charest wrote:

You only need to link with -T1. For compile it’s useless.

“Steve” <> stlang@vt.edu> > wrote in message
news:> 3A14F4FE.166E32D3@vt.edu> …
What exactly does this mean? The -T1 option should be used when
compiling
modules, but not used when the modules are linked?

Andrej Lucny wrote:

Maybe, you haven’t used option -T1 for compiling only.

Andy

Steve <> stlang@vt.edu> > wrote:
I have attached an interrupt handler to an IRQL (9) using
qnx_hint_attach but the interrupt handler never gets called. The
interrupt is generated from an external PCI board. I’m positive
the
board is correctly generating interrupts because I have probed its
IRQL. I’m fairly sure the interrupt handler works correctly
because I
have tested it with IRQL -1 which calls the interrupt handler
every
50ms. So, there seems to be a problem between the hardware
interrupt
being generated and my interrupt handler being called - which
leads me
to the OS. I have followed the examples that are contained in the
documentation and they work fine except for PCI generated
interrupts.

Do I have to do anything special to tell the OS that the interrupt
is
being generated from a PCI board?

Do I have to do any other interrupt setup other than
qnx_hint_attach
and
masking the interrupts on?

Any help would be appreciated.
\

Ian Zagorskih
Novosoft CyBearNet Department
Custom software development and web design since 1992
E-mail: ianzag@novosoft.ru
Phone: +7 (3832) 39-72-60, 39-72-61
Fax: +7 (3832) 39-63-58
For more visit www.novosoft-us.com