I remember when PCI was new that certain QNX Device and Network drivers could not be used
with Interupt sharing.
My question is:
Are there any Programms in QNX 4.25D that have Problems with PCI shared Interupts?
If so is there a list of such programms.
Previously, Horst Hannappel wrote in qdn.public.qnx4:
I remember when PCI was new that certain QNX Device and Network drivers could not be used
with Interupt sharing.
My question is:
Are there any Programms in QNX 4.25D that have Problems with PCI shared Interupts?
If so is there a list of such programms.
Anyone?
We used to tell our customers not to use shared interupts and all was good.
With modern PCI BIOS that becomes more and more difficult to achieve.
The question is: do all QNX provided drivers work with shared interupts or
is there something to take care of?
I have successfully shared PCI interrupts on network and SCSI cards under
QNX 4.25.
Our problem was that we had so many ISA devices that we needed to support we
only had 1 interrupt left for all our PCI devices. Fortunately, I don’t
think that video uses interrupts.
I think the drivers were Net.ether2100 and Fsys.aha7scsi.
Horst Hannappel <Horst.Hannappel@mbs-software.de> wrote in message
news:Voyager.010123142240.20780A@node3.internal…
Previously, Horst Hannappel wrote in qdn.public.qnx4:
I remember when PCI was new that certain QNX Device and Network drivers
could not be used
with Interupt sharing.
My question is:
Are there any Programms in QNX 4.25D that have Problems with PCI shared
Interupts?
If so is there a list of such programms.
Anyone?
We used to tell our customers not to use shared interupts and all was
good.
With modern PCI BIOS that becomes more and more difficult to achieve.
The question is: do all QNX provided drivers work with shared interupts or
is there something to take care of?
Horst Hannappel <Horst.Hannappel@mbs-software.de> wrote:
Previously, Horst Hannappel wrote in qdn.public.qnx4:
I remember when PCI was new that certain QNX Device and Network drivers could not be used
with Interupt sharing.
My question is:
Are there any Programms in QNX 4.25D that have Problems with PCI shared Interupts?
If so is there a list of such programms.
Anyone?
We used to tell our customers not to use shared interupts and all was good.
With modern PCI BIOS that becomes more and more difficult to achieve.
The question is: do all QNX provided drivers work with shared interupts or
is there something to take care of?
Ethernet & SCSI cards should definitely handle shared interrupts. I would
expect the EIDE drivers to do so as well. I wouldn’t trust the Dev.*
drivers – I don’t think Dev.con has ever been tested that way – though
it does seem to handle sharing an interrupt between a PS/2 mouse & keyboard,
but that is all through the same controller. I know that Dev.ser didn’t
use to handle shared interrupts, but it may have been updated. (Dev.par
doesn’t use interrupts at all, so it doesn’t care – nor do any of the
graphics drivers.)
-David
QNX Training Services
dagibbs@qnx.com
David Gibbs <dagibbs@qnx.com> wrote:
Horst Hannappel <> Horst.Hannappel@mbs-software.de> > wrote:
Previously, Horst Hannappel wrote in qdn.public.qnx4:
I remember when PCI was new that certain QNX Device and Network drivers could not be used
with Interupt sharing.
My question is:
Are there any Programms in QNX 4.25D that have Problems with PCI shared Interupts?
If so is there a list of such programms.
Anyone?
We used to tell our customers not to use shared interupts and all was good.
With modern PCI BIOS that becomes more and more difficult to achieve.
The question is: do all QNX provided drivers work with shared interupts or
is there something to take care of?
Ethernet & SCSI cards should definitely handle shared interrupts. I would
expect the EIDE drivers to do so as well. I wouldn’t trust the Dev.*
The eide drivers will not share interrupts.
Kevin Chiles <kchiles@qnx.com> wrote:
David Gibbs <> dagibbs@qnx.com> > wrote:
Horst Hannappel <> Horst.Hannappel@mbs-software.de> > wrote:
Previously, Horst Hannappel wrote in qdn.public.qnx4:
I remember when PCI was new that certain QNX Device and Network drivers could not be used
with Interupt sharing.
My question is:
Are there any Programms in QNX 4.25D that have Problems with PCI shared Interupts?
If so is there a list of such programms.
Anyone?
We used to tell our customers not to use shared interupts and all was good.
With modern PCI BIOS that becomes more and more difficult to achieve.
The question is: do all QNX provided drivers work with shared interupts or
is there something to take care of?
Ethernet & SCSI cards should definitely handle shared interrupts. I would
expect the EIDE drivers to do so as well. I wouldn’t trust the Dev.*
The eide drivers will not share interrupts.
Thanks Kevin – I wasn’t sure on them.
-David
QNX Training Services
dagibbs@qnx.com
Previously, David Gibbs wrote in qdn.public.qnx4:
Kevin Chiles <> kchiles@qnx.com> > wrote:
David Gibbs <> dagibbs@qnx.com> > wrote:
Horst Hannappel <> Horst.Hannappel@mbs-software.de> > wrote:
Previously, Horst Hannappel wrote in qdn.public.qnx4:
I remember when PCI was new that certain QNX Device and Network drivers could not be used
with Interupt sharing.
My question is:
Are there any Programms in QNX 4.25D that have Problems with PCI shared Interupts?
If so is there a list of such programms.
Anyone?
We used to tell our customers not to use shared interupts and all was good.
With modern PCI BIOS that becomes more and more difficult to achieve.
The question is: do all QNX provided drivers work with shared interupts or
is there something to take care of?
Ethernet & SCSI cards should definitely handle shared interrupts. I would
expect the EIDE drivers to do so as well. I wouldn’t trust the Dev.*
The eide drivers will not share interrupts.
Thanks Kevin – I wasn’t sure on them.
-David
QNX Training Services
dagibbs@qnx.com
Thanks for all the answers!
So the answer is:
all SCSI shares
all network shares
EIDE doesnot share
Dev* is unkwon
That leaves us with some problems. The best thing would be if evrything
tha uses PCI just works without fiddling in BIOS. It is clear you have to take
special care with ISA cards. As mentioned above i have to tell non QNX experts
how to adjust off the shelf computers to work with our QNX4 based system.
Is it difficult to arrange for shared interupts in a driver? Can we expect
improvement in the near future?
Could you tell me exactly how Dev.ser behaves? We use dumb serial PCI cards
like “Blue Heat” from ConnectTeh.
Horst
Horst Hannappel <Horst.Hannappel@mbs-software.de> wrote:
That leaves us with some problems. The best thing would be if evrything
tha uses PCI just works without fiddling in BIOS. It is clear you have to take
special care with ISA cards. As mentioned above i have to tell non QNX experts
how to adjust off the shelf computers to work with our QNX4 based system.
Is it difficult to arrange for shared interupts in a driver? Can we expect
improvement in the near future?
Could you tell me exactly how Dev.ser behaves? We use dumb serial PCI cards
like “Blue Heat” from ConnectTeh.
Dev.ser will definitely handle a dumb multi-port serial card with all
the ports on the card sharing one irq – the card generally has hardware
to properly or the lines, and Dev.ser does a tail-end poll.
I don’t know if it will handle the serial card sharing an irq with another
card properly – I don’t think it will. (It didn’t used to – I’m just
not sure that this hasn’t been fixed in the latest release. I don’t think
so, but I’m no longer in the line of fire for needing to know this sort of
thing.)
-David
QNX Training Services
dagibbs@qnx.com
Previously, David Gibbs wrote in qdn.public.qnx4:
Horst Hannappel <> Horst.Hannappel@mbs-software.de> > wrote:
That leaves us with some problems. The best thing would be if evrything
tha uses PCI just works without fiddling in BIOS. It is clear you have to take
special care with ISA cards. As mentioned above i have to tell non QNX experts
how to adjust off the shelf computers to work with our QNX4 based system.
Is it difficult to arrange for shared interupts in a driver? Can we expect
improvement in the near future?
Could you tell me exactly how Dev.ser behaves? We use dumb serial PCI cards
like “Blue Heat” from ConnectTeh.
Dev.ser will definitely handle a dumb multi-port serial card with all
the ports on the card sharing one irq – the card generally has hardware
to properly or the lines, and Dev.ser does a tail-end poll.
I don’t know if it will handle the serial card sharing an irq with another
card properly – I don’t think it will. (It didn’t used to – I’m just
not sure that this hasn’t been fixed in the latest release. I don’t think
so, but I’m no longer in the line of fire for needing to know this sort of
thing.)
I was afraid of that answer. Is there someone who knows the exact current state?
What is the difference in code that decides if a driver can share an irq with other
cards?
Horst
-David
QNX Training Services
dagibbs@qnx.com
Previously, Horst Hannappel wrote in qdn.public.qnx4:
What is the difference in code that decides if a driver can share an irq with other
cards?
Here’s all I know. ISA cards are designed to do edge
sensitive IRQ’s. That is an interrupt fires when the voltage
on the IRQ line is pulled from up to down ( or is it down to
up?) Anyway, I’ve been told that it is the wrong direction
electrically for allowing shared interrupts, so only one ISA
card can use an interrupt. Some cards, especially serial
port cards, will have hardware to OR the interrupt lines
from more than one UART so any of the UARTS can firethe
interrupt. Because the interrupt can’t be refired while
held, the driver must poll each UART to see if it is waiting
for service. There are some special ISA cards that use a
“tri-state” circuit which allows multiple cards to share an
interrupt however they generally all have to be the same
make of card.
For PCI things are different. The interrupts are Level
triggered. If the interrupt is down (or is it up) the
interrupt fires. QNX will give control to each interrupt
handler that has been attached to the interrupt. Each
handler is supposed to check its own hardware. It can’t
assume that the IRQ was for it, which maybe the difference
that you are looking for.
Mitchell Schoenbrun --------- maschoen@pobox.com
Previously, Mitchell Schoenbrun wrote in qdn.public.qnx4:
Previously, Horst Hannappel wrote in qdn.public.qnx4:
What is the difference in code that decides if a driver can share an irq with other
cards?
Here’s all I know. ISA cards are designed to do edge
sensitive IRQ’s. That is an interrupt fires when the voltage
on the IRQ line is pulled from up to down ( or is it down to
up?) Anyway, I’ve been told that it is the wrong direction
electrically for allowing shared interrupts, so only one ISA
card can use an interrupt. Some cards, especially serial
port cards, will have hardware to OR the interrupt lines
from more than one UART so any of the UARTS can firethe
interrupt. Because the interrupt can’t be refired while
held, the driver must poll each UART to see if it is waiting
for service. There are some special ISA cards that use a
“tri-state” circuit which allows multiple cards to share an
interrupt however they generally all have to be the same
make of card.
that is my understanding as well.
For PCI things are different. The interrupts are Level
triggered. If the interrupt is down (or is it up) the
interrupt fires. QNX will give control to each interrupt
handler that has been attached to the interrupt. Each
handler is supposed to check its own hardware. It can’t
assume that the IRQ was for it, which maybe the difference
that you are looking for.
Yes, i want to know what i should look for in the sources for Dev.ser.
What could a Driver do wrong that makes it misbehave with shared interupts.
Mitchell Schoenbrun --------- > maschoen@pobox.com
\
David Gibbs <dagibbs@qnx.com> writes:
I know that Dev.ser didn’t
use to handle shared interrupts, but it may have been updated.
At least in 4.25 running two Dev.ser with same interrupt doesn’t work,
all ports sharing same interrupt must be using same Dev.ser.
–
M. Tavasti / tavastixx@iki.fi / +358-40-5078254
Poista sähköpostiosoitteesta molemmat x-kirjaimet
Remove x-letters from my e-mail address