[comp.unix.microport] ^S/^Q problem in SV/AT 2.4

hedrick@geneva.rutgers.edu (Charles Hedrick) (05/24/89)

Now that all the Uport staff seem to be working elsewhere, we're
starting to get answers to questions that we hadn't been able to
before.  (While I appreciate this, I don't *really* expect plocher and
others to spend the rest of their lives trying to atone for the sins
of Uport.  But we might as well try to get as much out of them as we
can while they're still feeling helpful.)  So I thought it would be
worth asking an old question again: Is there a known fix for the
problem of ^S on the console not being reversible?  By known fix I
mean something that I can somehow do myself (even if it's just to take
modules x, y, and z from the 2.3 version).  I assume from what I'm
hearing here (and one attempt that I made myself) that's it's not
worth calling Uport at this point.

lcc@ucscb.UCSC.EDU (73701000) (05/24/89)

In article <May.23.23.02.11.1989.3024@geneva.rutgers.edu> hedrick@geneva.rutgers.edu (Charles Hedrick) writes:
->
->Now that all the Uport staff seem to be working elsewhere, we're
->starting to get answers to questions that we hadn't been able to
->before.  (While I appreciate this, I don't *really* expect plocher and
->others to spend the rest of their lives trying to atone for the sins
->of Uport.  But we might as well try to get as much out of them as we
->can while they're still feeling helpful.)  So I thought it would be
->worth asking an old question again: Is there a known fix for the
->problem of ^S on the console not being reversible?  By known fix I
->mean something that I can somehow do myself (even if it's just to take
->modules x, y, and z from the 2.3 version).  I assume from what I'm
->hearing here (and one attempt that I made myself) that's it's not
->worth calling Uport at this point.

To the best of my knowledge, the real culprit here is a bug in the one of the
standard keyboard controller chips that is used by many of the generic keyboard 
manufacturers. We actually spent a fair amount of time on this and the part of
the console driver that deals with the keyboard is really correctly coded. We
contacted a few manufacturers and and they are the ones that told us this. We
even got one of the manufacturers to upgrade a keyboard that was sent in by
a customer that had real consistantly bad problems. So you're probably
wondering why the problem got worse from 2.3 -> 2.4 right ? I can't answer
that one fully but I think that it had something to do with the way we were
trying to control the keyboard leds. As a matter of fact, some systems will
completely hang at boot time with 2.4 trying to initialize the keyboard leds.

So the bottem line is that going back to the 2.3 console driver might save
you from keyboard problems but forget it if you've got a non standard ega
or any kind of vga video card.

Ken Chapin

hedrick@geneva.rutgers.edu (Charles Hedrick) (05/24/89)

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.

plocher%sally@Sun.COM (John Plocher) (05/25/89)

In <May.24.12.47.40.1989.3201@geneva.rutgers.edu> Charles Hedrick writes:
>under what circumstances I couldn't ^Q after ^S'ing.  I found a couple

In the 2.4 console driver (and the 3.0e one) there is a patchable 
variable (kd_dontsetleds or some such) that if non-zero keeps the
driver from screwing with the LEDs when doing ^Q^S.  You may want
to play with this...

   -John Plocher (and I don't mind doing this "support" :-)

hedrick@geneva.rutgers.edu (Charles Hedrick) (05/26/89)

Thanks.  By poking around with nm I was able to find the variable.
It's kb_noleds.  It is normally zero.  I set it to one, using

   /etc/patch -k /unix kb_noleds 1

(-k to patch the running system, without -k to patch the file /unix)
^S/^Q now works without hanging.  Unfortunately this disables all
setting of the leds, so num lock and caps lock doesn't show either,
but this is a small price to pay for getting rid of the hanging.

Do you fix kernel problems on Suns too?

plocher%sally@Sun.COM (John Plocher) (05/26/89)

In article <May.25.18.41.10.1989.3473@geneva.rutgers.edu> hedrick@geneva.rutgers.edu (Charles Hedrick) writes:
>Do you fix kernel problems on Suns too?

No, I am in the Portable Window Systems group.  Our charter is to make
Sun's windowing software portable between different OS's and hardware
platforms.  Often this means actually porting the code to the new
platforms, but we would like to focus on portability issues rather than
porting issues.

In practice, we are porting.  Right now we are involved in porting the
X11/NeWS Merged window server to AT&T Unix Vr3 on the WGS 6386.  We are
using both the 1600x1200 Monochrome Cornerstone Video System and the
EGA/VGA.

My development environment (there are 6 of us) consists of a 25Mhz 386
clone, lots of disk space, and a Sigma VGA.  Other setups we have are
Compaqs (W/Compaq VGA) and AT&T WGS 6386s (W/AT&T EGA & VGA).  Everyone
else is using ATT Unix V/386 3.2 with Micom/Interlan TCP/IP boards and
software.  I am using Wollongong TCP/IP + NFS (Love it).  I'm not
using Everex Unix because they don't have TCP avaliable yet.  Ditto
ISC.

By the end of the Summer we should be running this stuff on a 386 under
Vr4 :-) - I will keep the group posted on that adventure!

The server we are developing uses a "standard" Console Driver ioctl()
to get the resolution et al from the driver, so it should run under ISC
and Everex's Unix also.  This is an AT&T Unix specific ioctl which
queries the console driver about the hardware resolution of the
screen.  Another ioctl which manages the virtual consoles is also
utilized.  Vendors are free to implement ioctls however the wish, so
this isn't a standard as such, but ISC and Everex shouldn't have
changed things that much from the ATT supplied descriptions...

   -John Plocher