From: pdh@netcom.com (P D H) Subject: Re: [Answer] Serial ports 0/2 and 1/3 don't work at the same time Date: Mon, 31 May 1993 22:27:11 GMT
ralph@aixgto01.SLAC.Stanford.EDU (Ralph Becker-Szendy) writes:
>The answer is: You can NOT share interrupts between "dumb" serial
>devices which are used simultaneously; not under Linux, not under DOS.
>The solution is to rejumper two of the four serial ports to use
>different interrupts (or to get an AST fourport or 16-port board,
>which has one interrupt for the whole thing and is supported in the
>normal Linux kernel). It seems a "common" layout is to use IRQ 5 for
>COM3.
....
>Note: AST multiport boards implement interrupt sharing corrrectly, and
>are supported under Linux. Interrupt sharing is also implemented in
>EISA and MCA, but not supported by Linux. And I would think it should
>be possible to support interrupt sharing in software with a slight
>performance penalty: the driver a.k.a. serial.c knows which ports
>share interrupts, in the service routine it polls all the ports which
>could have caused the interrupt. I'll stare at the source code and see
>whether I can get that to work (just for fun).
There are two issues involved in interrupt sharing. The first of concern
is whether there is hardware compatibility between the devices to allow
them to share. This is where a lot of the problems really come from.
Many devices are simply designed with the assumption than they will be
the only device in the IRQ line, and will wire it in such a way that if
another device is sharing it, the other device's interrupts will be so
loaded down electrically than they never cause anything to happen. If
both boards are like this, you lose everything. Sometimes one may work
and give you the impression that something is wrong with the other one,
which in fact that problems could well be in the working board.
There is also the software issue, which you have addressed. When an
interrupt does occur, where did it come from? Linux does handle this
OK (at least if the devices are responsive to standard commands at the
time the kernel is initializing).
It is not hard to design a board to share interrupts, but it does add
somewhat to the cost. Since so little software does handle shared
interrupts, most boards are not designed for it since everyone would
prefer to buy the board that is a few dollars cheaper. Basically there
is too little demand for hardware to support it because there is too
little software that does, and there is too little demand for software
to support it because there is too little hardware that does.
IMHO, the software side should do it first because it is cheaper to do it.
Linux is a good start.
-- /***********************************************************************\ | Phil Howard --- KA9WGN --- pdh@netcom.com | "The problem with | | depending on government is that you cannot depend on it" - Tony Brown | \***********************************************************************/