Subject: Problems with no keyboard interupt on GateWay computers
To: None <current-users@sun-lamp.cs.berkeley.edu>
From: John C. Hayward <johnh@david.wheaton.edu>
List: current-users
Date: 01/20/1994 23:23:56
Dear NetBSDers,
   At least four people report problems in that the keyboard locks up when
booting Gateway computers with kernels built from current sometime after
Dec-4 to Jan-20.  One person reports they had problems but they were resolved.

People with Gateways which systems will lock without a keystroke durring boot.
Drew Hess 	dhess@CS.Stanford.EDU
Mike Long	Mike.Long@analog.com
Marc WANDSCHNEIDER storm@mnementh.cs.mcgill.ca
John Hayward	johnh@wheaton.edu  I also have same problems with PS/ValuePoints

People with Gateways which report the problem has been resolved.
Adrian Hall 	adrian@lemmings.cursci.com

I put in some display code in pcrint routine and it shows an interupt
not associated with any keystroke just before the wd extra interupt on booting.

If you type a key before the first read from the system (login prompt)
then the interupt routine is called (twice once for key down and once
for key up).

If you wait until after the first read from the system only the "extra"
keyboard intrupt occures and you are locked out.

By hacking arround I also discovered if you put some display statments in
the cursor routine thru the first 6 opens of pc the problem goes away if
you are not going directly into X windows.

This problem is a major pain for me since I wanted to have a system with
shared libraries for a lab setting in which people will be booting the
system periodically.

I request three things:

1) Other Gateway or PS/ValuePoint users to report their success and failures
   for the NetBSD-current kernels after Jan-1 to me.

2) Some explainations on how the process works from the time a read is 
   requested until it returns from the read.  I assume that the read
   calls some upper level tty routines which if there are no characters
   pending causes the current process to get blocked.  At some point the
   keyboard is struck which generates an interupt request 1 and the interupt
   controller determines if this level interupt can interupt the CPU and
   then uses some vector to transfer control to pcrintr.  At that point the
   character is picked up from the keyboard and put in the buffer and the
   process waiting for the character is marked ready to run.  
   At that point a dispatcher will select a process to run.

   The details I would like filled in are between the key is typed and
   control is passed to the pcrint routine.  Somehow that process does not
   seem to be working correctly.  Please send e-mail as this does not need
   to go out to the general list.

3) Any helpfull pointers to resolve this problem including where I could get 
   a copy of the kernal sources before Dec-4th to try to identify what changes
   have caused this problem.

   Thanks in advance,
   johnh...

------------------------------------------------------------------------------