What particularly impresses me about this bug is that several months
(maybe more than a year) ago I explained to Bill several times why
this change wouldn't work as is.  I sincerely hope that some day
people will start LISTENING when the author of a piece of code tells
them their change WON'T WORK CORRECTLY; I'm getting rather tired of
repeating this experiment.

Now, lest I be accused of not providing any technical information
(though I've already been over this a bazillion times), the change is
broken in the following way:

cs_rr0 is currently only updated by modem status change interrupts.
This means that if DCD is asserted while CLOCAL is set, when CLOCAL is
later cleared, the cached DCD value in rr0 may be wrong.  In addition,
the tty layer's idea of the carrier status may also be wrong.  The net
result is that the tty layer will think the modem has hung up.  This
is precisely what happens when you dial a modem, and is the bug that
Matt and James observed.

Just updating rr0 there isn't enough.  For it to work correctly in all
cases, everything that zstty_stint() does might have to be done at
this point.  Calling zstty_stint() isn't quite enough, either; we may
have already updated rr0 but not called the line discipline yet.  What
we need to do is run zstty_stint() to catch up rr0 (and possibly stop
output, if flow control state has changed), and then update the line
discipline's carrier status explicitly.  (Note: There is already code
to do the latter part later on.)