^S/^Q problem in SV/AT 2.4

Charles Hedrick hedrick at geneva.rutgers.edu
Thu May 25 02:47:42 AEST 1989


Thanks for the response.  I played some more with ^S last night to see
under what circumstances I couldn't ^Q after ^S'ing.  I found a couple
of interesting things:

(1) Both times when this problem has hit me, I was installing the
system.  (I posted the message right after I had to do a reinstall
because of a disk crash.)  So I was running single user on the console
with the kernel from the installation disk.  The hang happens quite
consistently then.  (It was very frustrating.  I needed to see a line
from one of the install scripts.  No editor, more, or even grep was
yet on the system.  So using cat with ^S and ^Q was the only way to
look at the file.)  Once I get the system fully installed, I am unable
to make the hang happen.  I'm not sure why that would be.  Of course
single user I'm running the binary from the distribution disk.  After
installation, I'm running a kernel that I built from the link kit with
a few minor patches (changing keyboard dispatch entries a couple of
places, e.g. to make the caps lock function as a control key, and
replacing the serial driver with a public domain one that was posted
here recently).  I'm also running through the shell layers code, since
I use the version of ksh that emulates Berkeley-style job control
using layers.  Maybe somewhere in all of that is something that makes
the problem not happen.  The best bet is probably shell layers.  I'm
betting that it changes the timing enough to get rid of whatever race
condition is causing the problem.

(2) Normally when I hit ^S, some LED goes on ("no scroll" or something
like that).  When the problem happens, output stops but the LED
doesn't go on.  My theory was that the device driver managed to stop
output but not set whatever bit it used to remember that it had done
so.  So it ignored ^Q because it didn't think that output was actually
stopped.  If that's true, there would be a fairly obvious workaround
(if I had source).

Now that I've verified that the problem can't be reproduced once I'm
up for real, I guess it doesn't look so urgent.  But if I had to use
the system like it was single user, I'd be really upset.



More information about the Comp.unix.microport mailing list