Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!wuarchive!uunet!opel!johnk
From: johnk@opel.uu.net (John Kennedy)
Newsgroups: comp.unix.i386
Subject: Re: YASPP (Yet another serial port problem)
Message-ID: <304@opel.uu.net>
Date: 27 Dec 89 00:01:18 GMT
References: <10740@attctc.Dallas.TX.US>
Reply-To: johnk@opel.UUCP (John Kennedy)
Organization: Second Source, Inc., Annapolis, MD
Lines: 30

In article <10740@attctc.Dallas.TX.US> cassidy@attctc.Dallas.TX.US (Cassidy Lynar) writes:

> (serial device woes deleted)

Two problems come to mind:

1)  Is another device (typically the first parallel port) using int 5.
    This conflict would not manifest itself under dos, with its
    way of doing one thing at a time.

2)  Microport had a patchable bit mask that was used to write to the
    8259 interrupt controller.  If int 5 was not allocated as the OS was
    delivered, maybe something has to happen to enable it.

The fact that you're getting a character occasionally suggests to me
that a TxRDY interrupt is being looked for, but after a timeout
the next character is sent.  I can't image a serial driver that continues
to send under those conditions, but it may be some kind of a failsafe to
avoid an infinite wait in the driver.  My guess would be the first, a
conflict with another device.

Or, it could be a bug in the driver :-).

John


-- 
John Kennedy                     johnk@opel.uu.uunet
Second Source, Inc.
Annapolis, MD