qnx_hint_attach PROBLEMS Help!

I can compile this code fragment (from main() in my interrupt
experiment program) and step throught it with the watcom debugger It
locks the entire machine up (requiring a hard reset) inside the
qnx_hint_attach() routine (the “int” assembly instruction
specifically). the machine locks regardless if using watcom debugger
or running the process from a shell. I have it set to compile with
privity 1 (-T1 option), and the -Wc, -zu, -Wc, -s flags (for disabling
stack checking). I have no Idea where to from here on debugging this
one. Does anyone have any suggestions?
Note: QNX4.25 / Watcom 10.6

Thanks in advance for any suggestions,
Erick

// Set the process priority fairly high
if (setprio(0,25)==-1)
{
fprintf(stderr, “Failed to set priority\n”);
exit(EXIT_FAILURE);
}

// Create a Proxy of Zero Length
printf(“Creating a proxy message handler\n”);
pid_int_proxy = qnx_proxy_attach(0,NULL,0,-1);
if (pid_int_proxy == -1)
{
fprintf(stderr, “Failed to attach interrupt proxy\n”);
exit(EXIT_FAILURE);
}

//Setup PC104 cards (except interrupts)
initializeHardware(); // Initialize all the hardware on the pc104
stack

// Attach the interrupt service routine
printf(“Attaching to interrupt %u \n”,DM6814IRQ);
isr_id = qnx_hint_attach(DM6814IRQ, &ctrl_isr_handler,
FP_SEG(&pid_int_proxy));//<<<<<<<<<<<<<<<<<It Locks up in this routine
if (isr_id ==-1)
{
fprintf(stderr, “Failed to attach the ctrl interrupt
handler\n”);
exit(EXIT_FAILURE);
}

printf(“Enabing the DM6814 IRQ.\n”);
EnableIRQSharing6814(1); // Disable interrupt sharing.
EnableBoardIRQ6814(1); // Enable 6814 IRQ circuit.

continue to ISR handler…

Also I forgot before I run I did sin irqs and found IRQ7 avaliable
so my hardware is set for that and DM6814IRQ is defined to be 7.

Erick

On Wed, 09 Oct 2002 22:00:01 GMT, QNXNewbie@nomail.com wrote:

I can compile this code fragment (from main() in my interrupt
experiment program) and step throught it with the watcom debugger It
locks the entire machine up (requiring a hard reset) inside the
qnx_hint_attach() routine (the “int” assembly instruction
specifically). the machine locks regardless if using watcom debugger
or running the process from a shell. I have it set to compile with
privity 1 (-T1 option), and the -Wc, -zu, -Wc, -s flags (for disabling
stack checking). I have no Idea where to from here on debugging this
one. Does anyone have any suggestions?
Note: QNX4.25 / Watcom 10.6

Thanks in advance for any suggestions,
Erick

// Set the process priority fairly high
if (setprio(0,25)==-1)
{
fprintf(stderr, “Failed to set priority\n”);
exit(EXIT_FAILURE);
}

// Create a Proxy of Zero Length
printf(“Creating a proxy message handler\n”);
pid_int_proxy = qnx_proxy_attach(0,NULL,0,-1);
if (pid_int_proxy == -1)
{
fprintf(stderr, “Failed to attach interrupt proxy\n”);
exit(EXIT_FAILURE);
}

//Setup PC104 cards (except interrupts)
initializeHardware(); // Initialize all the hardware on the pc104
stack

// Attach the interrupt service routine
printf(“Attaching to interrupt %u \n”,DM6814IRQ);
isr_id = qnx_hint_attach(DM6814IRQ, &ctrl_isr_handler,
FP_SEG(&pid_int_proxy));//<<<<<<<<<<<<<<<<<It Locks up in this routine
if (isr_id ==-1)
{
fprintf(stderr, “Failed to attach the ctrl interrupt
handler\n”);
exit(EXIT_FAILURE);
}

printf(“Enabing the DM6814 IRQ.\n”);
EnableIRQSharing6814(1); // Disable interrupt sharing.
EnableBoardIRQ6814(1); // Enable 6814 IRQ circuit.

continue to ISR handler…

QNXNewbie@nomail.com wrote:

Perhaps a naive question but why would IRQ7 be more susceptible to
spurious interrupts than any others? That would seem to be a circuit
problem on a particuar piece of hardware and thus not a general
statement.

IRQ 7 is designated as the 8259 glitch handler. Although IRQ 7 is best
avoided (for efficiency reasons), there is no reason that it should not
work for you, as long as your hardware allows you to determine the
source of the interrupt (and if there was no source, that your handler
does nothing).

What should I do then? My card only supports IRQ 2-7, all of which
are chewd up by the system keybrd, mouse, serial, lpt,. net, floppy,
eide,pcmcia…except 7

Use IRQ 7, if you have no choice; or, perhaps you don’t need one of the
other devices and can disable it.

btw: eide on an interrupt between 2-7 seems a little odd…

<QNXNewbie@nomail.com> wrote in message
news:3da4a70b.28048421@inn.qnx.com

Also I forgot before I run I did sin irqs and found IRQ7 avaliable
so my hardware is set for that and DM6814IRQ is defined to be 7.

Sin irq just show which program is using IRQ7 it doesn’t mean it physicaly
not used by other hardware.

7 is kind of a flaky interrupt line (subject to spurious interrupt) whenever
possible try to avoid it.

Erick

On Wed, 09 Oct 2002 22:00:01 GMT, > QNXNewbie@nomail.com > wrote:

I can compile this code fragment (from main() in my interrupt
experiment program) and step throught it with the watcom debugger It
locks the entire machine up (requiring a hard reset) inside the
qnx_hint_attach() routine (the “int” assembly instruction
specifically). the machine locks regardless if using watcom debugger
or running the process from a shell. I have it set to compile with
privity 1 (-T1 option), and the -Wc, -zu, -Wc, -s flags (for disabling
stack checking). I have no Idea where to from here on debugging this
one. Does anyone have any suggestions?
Note: QNX4.25 / Watcom 10.6

Thanks in advance for any suggestions,
Erick

// Set the process priority fairly high
if (setprio(0,25)==-1)
{
fprintf(stderr, “Failed to set priority\n”);
exit(EXIT_FAILURE);
}

// Create a Proxy of Zero Length
printf(“Creating a proxy message handler\n”);
pid_int_proxy = qnx_proxy_attach(0,NULL,0,-1);
if (pid_int_proxy == -1)
{
fprintf(stderr, “Failed to attach interrupt proxy\n”);
exit(EXIT_FAILURE);
}

//Setup PC104 cards (except interrupts)
initializeHardware(); // Initialize all the hardware on the pc104
stack

// Attach the interrupt service routine
printf(“Attaching to interrupt %u \n”,DM6814IRQ);
isr_id = qnx_hint_attach(DM6814IRQ, &ctrl_isr_handler,
FP_SEG(&pid_int_proxy));//<<<<<<<<<<<<<<<<<It Locks up in this routine
if (isr_id ==-1)
{
fprintf(stderr, “Failed to attach the ctrl interrupt
handler\n”);
exit(EXIT_FAILURE);
}

printf(“Enabing the DM6814 IRQ.\n”);
EnableIRQSharing6814(1); // Disable interrupt sharing.
EnableBoardIRQ6814(1); // Enable 6814 IRQ circuit.

continue to ISR handler…

Perhaps a naive question but why would IRQ7 be more susceptible to
spurious interrupts than any others? That would seem to be a circuit
problem on a particuar piece of hardware and thus not a general
statement.

What should I do then? My card only supports IRQ 2-7, all of which
are chewd up by the system keybrd, mouse, serial, lpt,. net, floppy,
eide,pcmcia…except 7

as a test I tried hooking IRQ2 without the system locking it up but as
soon as i set the register on my card that enables IRQ2 the system
locks up solid again. The routines for clearing / enabling /disabling
the IRQ on the card were provied to me in source form from Real Time
Devices. They all exist in a seperate source file. I.e. I make a
function call in the ISR to their function to clear the interrupt…
could I be running into some sort of segment issue?

Erick

On Thu, 10 Oct 2002 06:40:39 -0400, “Mario Charest”
postmaster@127.0.0.1 wrote:

QNXNewbie@nomail.com> > wrote in message
news:> 3da4a70b.28048421@inn.qnx.com> …
Also I forgot before I run I did sin irqs and found IRQ7 avaliable
so my hardware is set for that and DM6814IRQ is defined to be 7.

Sin irq just show which program is using IRQ7 it doesn’t mean it physicaly
not used by other hardware.

7 is kind of a flaky interrupt line (subject to spurious interrupt) whenever
possible try to avoid it.


Erick

On Wed, 09 Oct 2002 22:00:01 GMT, > QNXNewbie@nomail.com > wrote:

I can compile this code fragment (from main() in my interrupt
experiment program) and step throught it with the watcom debugger It
locks the entire machine up (requiring a hard reset) inside the
qnx_hint_attach() routine (the “int” assembly instruction
specifically). the machine locks regardless if using watcom debugger
or running the process from a shell. I have it set to compile with
privity 1 (-T1 option), and the -Wc, -zu, -Wc, -s flags (for disabling
stack checking). I have no Idea where to from here on debugging this
one. Does anyone have any suggestions?
Note: QNX4.25 / Watcom 10.6

Thanks in advance for any suggestions,
Erick

// Set the process priority fairly high
if (setprio(0,25)==-1)
{
fprintf(stderr, “Failed to set priority\n”);
exit(EXIT_FAILURE);
}

// Create a Proxy of Zero Length
printf(“Creating a proxy message handler\n”);
pid_int_proxy = qnx_proxy_attach(0,NULL,0,-1);
if (pid_int_proxy == -1)
{
fprintf(stderr, “Failed to attach interrupt proxy\n”);
exit(EXIT_FAILURE);
}

//Setup PC104 cards (except interrupts)
initializeHardware(); // Initialize all the hardware on the pc104
stack

// Attach the interrupt service routine
printf(“Attaching to interrupt %u \n”,DM6814IRQ);
isr_id = qnx_hint_attach(DM6814IRQ, &ctrl_isr_handler,
FP_SEG(&pid_int_proxy));//<<<<<<<<<<<<<<<<<It Locks up in this routine
if (isr_id ==-1)
{
fprintf(stderr, “Failed to attach the ctrl interrupt
handler\n”);
exit(EXIT_FAILURE);
}

printf(“Enabing the DM6814 IRQ.\n”);
EnableIRQSharing6814(1); // Disable interrupt sharing.
EnableBoardIRQ6814(1); // Enable 6814 IRQ circuit.

continue to ISR handler…

<QNXNewbie@nomail.com> wrote in message
news:3da572b5.80186984@inn.qnx.com

Perhaps a naive question but why would IRQ7 be more susceptible to
spurious interrupts than any others? That would seem to be a circuit
problem on a particuar piece of hardware and thus not a general
statement.

I dont know the cause, I just know thats the way it is :wink:

What should I do then? My card only supports IRQ 2-7, all of which
are chewd up by the system keybrd, mouse, serial, lpt,. net, floppy,
eide,pcmcia…except 7

as a test I tried hooking IRQ2 without the system locking it up but as
soon as i set the register on my card that enables IRQ2 the system
locks up solid again. The routines for clearing / enabling /disabling
the IRQ on the card were provied to me in source form from Real Time
Devices. They all exist in a seperate source file. I.e. I make a
function call in the ISR to their function to clear the interrupt…
could I be running into some sort of segment issue?

No if you compile with proper flag (which you mentionned you did).
Make sure their function doesn`t call any C function (some are allowed but
very litte).
Something like sprintf could kill the ISR.

Erick

On Thu, 10 Oct 2002 06:40:39 -0400, “Mario Charest”
postmaster@127.0.0.1> wrote:


QNXNewbie@nomail.com> > wrote in message
news:> 3da4a70b.28048421@inn.qnx.com> …
Also I forgot before I run I did sin irqs and found IRQ7 avaliable
so my hardware is set for that and DM6814IRQ is defined to be 7.

Sin irq just show which program is using IRQ7 it doesn’t mean it
physicaly
not used by other hardware.

7 is kind of a flaky interrupt line (subject to spurious interrupt)
whenever
possible try to avoid it.


Erick

On Wed, 09 Oct 2002 22:00:01 GMT, > QNXNewbie@nomail.com > wrote:

I can compile this code fragment (from main() in my interrupt
experiment program) and step throught it with the watcom debugger It
locks the entire machine up (requiring a hard reset) inside the
qnx_hint_attach() routine (the “int” assembly instruction
specifically). the machine locks regardless if using watcom debugger
or running the process from a shell. I have it set to compile with
privity 1 (-T1 option), and the -Wc, -zu, -Wc, -s flags (for disabling
stack checking). I have no Idea where to from here on debugging this
one. Does anyone have any suggestions?
Note: QNX4.25 / Watcom 10.6

Thanks in advance for any suggestions,
Erick

// Set the process priority fairly high
if (setprio(0,25)==-1)
{
fprintf(stderr, “Failed to set priority\n”);
exit(EXIT_FAILURE);
}

// Create a Proxy of Zero Length
printf(“Creating a proxy message handler\n”);
pid_int_proxy = qnx_proxy_attach(0,NULL,0,-1);
if (pid_int_proxy == -1)
{
fprintf(stderr, “Failed to attach interrupt proxy\n”);
exit(EXIT_FAILURE);
}

//Setup PC104 cards (except interrupts)
initializeHardware(); // Initialize all the hardware on the pc104
stack

// Attach the interrupt service routine
printf(“Attaching to interrupt %u \n”,DM6814IRQ);
isr_id = qnx_hint_attach(DM6814IRQ, &ctrl_isr_handler,
FP_SEG(&pid_int_proxy));//<<<<<<<<<<<<<<<<<It Locks up in this routine
if (isr_id ==-1)
{
fprintf(stderr, “Failed to attach the ctrl interrupt
handler\n”);
exit(EXIT_FAILURE);
}

printf(“Enabing the DM6814 IRQ.\n”);
EnableIRQSharing6814(1); // Disable interrupt sharing.
EnableBoardIRQ6814(1); // Enable 6814 IRQ circuit.

continue to ISR handler…
\

On Thu, 10 Oct 2002 10:46:22 -0400, “Mario Charest”
postmaster@127.0.0.1 wrote:

QNXNewbie@nomail.com> > wrote in message
news:> 3da572b5.80186984@inn.qnx.com> …
Perhaps a naive question but why would IRQ7 be more susceptible to
spurious interrupts than any others? That would seem to be a circuit
problem on a particuar piece of hardware and thus not a general
statement.

I dont know the cause, I just know thats the way it is > :wink:


What should I do then? My card only supports IRQ 2-7, all of which
are chewd up by the system keybrd, mouse, serial, lpt,. net, floppy,
eide,pcmcia…except 7

as a test I tried hooking IRQ2 without the system locking it up but as
soon as i set the register on my card that enables IRQ2 the system
locks up solid again. The routines for clearing / enabling /disabling
the IRQ on the card were provied to me in source form from Real Time
Devices. They all exist in a seperate source file. I.e. I make a
function call in the ISR to their function to clear the interrupt…
could I be running into some sort of segment issue?

No if you compile with proper flag (which you mentionned you did).
Make sure their function doesn`t call any C function (some are allowed but
very litte).
Something like sprintf could kill the ISR.

Does the source file containing the function that gets called in the
ISR need to be compiled to disable stack checking too?

  • all their routine does is call another function that selects the
    proper register to access (some bit masking and outp), returns to
    funtion of thiers that I called in the ISR, and then outp again.

Thanks, Mario

Erick

Erick

On Thu, 10 Oct 2002 06:40:39 -0400, “Mario Charest”
postmaster@127.0.0.1> wrote:


QNXNewbie@nomail.com> > wrote in message
news:> 3da4a70b.28048421@inn.qnx.com> …
Also I forgot before I run I did sin irqs and found IRQ7 avaliable
so my hardware is set for that and DM6814IRQ is defined to be 7.

Sin irq just show which program is using IRQ7 it doesn’t mean it
physicaly
not used by other hardware.

7 is kind of a flaky interrupt line (subject to spurious interrupt)
whenever
possible try to avoid it.


Erick

On Wed, 09 Oct 2002 22:00:01 GMT, > QNXNewbie@nomail.com > wrote:

I can compile this code fragment (from main() in my interrupt
experiment program) and step throught it with the watcom debugger It
locks the entire machine up (requiring a hard reset) inside the
qnx_hint_attach() routine (the “int” assembly instruction
specifically). the machine locks regardless if using watcom debugger
or running the process from a shell. I have it set to compile with
privity 1 (-T1 option), and the -Wc, -zu, -Wc, -s flags (for disabling
stack checking). I have no Idea where to from here on debugging this
one. Does anyone have any suggestions?
Note: QNX4.25 / Watcom 10.6

Thanks in advance for any suggestions,
Erick

// Set the process priority fairly high
if (setprio(0,25)==-1)
{
fprintf(stderr, “Failed to set priority\n”);
exit(EXIT_FAILURE);
}

// Create a Proxy of Zero Length
printf(“Creating a proxy message handler\n”);
pid_int_proxy = qnx_proxy_attach(0,NULL,0,-1);
if (pid_int_proxy == -1)
{
fprintf(stderr, “Failed to attach interrupt proxy\n”);
exit(EXIT_FAILURE);
}

//Setup PC104 cards (except interrupts)
initializeHardware(); // Initialize all the hardware on the pc104
stack

// Attach the interrupt service routine
printf(“Attaching to interrupt %u \n”,DM6814IRQ);
isr_id = qnx_hint_attach(DM6814IRQ, &ctrl_isr_handler,
FP_SEG(&pid_int_proxy));//<<<<<<<<<<<<<<<<<It Locks up in this routine
if (isr_id ==-1)
{
fprintf(stderr, “Failed to attach the ctrl interrupt
handler\n”);
exit(EXIT_FAILURE);
}

printf(“Enabing the DM6814 IRQ.\n”);
EnableIRQSharing6814(1); // Disable interrupt sharing.
EnableBoardIRQ6814(1); // Enable 6814 IRQ circuit.

continue to ISR handler…


\

QNXNewbie@nomail.com wrote:

Perhaps a naive question but why would IRQ7 be more susceptible to
spurious interrupts than any others? That would seem to be a circuit
problem on a particuar piece of hardware and thus not a general
statement.

You should refer to the datasheet for the intel 8259A PIC, which is the
chip that is used in all PCs (or at least the chip whose functionality
is duplicated in the support chipset). Here is a link to the datasheet:

http://ftp.penguinppc.org/users/hollis/8259A_PIC_Datasheet.pdf

If you look on page 7 at the 2nd last paragraph, it states:

“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
and interrupt level 7.”

So, when noise on ANY of the IRQ lines occurs, it will be manifested as
additional IRQs on IRQ7.


as a test I tried hooking IRQ2 without the system locking it up but as
soon as i set the register on my card that enables IRQ2 the system
locks up solid again.

You need to be careful when using IRQ2, it’s not actually available.
There are actually TWO 8259A PIC chips in the PC design, but the actual
CPU only has a single IRQ line, so the two chips are chained together.
The IRQ output of the second chip is actually connected to the IRQ2
input of the first. IRQ 9 is typically used as the “replacement” for
IRQ2, you will often find boards that label it as IRQ2/9.

So, if something is using IRQ2, chances are that it is NOT actually
using IRQ2 and is, instead using IRQ9. If you mess with the actual
IRQ2 vector, you are more likely to disable IRQ’s 8 thu 15 instead.
This is because an IRQ2 is actually an indication to talk to the
2nd 8259A PIC instead of the first. If you service IRQ2 and send an
EOI, then you stop the processing before the rest of the OS can
actually prevent the OS from ever talking to the second chip.

Cheers,
Camz.

Does the source file containing the function that gets called in the
ISR need to be compiled to disable stack checking too?

Yes and -zq.

  • all their routine does is call another function that selects the
    proper register to access (some bit masking and outp), returns to
    funtion of thiers that I called in the ISR, and then outp again.

Thanks, Mario

Erick

Erick

On Thu, 10 Oct 2002 06:40:39 -0400, “Mario Charest”
postmaster@127.0.0.1> wrote:


QNXNewbie@nomail.com> > wrote in message
news:> 3da4a70b.28048421@inn.qnx.com> …
Also I forgot before I run I did sin irqs and found IRQ7 avaliable
so my hardware is set for that and DM6814IRQ is defined to be 7.

Sin irq just show which program is using IRQ7 it doesn’t mean it
physicaly
not used by other hardware.

7 is kind of a flaky interrupt line (subject to spurious interrupt)
whenever
possible try to avoid it.


Erick

On Wed, 09 Oct 2002 22:00:01 GMT, > QNXNewbie@nomail.com > wrote:

I can compile this code fragment (from main() in my interrupt
experiment program) and step throught it with the watcom debugger
It
locks the entire machine up (requiring a hard reset) inside the
qnx_hint_attach() routine (the “int” assembly instruction
specifically). the machine locks regardless if using watcom
debugger
or running the process from a shell. I have it set to compile with
privity 1 (-T1 option), and the -Wc, -zu, -Wc, -s flags (for
disabling
stack checking). I have no Idea where to from here on debugging
this
one. Does anyone have any suggestions?
Note: QNX4.25 / Watcom 10.6

Thanks in advance for any suggestions,
Erick

// Set the process priority fairly high
if (setprio(0,25)==-1)
{
fprintf(stderr, “Failed to set priority\n”);
exit(EXIT_FAILURE);
}

// Create a Proxy of Zero Length
printf(“Creating a proxy message handler\n”);
pid_int_proxy = qnx_proxy_attach(0,NULL,0,-1);
if (pid_int_proxy == -1)
{
fprintf(stderr, “Failed to attach interrupt proxy\n”);
exit(EXIT_FAILURE);
}

//Setup PC104 cards (except interrupts)
initializeHardware(); // Initialize all the hardware on the pc104
stack

// Attach the interrupt service routine
printf(“Attaching to interrupt %u \n”,DM6814IRQ);
isr_id = qnx_hint_attach(DM6814IRQ, &ctrl_isr_handler,
FP_SEG(&pid_int_proxy));//<<<<<<<<<<<<<<<<<It Locks up in this
routine
if (isr_id ==-1)
{
fprintf(stderr, “Failed to attach the ctrl interrupt
handler\n”);
exit(EXIT_FAILURE);
}

printf(“Enabing the DM6814 IRQ.\n”);
EnableIRQSharing6814(1); // Disable interrupt sharing.
EnableBoardIRQ6814(1); // Enable 6814 IRQ circuit.

continue to ISR handler…



\

Camz - Excellent Explanation about IRQ7! Thank you.

As for IRQ usage if my PC104 card has a jumber for IRQ 2-7 and I
select IRQ2 can I hook it by doing qnx_hint_attach() with IRQ9
instead?

Thanks again,

Erick


On 10 Oct 2002 15:15:18 GMT, camz@passageway.com wrote:

QNXNewbie@nomail.com > wrote:
Perhaps a naive question but why would IRQ7 be more susceptible to
spurious interrupts than any others? That would seem to be a circuit
problem on a particuar piece of hardware and thus not a general
statement.

You should refer to the datasheet for the intel 8259A PIC, which is the
chip that is used in all PCs (or at least the chip whose functionality
is duplicated in the support chipset). Here is a link to the datasheet:

http://ftp.penguinppc.org/users/hollis/8259A_PIC_Datasheet.pdf

If you look on page 7 at the 2nd last paragraph, it states:

“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
and interrupt level 7.”

So, when noise on ANY of the IRQ lines occurs, it will be manifested as
additional IRQs on IRQ7.


as a test I tried hooking IRQ2 without the system locking it up but as
soon as i set the register on my card that enables IRQ2 the system
locks up solid again.

You need to be careful when using IRQ2, it’s not actually available.
There are actually TWO 8259A PIC chips in the PC design, but the actual
CPU only has a single IRQ line, so the two chips are chained together.
The IRQ output of the second chip is actually connected to the IRQ2
input of the first. IRQ 9 is typically used as the “replacement” for
IRQ2, you will often find boards that label it as IRQ2/9.

So, if something is using IRQ2, chances are that it is NOT actually
using IRQ2 and is, instead using IRQ9. If you mess with the actual
IRQ2 vector, you are more likely to disable IRQ’s 8 thu 15 instead.
This is because an IRQ2 is actually an indication to talk to the
2nd 8259A PIC instead of the first. If you service IRQ2 and send an
EOI, then you stop the processing before the rest of the OS can
actually prevent the OS from ever talking to the second chip.

Cheers,
Camz.

Sorry for the confusion
the expansion card not eide can only select 2-7

On Thu, 10 Oct 2002 08:58:20 +0000, Rennie Allen <rallen@csical.com>
wrote:

QNXNewbie@nomail.com > wrote:
Perhaps a naive question but why would IRQ7 be more susceptible to
spurious interrupts than any others? That would seem to be a circuit
problem on a particuar piece of hardware and thus not a general
statement.

IRQ 7 is designated as the 8259 glitch handler. Although IRQ 7 is best
avoided (for efficiency reasons), there is no reason that it should not
work for you, as long as your hardware allows you to determine the
source of the interrupt (and if there was no source, that your handler
does nothing).

What should I do then? My card only supports IRQ 2-7, all of which
are chewd up by the system keybrd, mouse, serial, lpt,. net, floppy,
eide,pcmcia…except 7

Use IRQ 7, if you have no choice; or, perhaps you don’t need one of the
other devices and can disable it.

btw: eide on an interrupt between 2-7 seems a little odd…

For the record, I have had very good luck putting dumb serial cards on IRQ
7. I really hate wasting a whole interrupt.

The Dev.ser driver is very good at ignoring interrupts that aren’t real.

I haven’t exhaustively tested the QNX6 serial driver, but it shouldn’t be
very different in that regard.

When will they finally come out with a PC with like 32 interrupts and 32
slots. I can never plug enough crap into a single box.


“Rennie Allen” <rallen@csical.com> wrote in message
news:3DA5412C.5080605@csical.com

QNXNewbie@nomail.com > wrote:
Perhaps a naive question but why would IRQ7 be more susceptible to
spurious interrupts than any others? That would seem to be a circuit
problem on a particuar piece of hardware and thus not a general
statement.

IRQ 7 is designated as the 8259 glitch handler. Although IRQ 7 is best
avoided (for efficiency reasons), there is no reason that it should not
work for you, as long as your hardware allows you to determine the
source of the interrupt (and if there was no source, that your handler
does nothing).

What should I do then? My card only supports IRQ 2-7, all of which
are chewd up by the system keybrd, mouse, serial, lpt,. net, floppy,
eide,pcmcia…except 7

Use IRQ 7, if you have no choice; or, perhaps you don’t need one of the
other devices and can disable it.

btw: eide on an interrupt between 2-7 seems a little odd…

By design, whenever the 8259A get confused, it raises IRQ7 (IRQ15 on the
second PIC) and leaves it to the OS to figure out what might be wrong.

“Mario Charest” postmaster@127.0.0.1 wrote in message
news:ao43jg$cuj$1@inn.qnx.com

QNXNewbie@nomail.com> > wrote in message
news:> 3da572b5.80186984@inn.qnx.com> …
Perhaps a naive question but why would IRQ7 be more susceptible to
spurious interrupts than any others? That would seem to be a circuit
problem on a particuar piece of hardware and thus not a general
statement.

I dont know the cause, I just know thats the way it is > :wink:

QNXNewbie@nomail.com wrote:

As for IRQ usage if my PC104 card has a jumber for IRQ 2-7 and I
select IRQ2 can I hook it by doing qnx_hint_attach() with IRQ9
instead?

That is quite possible. Is this a custom board, or can you give us
a part number and manufacturer?

Cheers,
Camz.

On 11 Oct 2002 00:51:03 GMT, camz@passageway.com wrote:

QNXNewbie@nomail.com > wrote:
As for IRQ usage if my PC104 card has a jumber for IRQ 2-7 and I
select IRQ2 can I hook it by doing qnx_hint_attach() with IRQ9
instead?

That is quite possible. Is this a custom board, or can you give us
a part number and manufacturer?

Hi Camz,

It is a Real Time Devices DM6814 Encoder counter / timer card.
I just found a listing in the datasheet that there are other IRQ’s to
jumper to since my card is the PC- AT rather than the PC-XT version.
I’m trying to hook IRQ10 with my current test program. I can talk to
this card, setup the counter timer for my rate using RTDs source code
(verifyed by oscilloscope) but as soon as I enable the interrupt on
the card the machine locks up tight requiring reboot.

Do I need to send the EOI command to the 8259 IntCtrlr at the end of
my ISR or do all I need to do is clear the int on the card and
return(proxy_msg);?

Thanks,

Erick


Cheers,
Camz.