IRQ assignments, priority

Trying to configure a PCI a/d converter so that it’s interrupt is
not shared and high priority is getting really difficult on x86-based
standard PC’s. I would
appreciate any advice with these problems:

1.) With ‘pci -v’ I can see the interrupt assignments for PCI devices. How can I
see the others? Is is safe to assume the ISA interrupts that I cannot specify
in the BIOS setup screens are standard (e.g. IDE on 14 and 15, mouse on 12, etc)?

2.) Under XP my machine shows ACPI and SMBus on 9. Can I ignore this under RTP
and assume these wont generate an interrupt? I’ve got to use an interrupt between
8 and 12 so I have priority over mouse, IDE, etc.

3.) Some BIOS’s allow you to turn USB off, some dont (and some motherboards wire-or
PCI slot INTA’s to the USB controllers, which makes this issue really critical).
On machines where I cant turn off USB in the BIOS, how
can I guarantee I wont get any USB interrupts? Is not connecting anything to USB ports
sufficient?

I know RTP is multiplatform,
and I’m just talking about x86 with PCI bus. But some nice things 4.25 had to
help with these issues (‘sin irq’ and the ability to specify the
highest priority IRQ) have not shown up in RTP and I’m confused. Is attempting
hard realtime on x86 standard PC’s not considered a good platform anymore?
I need some options here.

Thanks,
Art Hays
National Institutes of Health
avhays@nih.gov

Art Hays <avhays@nih.gov> wrote:

Trying to configure a PCI a/d converter so that it’s interrupt is
not shared and high priority is getting really difficult on x86-based
standard PC’s. I would
appreciate any advice with these problems:

1.) With ‘pci -v’ I can see the interrupt assignments for PCI devices. How can I
see the others? Is is safe to assume the ISA interrupts that I cannot specify
in the BIOS setup screens are standard (e.g. IDE on 14 and 15, mouse on 12, etc)?

2.) Under XP my machine shows ACPI and SMBus on 9. Can I ignore this under RTP
and assume these wont generate an interrupt? I’ve got to use an interrupt between
8 and 12 so I have priority over mouse, IDE, etc.

3.) Some BIOS’s allow you to turn USB off, some dont (and some motherboards wire-or
PCI slot INTA’s to the USB controllers, which makes this issue really critical).
On machines where I cant turn off USB in the BIOS, how
can I guarantee I wont get any USB interrupts? Is not connecting anything to USB ports
sufficient?

I know RTP is multiplatform,
and I’m just talking about x86 with PCI bus. But some nice things 4.25 had to
help with these issues (‘sin irq’ and the ability to specify the
highest priority IRQ) have not shown up in RTP and I’m confused. Is attempting
hard realtime on x86 standard PC’s not considered a good platform anymore?
I need some options here.

Thanks,
Art Hays
National Institutes of Health
avhays@nih.gov

On some BIOSs you can set what IRQs are available to PCI devices in
individual slots. You can also see what IRQs are available to ISA
devices.

I’ve have some luck putting certain PCI devices into certain slot and
telling BIOS that the only IRQ available for that slot is X. The BIOS
will usually try to honor that configuration if it can.

If your BIOS doesn’t allow this then I think you may be out of luck.


Bill Caroselli – Q-TPS Consulting
1-(626) 824-7983
qtps@earthlink.net

Art Hays wrote:

2.) Under XP my machine shows ACPI and SMBus on 9. Can I ignore this under RTP
and assume these wont generate an interrupt? I’ve got to use an interrupt between
8 and 12 so I have priority over mouse, IDE, etc.

You should be able to turn ACPI off in the power management section of
the BIOS (which should stop it from using IRQ 9).

3.) Some BIOS’s allow you to turn USB off, some dont (and some motherboards wire-or
PCI slot INTA’s to the USB controllers, which makes this issue really critical).
On machines where I cant turn off USB in the BIOS, how
can I guarantee I wont get any USB interrupts? Is not connecting anything to USB ports
sufficient?

I know RTP is multiplatform,
and I’m just talking about x86 with PCI bus. But some nice things 4.25 had to
help with these issues (‘sin irq’ and the ability to specify the
highest priority IRQ) have not shown up in RTP and I’m confused.

Ha ! get 6.2.1. I was thrilled as punch when “pidin irq” showed up.
As the frenchman on the castle in the holy grail would say
“we have one… it is veerrrry nahs” :slight_smile:

Is attempting
hard realtime on x86 standard PC’s not considered a good platform anymore?
I need some options here.

It can be tricky, but it’s not impossible.

Rennie

Rennie Allen <rgallen@attbi.com> wrote:

Art Hays wrote:

I know RTP is multiplatform,
and I’m just talking about x86 with PCI bus. But some nice things 4.25 had to
help with these issues (‘sin irq’ and the ability to specify the
highest priority IRQ) have not shown up in RTP and I’m confused.

Ha ! get 6.2.1. I was thrilled as punch when “pidin irq” showed up.
As the frenchman on the castle in the holy grail would say
“we have one… it is veerrrry nahs” > :slight_smile:

Yes, I fought to get a “pidin irq” for a while. I missed it muchly.

As to interrupt priority, under QNX4, you could only play with the first
bank, so you didn’t have a way to make interrupt 10 (say) the highest
priority.

Under QNX6, you could modify startup-bios to do the 8259 work to do
this, I would think.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

David Gibbs <dagibbs@qnx.com> wrote in message
news:b61q4m$qir$4@nntp.qnx.com

Under QNX6, you could modify startup-bios to do the 8259 work to do
this, I would think.

We changed startup-bios to allow you to specify the highest priority
interrupt on the command line, but it won’t make the next release AFAIK.

The change you want to make is to send the OCW2, to pin down the lowest
priority interrupt, and the rest will follow in rotation.

-Adam

Rennie Allen <rgallen@attbi.com> wrote:

Ha ! get 6.2.1. I was thrilled as punch when “pidin irq” showed up.
As the frenchman on the castle in the holy grail would say
“we have one… it is veerrrry nahs” > :slight_smile:

Can the 6.2.1 run under 6.2.0?
Or does ‘pidin irq’ require a kernel API to work?

Bill Caroselli wrote:

Rennie Allen <> rgallen@attbi.com> > wrote:

Can the 6.2.1 run under 6.2.0?
Or does ‘pidin irq’ require a kernel API to work?

Is sure hope it is something in proc (I would hate to think
we’ve been doing without this until now, just because there
was a missing printf in pidin :slight_smile:

btw: “pidin irq” is more sophisticated than “sin irq”. Since
there are now many ways to intercept an interrupt,
“pidin irq” displays how the interrupt is being
intercepted.

“Rennie Allen” <rgallen@attbi.com> wrote in message
news:b60fa2$92a$1@inn.qnx.com

Ha ! get 6.2.1. I was thrilled as punch when “pidin irq” showed up.
As the frenchman on the castle in the holy grail would say
“we have one… it is veerrrry nahs” > :slight_smile:

Very welcome - as are “pidin timers” and “pidin net”!

Not wanting to look the proverbial gift horse in the mouth, but…

Couldn’t someone have updated “psin” to show the same information?
And while we’re at it, how about “pidin fds” and “pidin reg”?

Doesn’t anyone else find it annoying that “sin”, “pidin”, “psin” and “ps”
each give you access to one or two snippets of information that isn’t
available from any of the others? For example, unless I missed something
file descriptors and registers are in “sin/psin” only and umask is in “ps”
only. It would make sense to me that “pidin” should be the master with
sin/ps having subsets as required for backwards/POSIX compatibility.


Rob Rutherford
Ruzz Technology

Doesn’t anyone else find it annoying that “sin”, “pidin”, “psin” and “ps”
each give you access to one or two snippets of information that isn’t
available from any of the others? For example, unless I missed something
file descriptors and registers are in “sin/psin” only and umask is in “ps”
only. It would make sense to me that “pidin” should be the master with
sin/ps having subsets as required for backwards/POSIX compatibility.

Ahhh…history.

The master should be pidin, but sin was the master on QNX4 and some people
like being able to use the same finger-history no matter what machine they
are sitting at. :wink: Try invoking ‘sin sin’ and ‘pidin sin’ sometime.

So I am sure you will see the “pidin fds” show up one of these days…

chris


Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

Bill Caroselli <qtps@earthlink.net> wrote:

Rennie Allen <> rgallen@attbi.com> > wrote:
Ha ! get 6.2.1. I was thrilled as punch when “pidin irq” showed up.
As the frenchman on the castle in the holy grail would say
“we have one… it is veerrrry nahs” > :slight_smile:

Can the 6.2.1 run under 6.2.0?
Or does ‘pidin irq’ require a kernel API to work?

It required a procnto change. Not in fact kernel, it required support
for a new message and response on the Proc side. (Though, that distinction
is possibly more important to us than to you.)

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Try invoking ‘sin sin’ and ‘pidin sin’ sometime.

Don’t forget ‘sin toomuch’…especially on QNX4