From smp@clem.systemsix.com  Fri Dec 29 20:37:00 1995
Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id UAA27086
          for <FreeBSD-gnats-submit@freebsd.org>; Fri, 29 Dec 1995 20:36:55 -0800 (PST)
Received: (from smp@localhost) by clem.systemsix.com (8.6.12/8.6.12) id VAA00509; Fri, 29 Dec 1995 21:36:17 -0700
Message-Id: <199512300436.VAA00509@clem.systemsix.com>
Date: Fri, 29 Dec 1995 21:36:17 -0700
From: smp@csn.net
Reply-To: smp@csn.net
To: FreeBSD-gnats-submit@freebsd.org
Subject: sio output looses chars in fifo on close()
X-Send-Pr-Version: 3.2

>Number:         920
>Category:       kern
>Synopsis:       sio output looses chars in fifo on close()
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bde
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Dec 29 20:40:02 PST 1995
>Closed-Date:    Tue Dec 17 03:33:25 PST 1996
>Last-Modified:  Tue Dec 17 03:42:31 PST 1996
>Originator:     Steve Passe
>Release:        FreeBSD 2.1-STABLE i386
>Organization:
--
Steve Passe
smp@csn.net
>Environment:

	P5/pci/boca 8-port serial card

>Description:

	The sio driver disables the fifo (of 16550 class chips) in
        sioclose() -> comhardclose().  This appears to 'loose' characters
        currently in the uart.  If the port is open by another process
        ( as in "cat > /dev/ttyd4" ) the problem doesn't occur.

>How-To-Repeat:

	echo characters to a serial port connected to an external monitoring
	device.  Note that you CANNOT merely send them back in thru a hard wire
	and monitor with a "cat < /dev/ttyd4" as this keeps the port open and
	'hides' the problem.  Although I haven't tried it, I suspect you could
	wire the output of ttyd4 to the input of ttyd5 and monitor it that way.

	echo 1 2 3 4 5 6 7 8 9 0 > /dev/ttyd4

	will get the "1 2 3 4 5 6 7 8" out the port but loose "9 0"

>Fix:
	
	removing/disabling lines 989-996 from src/sys/i386/isa/sio.c 'fixes'
	the problem:

>	if (com->hasfifo) {
>		/*
>		 * Disable fifos so that they are off after controlled
>		 * reboots.  Some BIOSes fail to detect 16550s when the
>		 * fifos are enabled.
>		 */
>		outb(iobase + com_fifo, 0);
>	}


>Release-Note:
>Audit-Trail:

From: Bruce Evans <bde@zeta.org.au>
To: FreeBSD-gnats-submit@FreeBSD.ORG, smp@csn.net
Cc:  Subject: Re: kern/920: sio output looses chars in fifo on close()
Date: Sat, 30 Dec 1995 17:57:39 +1100

 >	The sio driver disables the fifo (of 16550 class chips) in
 >        sioclose() -> comhardclose().  This appears to 'loose' characters
 >        currently in the uart.  If the port is open by another process
 >        ( as in "cat > /dev/ttyd4" ) the problem doesn't occur.
 
 ttywait() is supposed to have waited until output has completed (except
 in non-blocking mode).  However, it doesn't because TS_BUSY is cleared
 too early (when all output has been written to the fifo, not when output
 is complete).  This isn't easy to handle correctly since there is no
 interrupt for output-complete.
 
 Output would also be lost or garbled when the line state is changed,
 except comparam() waits for output to complete because some UARTs lock
 up if their speed is changed while they are active.  Some internal
 modems are reported to loop endlessly in the wait in comparam().  This
 may be because they don't [correctly] implement the LSR_TSRE
 (transmitter shift register empty) bit that must be polled to to decide
 when to clear TS_BUSY.
 
 Bruce
Responsible-Changed-From-To: freebsd-bugs->bde 
Responsible-Changed-By: scrappy 
Responsible-Changed-When: Wed Apr 10 11:30:27 PDT 1996 
Responsible-Changed-Why:  
sio falls under Bruce's domain 
State-Changed-From-To: open->closed 
State-Changed-By: bde 
State-Changed-When: Tue Dec 17 03:33:25 PST 1996 
State-Changed-Why:  
Fixed in rev.1.152 of sio.c (1996/11/30).  TS_BUSY is handled correctly 
in the driver now. 
Also fixed in 2.2. 
Not fixed in -stable. 
Not fixed in cy.c. 
Not investigated in other drivers. 
>Unformatted:
