From: Ralph Becker-Szendy (ralph@aixgto01.SLAC.Stanford.EDU)
Date: 05/31/93


From: ralph@aixgto01.SLAC.Stanford.EDU (Ralph Becker-Szendy)
Subject: [Answer] Serial ports 0/2 and 1/3 don't work at the same time
Date: Mon, 31 May 1993 21:00:43 GMT

This morning, I asked the following question (edited):
> Problem in a nutshell: Whenever serial port 0 (a.k.a. ttyS0 or cua0)
> is open, port 2 doesn't work and vice versa. Same with ports 1 and 3.
> The ports are at addresses 3F8,2F8, 3E8, 2E8, and on IRQ 4, 3, 4, 3.
> "Is open" means an application program, such as getty or login or
> kermit or X (in the case of the mouse) is using it.

Thanks to the following nice people who quickly answered it:
stevev@miser.uoregon.edu (Steve VanDevender)
edmonds@edmonds.home.cs.ubc.ca (Brian Edmonds)
Kenneth Hamer <khamer@seattleu.edu>
bsa@kf8nh.wariat.org (Brandon S. Allbery)
kstark@garbo.uwasa.fi (Kristian Stark)

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.

A similar problem occurs with the printer port (I have two): When
using the polling driver, they can probably share an interrupt (which
is somewhat irrelevant), but not when using the the (optional but
faster) interrupt driver. The "common" interrupt assignment for the
second parallel port is IRQ 5, which conflicts with 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).

Again, thanks for all the answers in such a short time. I have cancelled
the original question, to reduce traffic on c.o.l.

-- 
Ralph Becker-Szendy                                 RALPH@SLAC.STANFORD.EDU
Stanford Linear Accelerator Center                      RALPH@SLACVM.BITNET
M.S. 95, P.O. Box 4349, Stanford, CA 94309                    (415)926-2701
My opinion. This is not SLAC, Stanford U, or the US DoE speaking. Just me.