>Number:         3442
>Category:       port-i386
>Synopsis:       com.c doesn't drain hardware FIFO during close
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    gnats-admin (GNATS administrator)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Apr  2 14:20:03 1997
>Last-Modified:
>Originator:     David Eckhardt
>Organization:
Carnegie Mellon University Computer Science Department
>Release:        1.2
>Environment:
	System: NetBSD piper.nectar.cs.cmu.edu 1.1 NetBSD 1.1 (PIPER) #5: Tue Mar 18 17:50:12 EST 1997 davide@piper.nectar.cs.cmu.edu:/usr/davide/cmucs-netbsd/src/sys/arch/i386/compile/PIPER i386
>Description:
	It seems as if the com driver drains only its internal software FIFO
	during close() processing, but does not wait for the hardware transmit
	FIFO to drain before disabling the com port (i.e., turning off the
	clock etc.).
>How-To-Repeat:
	I discovered this by running pilot-link 0.5.0 (available at
	ftp://ns1.pfnet.com/pub/PalmOS/), which communicates with a
	U.S. Robotics PalmPilot organizer via a magic serial packet protocol.
	The problem was that the NetBSD program would finish up all
	transactions and exit, but the Pilot would sit around and eventually
	time out.  Various flush ioctls made no difference, but a sleep(1)
	before the close() ensured a clean termination.  A brief cruise through
	com.c didn't turn up any code which looked like it was checking the
	transmit FIFO status before totally disabling the port.

	A Linux maintainer claims:

		["Theodore Y. Ts'o" <tytso@MIT.EDU>]
		It's already been fixed in the development branch
		of Linux, as of version 2.1.8 or so.  The POSIX
		Compliance Test Suite (PCTS) explicitly tests for
		this case, so I wouldn't be surprised if the
		NetBSD driver gets fixed soon.
		- Ted (The Linux Serial Guy)
>Fix:
	Sorry, the only UART I understand at all is the Z8530.
>Audit-Trail:
>Unformatted: