kern/56143: Serial-line speed switch can corrupt "drained" output

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>Number:         56143
>Category:       kern
>Synopsis:       Serial-line speed switch can corrupt "drained" output
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue May 04 15:45:00 +0000 2021
>Originator:     Mouse
>Release:        NetBSD 9.1
>Organization:
	Dis-
>Environment:
System: NetBSD Aaeon-9.Rodents-Montreal.ORG 9.1 NetBSD 9.1 (GEN91) #15: Fri Apr 16 12:48:33 EDT 2021 mouse%Aaeon-9.Rodents-Montreal.ORG@localhost:/home/mouse/kbuild/GEN91 amd64
Architecture: x86_64
Machine: amd64

The machine is an Aaeon "industrial" computer with real serial ports.
The serial ports in question attach as

[     1.000003] acpi0 at mainbus0: Intel ACPICA 20190405
...
[     1.047160] com0 at acpi0 (UAR1, PNP0501-1): io 0x3f8-0x3ff irq 4
[     1.047160] com0: ns16550a, working fifo
[     1.047160] com1 at acpi0 (UAR2, PNP0501-2): io 0x2f8-0x2ff irq 3
[     1.047160] com1: ns16550a, working fifo
>Description:
	When using TCSADRAIN to change serial-port speeds, the drain
	operation appears to not drain far enough; it can corrupt the
	last octet (I speculate it can corrupt more than that if the
	hardware in question has more queueing, but that's a guess).
>How-To-Repeat:
	Set the speed to one speed (4800 in our test case).  Write data
	to the serial port (30 octets, in our case).  Change speeds (to
	9600 in our case) with TCSADRAIN before the written data has
	been fully sent.  Note that most of the output is sent
	correctly, but the last octet is corrupted (in our case, 0x0a
	becomes 0xf3 - not that surprising based on the line state
	waveform).

	I don't know why this is; ttywait_timo checks TS_BUSY as well
	as t_outq.c_cc.  Perhaps the com driver doesn't set TS_BUSY
	entirely correctly?
>Fix:
	Unknown.

	For my purposes at the moment, I'm working around it in
	userland by setting with TCSADRAIN|TCSASOFT, then sleeping 5ms,
	5ms because at 4800 each character is a smidgen over 3ms wide
	and 5ms allows a little extra room, then setting with just
	TCSADRAIN.

	Working on 9.1 is unpleasant enough I am not motivated to put
	my own time into this, and work is unlikely to want me to put
	work time into fixing it when we have a workaround.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B