Subject: port-i386/3442: NetBSD com.c doesn't drain hardware FIFO during close
To: None <firstname.lastname@example.org>
From: None <email@example.com>
Date: 04/02/1997 17:06:08
>Synopsis: com.c doesn't drain hardware FIFO during close
>Responsible: gnats-admin (GNATS administrator)
>Arrival-Date: Wed Apr 2 14:20:03 1997
>Originator: David Eckhardt
Carnegie Mellon University Computer Science Department
System: NetBSD piper.nectar.cs.cmu.edu 1.1 NetBSD 1.1 (PIPER) #5: Tue Mar 18 17:50:12 EST 1997 firstname.lastname@example.org:/usr/davide/cmucs-netbsd/src/sys/arch/i386/compile/PIPER i386
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
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)
Sorry, the only UART I understand at all is the Z8530.