This reminds me of a nasty problem that took ages to find in the bygone
years of converting from V7 UNIX to System III (and then System V) UNIX
(ugh). The serial ports of the systems we made would lock up under System
V, but not V7, and only for "slow" speeds like 1200/2400 baud (no problems
at 9600). We didn't know why, but it felt like some kind of race condition.
It turned out (after a long and arduous bug quashing effort) that the UART
was getting its parameters bashed in the middle of outputting a character
under System V UNIX. The UART, understandably, did not like this very much,
and would lock up. We had to reset/reboot the system to get the locked up
ports back. This puzzled us a whole lot, since the UART driver code had
really not changed between V7 and System V (aside from the glue to the
higher level routines).

After we stared at the problem for a while, we figured out why. In the V7
tty(4) man page, the ioctl for setting the port parameters after waiting
for output to drain was documented before the ioctl which set the
parameters without waiting. In the System V manual pages, the order was
reversed. A quick grep of the sources confirmed that most System V programs
that fiddle tty state were using the immediate "don't wait" ioctl, and our
driver was simply doing what it had been told to do: immediately stomping
the UARTs into the requested state. At 1200 baud, the probability of this
happening while the UART was transmitting was fairly high. The problem was
there in V7 also, but had never been tripped over, because the programs for
that system generally used the polite "wait until you're done" ioctl.

We changed the serial I/O device driver to defer UART mode changes (no
matter which ioctl was used) until the next transmit interrupt. Problem
solved.

Moral: never, ever, step on a UART's modes when it is in the middle of
trying to actually do something with a character. They don't like it.

Question: do NetBSD's serial drivers bother to wait?

	Erik Fair