A colleague reported that the keyboard of his brandnew laptop
is dead under 2.6 while 2.4 works.

Now I once wrote

  In order to avoid interference between scancode sequences
  or mouse packets and the reponses given to commands,
  the keyboard or mouse should always be disabled before
  giving a command that requires a response, and probably
  enabled afterwards. Some keyboards or mice do the disable
  automatically in this situation, but still require an
  explicit enable afterwards. 

(http://www.win.tue.nl/~aeb/linux/kbd/scancodes-9.html)

This is what happens on this laptop. The routine atkbd_probe()
probes for a keyboard, and after detecting it, enables it.
But immediately afterwards the routine atkbd_set_3() reads
the current scancode set and sets the desired set, and as a
side effect of these commands, the keyboard gets disabled again.

Thus, the keyboard enable must be moved after all command sending
has been done.

Now that I patch this area anyway: we are almost always in
scancode set 2 but send the ATKBD_CMD_SETALL_MB command
that only works in scancode set 3. At best this is useless.
At worst it confuses the keyboard. So, I put this command
in a separate routine and call that only when we really
are in scancode set 3.