Dev.ser freezes computer when using IRQ sharing ports

Hi,

we have an embedded QNX4.25 system with Pentium 166MHz, 430TX chipset.
It has a SMC FDC37C935 Combo controller with two UARTs and
a ST16C554 QUAD UART.

When using the SMC UART:s and two of the QUAD UART:s, all using
different IRQ:s, everything works fine. Problems come when we try to
also use the last two. Sending some text e.g. by first “ls -Rpl >/dev/serX”
and “cat </dev/serX” all ports work fine. However, when we start the
application which pumps data continuously and also e.g. does disk access,
the computer always totally freezes after perhaps ten seconds.

We start the driver by
Dev.ser 3f8,6 2f8,7 -b 2400 3e8,4 2e8,3 &
vs
Dev.ser 3f8,6 2f8,7 -b 2400 3e8,4 2e8,3 338,4 238,3 &
where the latter causes the crashes.

Any ideas?

Cheers / Tom

Tomas H?gstr?m <tomas@applied-sensorfusion.com> wrote:

THgm > We start the driver by
THgm > Dev.ser 3f8,6 2f8,7 -b 2400 3e8,4 2e8,3 &
THgm > vs
THgm > Dev.ser 3f8,6 2f8,7 -b 2400 3e8,4 2e8,3 338,4 238,3 &
THgm > where the latter causes the crashes.

It’s been awhile since I’ve worked on QNX4 but I seem to remember an
issue where if Dev.ser attempted to access an address of a UART that
didn’t exist, that it hung the system. I never did track down exactly
what about it was hanging the system. I’m guessing a high priority
CPU loop.

Ok. But in this case all ports work fine for a while.

Bill Caroselli wrote:

Tomas H?gstr?m <> tomas@applied-sensorfusion.com> > wrote:

THgm > We start the driver by
THgm > Dev.ser 3f8,6 2f8,7 -b 2400 3e8,4 2e8,3 &
THgm > vs
THgm > Dev.ser 3f8,6 2f8,7 -b 2400 3e8,4 2e8,3 338,4 238,3 &
THgm > where the latter causes the crashes.

It’s been awhile since I’ve worked on QNX4 but I seem to remember an
issue where if Dev.ser attempted to access an address of a UART that
didn’t exist, that it hung the system. I never did track down exactly
what about it was hanging the system. I’m guessing a high priority
CPU loop.

Unless all UART sit on a PCI bus you cannot share interrupt.

“Tomas Högström” <tomas@applied-sensorfusion.com> wrote in message
news:3FD798DB.39F19AA2@applied-sensorfusion.com

Ok. But in this case all ports work fine for a while.

Bill Caroselli wrote:

Tomas H?gstr?m <> tomas@applied-sensorfusion.com> > wrote:

THgm > We start the driver by
THgm > Dev.ser 3f8,6 2f8,7 -b 2400 3e8,4 2e8,3 &
THgm > vs
THgm > Dev.ser 3f8,6 2f8,7 -b 2400 3e8,4 2e8,3 338,4 238,3 &
THgm > where the latter causes the crashes.

It’s been awhile since I’ve worked on QNX4 but I seem to remember an
issue where if Dev.ser attempted to access an address of a UART that
didn’t exist, that it hung the system. I never did track down exactly
what about it was hanging the system. I’m guessing a high priority
CPU loop.

Makes sense, but in this case the IRQ:s are only shared by different channels in the
same UART (the 16C554), I guess it was probably not correct to call that “IRQ sharing”.
It is ISA bus. This shall be possible, the Connect Tech Xtreme/104 boards
e.g. uses the 16C654 and uses one or two IRQ:s for four or eight ports.

Thanks / Tom

Mario Charest wrote:

Unless all UART sit on a PCI bus you cannot share interrupt.

“Tomas Högström” <> tomas@applied-sensorfusion.com> > wrote in message
news:> 3FD798DB.39F19AA2@applied-sensorfusion.com> …
Ok. But in this case all ports work fine for a while.

Bill Caroselli wrote:

Tomas H?gstr?m <> tomas@applied-sensorfusion.com> > wrote:

THgm > We start the driver by
THgm > Dev.ser 3f8,6 2f8,7 -b 2400 3e8,4 2e8,3 &
THgm > vs
THgm > Dev.ser 3f8,6 2f8,7 -b 2400 3e8,4 2e8,3 338,4 238,3 &
THgm > where the latter causes the crashes.

It’s been awhile since I’ve worked on QNX4 but I seem to remember an
issue where if Dev.ser attempted to access an address of a UART that
didn’t exist, that it hung the system. I never did track down exactly
what about it was hanging the system. I’m guessing a high priority
CPU loop.

Mario Charest postmaster@127.0.0.1 wrote:

MC > Unless all UART sit on a PCI bus you cannot share interrupt.

I have worked on many ISA devices where several devices on the same
card
shared interrupts. The key is that only one IAS card can use a
specific interrupt.

BC > card* shared interrupts. The key is that only one IAS card can use a
^^^
ISA

“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:bra0d2$rfm$2@inn.qnx.com

BC > card* shared interrupts. The key is that only one IAS card can use a
^^^
ISA

Some cards can share interrupt (serial card from quatech are good example).

Just wondering,

Since he is defining Dev.ser to use 6 IO ports, and where 2 pair of these
ports share the same interrupts, would there not be a problem if both ports
received data at the same time yet only 1 interrupt is signalled? I think
the whole problem is the interrupt sharing by Dev.ser, not the hardware.
Can you define the existance of a serial port without assigning it an
interrupt? I don’t know if these ports are being read via. the interrupt or
polled, but my guess is that the serial driver gets all tangled up in its
own socks on that one.

“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:br9tt5$q78$1@inn.qnx.com

Mario Charest postmaster@127.0.0.1 wrote:

MC > Unless all UART sit on a PCI bus you cannot share interrupt.

I have worked on many ISA devices where several devices on the same
card
shared interrupts. The key is that only one IAS card can use a
specific interrupt.