> 
> >Date: Mon, 7 Mar 1994 23:43:17 -0800 (PST)
> >From: Jared V Boone <jboone@patriot.wtfd.orst.edu>
> 
> >My computer:
> >
> >   o Intel LP486DX/33 + Overdrive66, 8MB, IDE HD, 3c503, Phoenix BIOS
>                                                           ^^^^^^^^^^^^
> Here's the problem; the keyboard hang seems to strike Phoenix BIOS
> machines and/or machines that use a PS/2 mouse port (interaction w/pms
> driver?).
> 
> >     1.00.07.S0.  Uses a i8742AH, EPROM Program 506425-001 V1.00.1.  PS/2
> >     Style Connector. 
> 
> I don't have more detailed part numbers available, but the keyboard
> controller on my Gateway 2K DX266V's Micronics JX-30 motherboard is an
> Intel i8242, with the label "(C) Phoenix '91" on it.

Just to throw in some more information from a different viewpoint:
From the OS/2 2.1 Installation Guide Appendix G (translated from the German
manual, so not citing the US manual):

[...info about systems that do not work with OS/2 2.1...]
This information are for users of systems from Gateway 2000 and users
of systems with BIOS versions of the following manufacturers:
Phoenix, AMI, Micronics

BIOS from Phoenix
To run OS/2 2.1 you need BIOS version 1.02.05D or later of Phoenix Inc.
(Remark: The above version ID 1.00.07.S0 looks quite old).

BIOS from AMI
The recent BIOS versions show a code in the lower left corner during
memory test...which has one of the following formats:
aaaa-bbbb-mmddyy-Kc or
ee-ffff-bbbbbb-gggggggg-mmddyy-hhhhhhhh-c
If not, you have a very old BIOS, in this case contact Washburn Inc
(USA: ++1-716-248-3627), or you have a BIOS from a manufacturer with
a source license (all 386 versions of Everex). Ask manufacturer.
For correct keyboard operation (of OS/2 2.x) you need the letter 'F'
in position 'c' of the BIOS ID. [...]

If version letter is 'M' or '0' (zero), this means that the controller
is not directly from AMI, even with a license hologram of AMI.
No experiences exist, so proper working (of OS/2 2.1) with these
chips is not guaranteed. Sometimes, but not always, such a non-AMI
chip can be
replaced by an original version. In some cases (usually version '0')
keyboard controllers that perform non-keyboard (system board)
functions, so replacement makes the board unavailable.
[...] Revision ID '9' also means a nonstandard controller (+BIOS).
Contact board manufacturer.

Micronics BIOS
OS/2 may report failures like 'divide underflow'. In this case
it is possible that the system has a revision E motherboard
with an old BIOS. Micronics recommends replacement to a F board
(in particular with systems bought by Gateway 2000).

Gateway 2000
See under Micronics.
(Clarification: the divide underflow occurs with 486 systems, with
a revision E board when an application uses the 486-builtin copro
(!)).

End of excerpt.

My argumentation is the following: Although NetBSD is not OS/2,
several similarities, in particular with protected mode, FP access
etc. apply, so chances are that a system with OS/2 problems
(which has been excessively tested and contains numerous fixes
for system bugs) will also have problems with AnyBSD
(No arguing about NetBSD!=BIOS, while OS/2==BIOS, kbd controlling,
this is untrue in general for the PM parts of OS/2).
If IBM with their large crew of programmers and testers recommends
replacing bad BIOS and motherboard versions, the "@#!$& keyboard
problem" is likely not to be solved by some more KBDATAP flush
or yet another delay loop. Linux, as another protected-mode OS,
is not a counter example, since they are extremely careful to
access the kbd controller in a non-standard way. Non-standard
is already the performing of the RESET command (Linux relies on
a proper reset done by the POST/Init code of the BIOS, so a crash
of the keyboard cannot be recovered (can it be anyway in AnyBSD?))
or an asynchronous issuing of SETLEDS or SETREPEATERATE commands
(instead of setting semaphores and catching the responses by the
interrupt code, see Mach kd.c for example).
I believe that the revision ID of pccons could easily reach 1.200
before we find a all-working-and-satisfying solution to this problem,
if at all.

My proposal is to collect a list of non-working boards/keyboards/BIOS-IDs
(non-working is a system that needs the Numlock trick to startup
to get a precise list of problem cases. This list could be packed
together with the next NetBSD release (1.0) as an anti-shopping-list.
If you send me a detailed spec of such a problem system, I would volunteer
to collect such a list and summarize occasionally (maybe this could become
a FAQ entry as well). Mail to veit@gmd.de with a Subject line containing
at least "PCCONS" (in capitals) to simplify my job to filter information
from junk.

I guess quite a number of systems that fail are among the above 
mentioned systems. Even if YOUR system was bought yesterday noone 
guarantees that a clever manufacturer does not recycle his ancient
chips this way (the dumb DOS users won't discover any difference anyway).

And yet another thing: A hasty look at my BIOS (AMI) shows that the
controller ID (above mentioned as 'c' entry) is likely not hard coded into
the BIOS, as it might have been possible (since 8042 and BIOS eproms
usually belong to gether), but is "calculated" in some way. This
likely requires querying the controller and/or keyboard in some
characteristic, and unfortunately undocumented, way. If someone
knows how to definitely get this information, please report or
mail to me the recipe to this (I myself will dig in my BIOS to find it).
Such code is essential for the pccons probing code.
Also, MS Windows seems to have other special probing code, because
it calls my (really old) keyboard an AT84 type, whereas the keyboard
of my notebook is called AT101/102 (which is not right, but there seems
to be a mark to distinguish them; it is not the transfer protocol used,
I verified this with a logic analyzer).

-- 
         Dr. Holger Veit                   | INTERNET: Holger.Veit@gmd.de
|  |   / GMD-SET German National Research  | Phone: (+49) 2241 14 2448
|__|  /  Center for Computer Science       | Fax:   (+49) 2241 14 2342
|  | /   Schloss Birlinghoven              | Had a nightmare yesterday:
|  |/    53754 St. Augustin, Germany       | My system started up with
                                           | ... Booting vmunix.el ...


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