Which motherboard, what chipset does it have?  What brand and model of keyboard,
USB or PS/2?

MSI KT3 Ultra2(VIA KT333)

Cheap($10) generic(Micro Innvocations) PS/2 keyboard from CompUSA

Logitech Optical USB Wheel Mouse which works fine with the installer

I tried using the same disc1 on my second computer(ABIT KT7A-RAID, KT133A) and
the keyboard worked in the text installer.

Did more testing and figured out why my second computer worked and my main
computer didn't. On both computers if there was no mouse you got no keyboard in
the text installer. On both computers if you used a USB mouse you got no
keyboard in the GUI and text installer. On both computers if you used a PS/2
mouse or USB mouse with PS/2 adapter you the keyboard worked in the text and GUI
installer. So now we have a workaround.

To clarify this is with a PS/2 keyboard and I tried two different PS/2 keyboard.
One with straight PS/2 and one AT with PS/2 adapter.

I got the same problem on my Duron with PS/2 keyboard from DTK.
Motherboard is Biostar M7VKS. Chipsets are VIA KLE133.
I'm using serial mouse.
Motherboard's USB is disabled in BIOS menu.

I connected a PS/2 mouse and install again; the keyboard worked.

It seems this problem is related VIA chipset and non-PS/2 mouse.

I can confirm that the keyboard stops working at the welcome screen in text mode
install when the USB mouse is plugged in (or no mouse is plugged at all).
Plugging in a PS/2 and rebooting solves the keyboard problem. I have only tested
text-mode install.

I have an MSI board with Intel PIIX4 chipset.

Bill any ideas?

When i plug in my usb mouse again and reboot the system the keyboard doesn't
work at all (i can't flash the caps-lock light or press 'y' to start kudzu at
boot. (it works in grub but not after the kernel has been loaded)

This leads me to believe this is a kernel issue.

Some more testing shows the following:

Keyboard works (I can flash the caps-lock) from boot until the "Welcome To
Kudzu" screen shows up where it stops working (and logiacally i can not start
kudzu before it times out). Then it starts working again until X starts.

If I change runlevel to 3 I can log in with the keyboard, but when i type
'startx' the keyboard stops working. When exiting X it never starts working again.

This whole problem vanished after downgrading to kernel-2.4.18-19.8.0 from
redhat-8 errata. I suppose this means that the bug should be moved to kernel.

*** Bug 80332 has been marked as a duplicate of this bug. ***

> I suppose this means that the bug should be moved to kernel.

You mean Kudzu, not kernel? Phoebe's 2.4.20-2.2.athlon kernel works fine on my
Valhalla machine.

After I finally got Phoebe installed I have the keyboard problem. I couldn't use
it during kudzu. Then I could at the login prompt till X came up and then I
couldn't for the X login. So I shutdown the machine, reconnected the usb mouse
with a ps/2 adapater, and booted. It now works.

Arjan, were there any ps/2 driver changes?

I have what appears to be the same problem. I have an undetected serial mouse,
so after skipping the mediacheck, the "mouse not detected" screen appears with a
choice of "ok" or "use text mode" but I cant select any because the keyboard
appears useless. numlock does not work, nor does ctrl-alt-del.

In case it matters, it's a i440BX based machine.

Martin, exactly the symptoms you see are covered by the report I've marked as
duplicate already: bug #80332

*** Bug 80552 has been marked as a duplicate of this bug. ***

I'm seeing the same thing on my machine.  It's an FIC VA-503+ (AT) super 7
board, VIA MVP3 chipset, running a K6-2/500.  Installed are a PCI SB 128, AGP
Voodoo3/3000 16MB, generic USB PCI card, Promise dual DMA/100 IDE PCI card,
hardware ISA 56k modem.

Running 7.3 on the machine just fine.

After probing for the mouse, the next screen tells me none are found, that we
must continue in text mode, but no input is accepted from the keyboard.

I have tried removing the modem, IDE card, and USB card, each in succession
until none were installed, same result.

It happens with or without the mouse attached.  The mouse is a serial mouse. 
The keyboard is an AT.

Looks to me like some sort of probe is hosing the keyboard...

Has the problem been reproduced over at redhat? If not I can volunteer to binary
search for the kernel change that introduced the problem for me, given that
there is a possibility to download the internal/testing kernel rpms somewhere.

I've seen one such case where the ps/2 mouse probing upset the keyboard
controller.... 

Please note from my description above that the keyboard hangs not only when
kudzu is run but also when XFree86 starts.

To reiterate; shutting of kudzu with '/sbin/chkconfig kudzu off' doesn't give me
a working keyboard in X, downgrading the kernel to rh8-errata does.

If this is indeed not a kernel bug but a behaviour change that should be
compensated for in kudzu, it needs to be compensated for in XFree86 also. 

> Please note from my description above that the keyboard hangs
> not only when kudzu is run but also when XFree86 starts.

I cannot confirm that. No problems with the kernel or XFree86. But I disabled kudzu.

After a long series of reboots and testing i can only come to the conclusion
that arjan is right, this is no kernel issue. These are my findings:

1) I can not reproduce my earlier conclusion that kudzu worked with an earlier
kernel. Now it disables the keyboard (and times out) consistently with both
kernel-2.4.20-2.2 and kernel-2.4.18-19.8.0.

2) Downgrading kudzu to 0.99.69 makes it work on startup

3) When i do the following
   1) remove the usb mouse
   2) insert the ps/2 mouse
   3) reboot the system
   4) let kudzu-0.99.83 configure the ps/2 mouse
   5) remove the ps/2 mouse
   6) remove insert the usb mouse
   7) reboot
   8) let kudzu-0.99.83 try and fail to configure the usb mouse
   9) startx (or go into runlevel 5)
   ..the keyboard hangs.

4) If the configuration is in the state described in 3) and I replace
   thereference to /dev/psaux in the Mouse0 section of   
   /etc/XFree86-4 with a reference to /dev/input/mice the keyboard doesn't hang 
   on when X starts

5) I haven't tested yet (gpm disabled by defult) but I have the feeling that gpm 
   hangs the keyboard also if DEVICE in /etc/sysconfig/mouse points to 
   /dev/psaux or is undefined and /dev/mouse points to /dev/psaux

After some playing around with gpm and strace i found out that if i open
/dev/psaux and write "*n" to it, the keyboard locks until the device is closed.
Kudzu, XFree86 and gpm must be doing something like that.

Created attachment 89126 [details]
Test program

This program locks the keyboard for five seconds on both my i386 machines. One
is a P/133 with serial mouse and one is a PIII/800 with usb mouse.

I found wierd results when checking to see if this issue had been fixed in
2.4.20-2.12. I would have it with a ps/2 mouse, so it worked. Then I would
reboot with a usb mouse, and kudzu wouldn't let me use the keyboard, then I
could type at the console, then X would come up and I couldn't type in gdm, but
I could use the mouse. Then I would reboot with the ps/2 mouse and then neither
the mouse or the keyboard would work. It would get into X and I would have to
press reset. Then on reboot with the ps/2 mouse it was working again.

I tried reverting 2.4.20-2.12 to pc_keyb.c and pc_keyb.h from 2.4.18-18.8.0. It
had no effect on the problem.

I am back to using my usb mouse after I downgraded kudzu back to the RedHat 8.0
version.

At this point I think all recent kernels have a bug which allows kudzu to hang
the keyboard, kudzu is doing something it shouldn't, or allow of motherboards
have the same bug. It really doesn't matter if it is a motherboard bug or not,
since you aren't likely to get all the motherboard manufactures to fix it and it
may be a design flaw. In which case it would be a matter of workaround. That
leaves kudzu or the kernel. So which is it?

A friend of mine could not reproduce the keyboard hang on his debian/testing box
with my test program. I'm not entirely sure about his reliability, but it could
also be that this is a kernel "oddity" that the debian people have patched.

kudzu-0.99.88-1 is out and the top of it change log says

* Thu Jan 16 2003 Bill Nottingham <notting> 0.99.88-1

- ps2 probe fixing

The bug also went for non-ps2 peripherals, like XT keyboards and serial mice....

As far as I know this bug only relates to ps/2 keyboards not working when there
is a lack of a ps/2 mouse. Which would over serial mice, but not XT keyboards.
If you have issues with XT keyboards, I think you have a different bug.

I posted another bugreport here on bugzilla about my problem with XT keyboards
and serial mice, which was marked a duplicate of this one by RedHat. So if my
latest remark seems off topic to you, then it isn't according to RedHat....
Cannot not find my original bugreport anymore btw...

Just fresh installed Phoebe2, it still has this keyboard problem during the
installer.

kudzu-0.99.88 still has the same ps/2 probe problem. If no ps/2 mouse you get no
ps/2 keyboard.

Hm, ok. In 0.99.88, the code was reverted to the old code which worked in 8.0.
So this sounds more like a kernel issue at this point.

Then why does actually installing 0.99.69 from RedHat 8.0 work and 0.99.88 doesn't?

Does it hang the keyboard when kudzu runs, or when X starts?

Your previous comments imply the latter.

*** Bug 82165 has been marked as a duplicate of this bug. ***

No, it is not a kernel issue. I did a fresh reinstall an hour ago. To get the
USB mouse working I had to do the following:

- connect the mouse with ps/2 converter
- do the install (the keyboard is verified to freeze without ps/2 mouse)
- install kudzu-0.99.69-1 form rh8
- reboot and let that kudzu reconfigure the mouse
- upgrade to kudzu-0.99.88

notting: the kernel behaviour (testable with the attached c program in comment
#26 above) has been there forever. Kudzu used to work around it, it doesn't now
as of 0.99.88.

kudzu has never had *any* code to 'work around kernel behavior.'

Again, for you, at what point does the keyboard freeze - when you start X, or
when kudzu is running?

the keyboard freezes from when someone opens /dev/psaux and writes '*n' to it.
The freeze releases when the /dev/psaux fd is closed.

On my system the lockup is provoked in the following three ways:

- when starting gpm without explicit mousetype configuration
  the autoprobing code of gpm tries to open it as a serial mouse at first, 
  locking it up. The lockup releases when gpm is killed

- when starting X with the /dev/mouse pointing to /dev/psaux

- when running kuzdu > 0.99.69 with a ps mouse configured in 
  /etc/sysconfig/hwconf that is actually removed from the system.
  I have now verified with strace that older kudzu also opens /dev/psaux and 
  sends stuff to it that locks up the keyboard. However older versions of kuzu 
  closs the device before the interactive part starts up, thus releasing the 
  keyboard lockup.

So, what you need to do is to put a 'close(mousefd);' somewhere in kudzu so that
the keyboard is available when the probing is done.

Oh, duh.

*sigh*

I really should put CVS acls in to prevent people from 'improving' the probing code.

Fixed in 89.