Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!aramis.rutgers.edu!geneva.rutgers.edu!hedrick From: hedrick@geneva.rutgers.edu (Charles Hedrick) Newsgroups: comp.unix.microport Subject: Re: ^S/^Q problem in SV/AT 2.4 Keywords: ctrl-s/ctrl-q Message-ID: Date: 24 May 89 16:47:42 GMT References: <7632@saturn.ucsc.edu> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 36 To: lcc@ucscb.UCSC.EDU Ken Chapin 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.