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

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

The following reply was made to PR kern/56143; it has been noted by GNATS.

From: Mouse <mouse%Rodents-Montreal.ORG@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/56143: Serial-line speed switch can corrupt "drained" output
Date: Tue, 4 May 2021 16:53:13 -0400 (EDT)

 >> 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?
 > More likely the hardware is saying that it has transmitted the
 > character when all it has really done is move it to its shift
 > register (and so the output character buffer is free for the next).
 
 Possibly.  Then it's either "the hardware lies" or "the driver turns
 off TS_BUSY before it should", I guess.
 
 I suspect it's the latter, in that com.c turns of TS_BUSY
 unconditionally in com_txsoft, which is probably "FIFO is below
 low-water mark (or moral equivalent, if tiny/no FIFO)" rather than a
 true "transmitter is idle".  Looking at comreg.h, I see LSR_TSRE versus
 LSR_TXRDY, but I don't see anything obvious permitting interrupts on
 LSR_TSRE going active.  It would be ugly to have to poll LSR_TSRE, but
 if it's the only way to get TS_BUSY right....
 
 > The driver would need to test deeper hardware state to tell if the
 > hardware has actually finished transmitting the character, and is
 > fully idle.
 
 The (few) serial-line chips I've looked at things like register bits
 for have had "transmitter is idle" state bits, like LSR_TSRE above, and
 usually interrupt generation logic, which is documented as being what
 we want here.  The 16550A is not among the chips I know, though, and,
 well, see above.  There's also the question of LSR_TSRE tells the real
 truth.
 
 > I'm not even sure if all hardware has a way to return that kind of
 > state (but I semi-recall - it has been a very long time - that some
 > hardware does provide that info).   It would need special case
 > handling in each driver for this ioctl to get this right though.
 
 Well, it seems to me that it's no more special-case handling than the
 driver must already be doing to pilot the hardware.
 
 As for doing something "for this ioctl", by the time they hit the
 driver, TIOCSETA, TIOCSETAF, and TIOCSETAW aren't ioctls any longer,
 and actually aren't even calls into the driver except for a call
 through tp->t_param, unless I've missed something.  Look at kern/tty.c,
 starting with line 1123 in the 9.1 version (tty.c,v 1.281).
 
 					Mouse