Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!wugate!uunet!virtech!cpcahil
From: cpcahil@virtech.UUCP (Conor P. Cahill)
Newsgroups: comp.unix.i386
Subject: Re: X5 Update - Serial Bugs
Message-ID: <1255@virtech.UUCP>
Date: 10 Oct 89 18:09:25 GMT
References: <[2531618a:210]comp.unix.i386@tronsbox.UUCP>
Organization: Virtual Technologies Inc
Lines: 63

In article <[2531618a:210]comp.unix.i386@tronsbox.UUCP>, tron1@tronsbox.UUCP (HIM) writes:
> 1) The origional ISC 2.0.x driver.....
>     Well. It doesnt REALLY work well. Many mysterious happenings. 
>     Problems with port sharing. Character loss problems.
> 
> 2) MAXPEED SS8 Inteligent I/O card...
>     The hardware is good, but the driver is not so useful. It works GREAT
>     for terminals. But can't control a modem for its life really. 

	My Maxspeed also has problems under 386/ix, but they differ from yours.

>     Bugs characterized by :
> 
>          I. Hung uucico's

		I have never had a hung uucico on my system (that I noticed).

>         II. The persistant belief that the port is "Device Busy" when it is
>             not opened in any way . Turning the modem off/on will fix.

		This I have run into, but only when I was using cu to talk
	 	to the modem.  It never happened with uucico, maybe just luck.

		I have noticed that the driver does not always drop DTR when
		I disconnect from the modem, but this hasn't given me too
		much problems (other than a large phone bill if I didn't 
		notice it).

>        III. The port will OFTEN refuse to send data OUT (sd).
>             This is most harmefull when you are logged in directly
>             incomming data is correctly acted upon, but character echo is 
>             lost.  I HAVE SEEN this from the host end while on the phone
>             voice with the person logged in. The (sd) light is NOT going on.

		I have seen this problem with my printer.  If I send two 
		jobs to the printar in succession (and the second job gets
		queued before the first job is complete), the second job will
		lock up the port.  This is fixed with the "> /dev/tt..." that
		you mentioned later, or by disabling and reenabling the port.

>             If the user does a "ls -ls" , the hard drive runs, the command 
>             executes, but the result is not transmitted. This bug can be
>             cleared in two ways. One is , as root , do a "> /dev/ttyax" where
>             the device name is the stuck one. Two, wait about 3 minutes and
>             the data will be transmitted.

	The big problem that I have had is that the board does not seem to
	support incomming data at 19200 (from a T2500).  When I upped the 
	speed from 9600 I got spurious input data queued in the tty port for
	a different tty and lost the data from the correct port.  My uucico
	throughput at 9600 baud is around 850 cps, while it is only 300 cps
	at 19200.

	I have called maxspeed and so far they have not been able to help me.


Good luck...

-- 
+-----------------------------------------------------------------------+
| Conor P. Cahill     uunet!virtech!cpcahil      	703-430-9247	!
| Virtual Technologies Inc.,    P. O. Box 876,   Sterling, VA 22170     |
+-----------------------------------------------------------------------+