Xref: utzoo comp.unix.questions:18023 comp.sys.intel:1045 comp.sys.ibm.pc:38914 Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!asuvax!mcdphx!mcdchg!ddsw1!olsa99!proxima!lucio From: lucio@proxima.UUCP (Lucio de Re) Newsgroups: comp.unix.questions,comp.sys.intel,comp.sys.ibm.pc Subject: BellTech ACE 8-port intelligent serial controller Keywords: serial controller getty Message-ID: <549@proxima.UUCP> Date: 24 Nov 89 20:01:49 GMT Organization: free range computer systems cc Lines: 136 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@proxima