Subject: Problems with no keyboard interupt on GateWay computers
To: None <firstname.lastname@example.org>
From: John C. Hayward <email@example.com>
Date: 01/20/1994 23:23:56
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 firstname.lastname@example.org
John Hayward email@example.com I also have same problems with PS/ValuePoints
People with Gateways which report the problem has been resolved.
Adrian Hall firstname.lastname@example.org
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
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,