lucio@proxima.UUCP (Lucio de Re) (11/25/89)
We have installed a number of the BellTech (now an Intel company)
ACE 8-port intelligent serial controllers in MITAC 386 computers
running SCO Xenix 386 System V Release 2.3.2.
A number of teething problems were resolved by the RTFM technique (I
actually would never have thought that one could find small print in
technical manuals, but the information we eventually found was
equally well disguised!). For those who may come unstuck, our MITACs
normally maps 0xF00000+ into its useable memory space, seemingly
using it as CACHE space. A jumper makes it possible to reserve this
area for memory mapped I/O devices. Initially disabling CACHEing
made the ACE visible to the system; later we found out about the
jumper and successfully re-introduced CACHEing (don't ask me where
it is mapped to now, I actually would prefer not to know!).
I have seen mention here of other individuals having problems with
this device, but the information supplied was too scanty for me to
determine whether their problems were similar to ours:
(a) on enabled direct connect lines, getty receives (and echoes) a
carriage return and line feed every minute (I actually timed it,
and this seems an accurate value), getty then seems to die, gets
respawned by init; with 6 such ports the PIDs climb up to
somewhat ridiculous values very quickly.
(b) occasionally (not too rarely) the ACE device driver reports
multiple error conditions (there is no documentation as to the
meaning of these error messages). I include a few of these error
messages below; sorry about the waste of bandwidth, but
completeness may be important. The configuration that was
responsible for these errors includes two modem lines at ttyA0
and ttyA1 respectively, direct lines at ttya2 through ttya7. The
second last batch of errors seems to have coincided with the
termination of the last newsfeed.
(c) This problem seems to occur only on the first card (up to four
may coexist (and share a single interrupt vector! it's a smart
controller). We have one installation with two such cards and
the second one "seems" not to suffer from the getty problem,
unfortunately it is not used extensively.
(d) I find it a little ominous that the device driver software is
labelled release 0.8, but no later release seems available yet.
Now some accumulated bumf. If anybody can help, we'll greatly
appreciate it.
FROM /usr/adm/messages
Thu Nov 23 0:39:03
... SysV release 2.3.2 kid 5.52 for i80386 Serial Number: ltd027793
device address vector dma comment
----------------------------------------------------------------------------
ACE (SysV) v0.8 (c) 1988 Bell Technologies
card 0 installed
Thu Nov 23 0:39:06
ACE II: card 0: Async Driver, v0.8
Thu Nov 23 1:14:22
ACE II: card 0: rcv before open: port 0 char 10 err 0
Thu Nov 23 1:14:22
ACE II: card 0: rcv before open: port 0 char 4f err 0
ACE II: card 0: rcv before open: port 0 char 4f err 0
ACE II: card 0: rcv before open: port 0 char 4f err 0
ACE II: card 0: rcv before open: port 0 char 4f err 0
ACE II: card 0: rcv before open: port 0 char 4f err 0
ACE II: card 0: rcv before open: port 0 char 4f err 0
ACE II: card 0: rcv before open: port 0 char 0 err 0
Thu Nov 23 21:13:46
ACE II: card 0: rcv before open: port 0 char 10 err 0
Thu Nov 23 21:13:46
ACE II: card 0: rcv before open: port 0 char 4f err 0
ACE II: card 0: rcv before open: port 0 char 4f err 0
ACE II: card 0: rcv before open: port 0 char 4f err 0
ACE II: card 0: rcv before open: port 0 char 4f err 0
ACE II: card 0: rcv before open: port 0 char 4f err 20
ACE II: card 0: rcv before open: port 0 char 0 err 20
ACE II: card 0: rcv before open: port 0 char 4f err 20
ACE II: card 0: rcv before open: port 0 char 4f err 20
ACE II: card 0: rcv before open: port 0 char 4f err 20
Thu Nov 23 21:13:46
ACE II: card 0: rcv before open: port 0 char 0 err 0
Fri Nov 24 20:08:05
ACE II: card 0: rcv before open: port 0 char 10 err 0
Fri Nov 24 20:08:05
ACE II: card 0: rcv before open: port 0 char 4f err 0
ACE II: card 0: rcv before open: port 0 char 4f err 0
ACE II: card 0: rcv before open: port 0 char 4f err 0
ACE II: card 0: rcv before open: port 0 char 4f err 0
ACE II: card 0: rcv before open: port 0 char 4f err 0
ACE II: card 0: rcv before open: port 0 char 4f err 0
ACE II: card 0: rcv before open: port 0 char 0 err 0
Fri Nov 24 21:19:10
ACE II: card 0: rcv before open: port 0 char 10 err 0
Fri Nov 24 21:19:11
ACE II: card 0: rcv before open: port 0 char 4f err 0
ACE II: card 0: rcv before open: port 0 char 4f err 0
ACE II: card 0: rcv before open: port 0 char 4f err 0
ACE II: card 0: rcv before open: port 0 char 4f err 0
ACE II: card 0: rcv before open: port 0 char 4f err 0
ACE II: card 0: rcv before open: port 0 char 4f err 0
ACE II: card 0: rcv before open: port 0 char 0 err 0
----------------------------------------------------------------------------
FROM /usr/spool/uucp/.Log/uucico/olsa99
uucp olsa99 (11/24-20:02:26,13157,0) SUCCEEDED (call to olsa99 )
uucp olsa99 (11/24-20:02:31,13157,0) OK (startup)
... (transfer omitted)
uucp olsa99 (11/24-20:08:05,13157,6) OK (conversation complete ttyA0 387)
uucp olsa99 (11/24-21:09:44,13552,0) SUCCEEDED (call to olsa99 )
uucp olsa99 (11/24-21:09:47,13552,0) OK (startup)
... (transfer omitted)
uucp olsa99 (11/24-21:19:10,13552,12) OK (conversation complete ttyA0 610)
----------------------------------------------------------------------------
Any ideas or suggestions? I will be experimenting further, but other
pressures make it impossible for me to spend too much time on this
problem (it is not YET high pressure!); I will of course provide any
additional information on request.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I used to design nuclear reactors and you should see the code that
engineers and scientists come up with. Yuuuck! Spaghetti everywhere.
-------------------------------------------------- (Kenneth L Moore) -
Lucio de Re ...uunet!ddsw1!olsa99!flagship!lucio
-------------------------------------------------------- lucio@proximaeric@snark.uu.net (Eric S. Raymond) (11/30/89)
In <549@proxima.UUCP> Lucio de Re wrote: > We have installed a number of the BellTech (now an Intel company) > ACE 8-port intelligent serial controllers in MITAC 386 computers > running SCO Xenix 386 System V Release 2.3.2. I have one on my 6386, donated by the nice folks at used-to-be BellTech. > (a) on enabled direct connect lines, getty receives (and echoes) a > carriage return and line feed every minute I haven't seen this on my direct-connect (to an IBM PC serial port). > (b) occasionally (not too rarely) the ACE device driver reports > multiple error conditions (there is no documentation as to the > meaning of these error messages). I *have* seen this. The point of posting what you're reading rather than mailing it is to let the world know that these messages appear to be harmless and that the kernel and UUCP will resynchronize with the card without manual intervention. > Any ideas or suggestions? Benign neglect. I've been running for a couple of months now with no problems. -- Eric S. Raymond = eric@snark.uu.net (mad mastermind of TMN-Netnews)
lucio@proxima.UUCP (Lucio de Re) (12/01/89)
In article <549@proxima.UUCP>, lucio@proxima.UUCP (Lucio de Re) writes: > We have installed a number of the BellTech (now an Intel company) > ACE 8-port intelligent serial controllers in MITAC 386 computers > running SCO Xenix 386 System V Release 2.3.2. > The tty lines whose behaviour had me so baffled have stopped behaving inconsistently since I removed them from the HDB Devices file. Referring to the getty(M) manual pages, I found that getty checks for locks on tty lines IFF they have corresponding entries in this file. The impression conveyed is that the locks are to stop getty grabbing the device, what is left unsaid is that getty also locks the device, but I can only surmise that the lock expires after a minute (the device is LOCKED for cu usage immediately and for a short time after being enabled). This does not matter on normal COM ports, but for some mysterious reason it causes getty to terminate (normally) on the ACE ports. I would dearly like to know how this lock expiry, which seems very poorly documented, interacts with the ACE card to cause the behaviour I have experienced. In the meantime I eliminated the problem by disabling dialout on the guilty ports. Under the few circumstances where it is necessary to have two-way operation, I will use the ttyO* devices as recommended by BellTech. Thanks to eric@snark.uu.net (Eric S. Raymond) and huver@amgraf (?Huver) for their assistance. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > I used to design nuclear reactors and you should see the code that > engineers and scientists come up with. Yuuuck! Spaghetti everywhere. > -------------------------------------------------- (Kenneth L Moore) - > Lucio de Re ...uunet!ddsw1!olsa99!proxima!lucio > -------------------------------------------------------- lucio@proxima