Bug 80293 - No keyboard after Skip cd check
No keyboard after Skip cd check
Status: CLOSED RAWHIDE
Product: Red Hat Public Beta
Classification: Retired
Component: kernel (Show other bugs)
phoebe
athlon Linux
medium Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
: 80332 80552 82165 (view as bug list)
Depends On:
Blocks: 79578
  Show dependency treegraph
 
Reported: 2002-12-23 23:50 EST by Nathan G. Grennan
Modified: 2007-04-18 12:49 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-01-20 18:10:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Test program (717 bytes, text/plain)
2003-01-04 10:17 EST, Daniel Resare
no flags Details

  None (edit)
Description Nathan G. Grennan 2002-12-23 23:50:51 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20021216

Description of problem:
Both in the text and GUI installer after I get past the Skip cd check the
keyboard doesn't work. For the text installer this is fatal in that I get to the
Welcome to RedHat Linux where I need to press enter to select OK and it does
nothing. I have tried nofb, noapic, acpi=off, expert, lowres, etc. Nothing helps.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Boot CD
2. type text and press Enter at boot: prompt
3. run through the dialogs till you get to skip cd check and press enter

    

Actual Results:  After that keyboard is useless

Expected Results:  Keyboard to work so I can continue with install

Additional info:

I did see the keyboard work again after it killed X during another bug.
The computer is nothing special and I have never seen my keyboard not work with
something before.

<Rant>
Anaconda could really use a complete rewrite.
</Rant>
Comment 1 Warren Togami 2002-12-24 00:40:10 EST
Which motherboard, what chipset does it have?  What brand and model of keyboard,
USB or PS/2?
Comment 2 Nathan G. Grennan 2002-12-24 00:57:10 EST
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
Comment 3 Nathan G. Grennan 2002-12-24 23:29:12 EST
I tried using the same disc1 on my second computer(ABIT KT7A-RAID, KT133A) and
the keyboard worked in the text installer.
Comment 4 Nathan G. Grennan 2002-12-25 00:03:27 EST
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.
Comment 5 Nathan G. Grennan 2002-12-25 00:10:23 EST
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.
Comment 6 Kazutoshi Morioka 2002-12-25 04:51:36 EST
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.
Comment 7 Daniel Resare 2002-12-27 10:50:09 EST
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.
Comment 8 Michael Fulbright 2002-12-27 11:04:45 EST
Bill any ideas?
Comment 9 Daniel Resare 2002-12-27 11:31:02 EST
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.
Comment 10 Daniel Resare 2002-12-27 12:01:53 EST
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.

Comment 11 Daniel Resare 2002-12-27 12:24:54 EST
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.
Comment 12 Michael Schwendt 2002-12-27 12:57:55 EST
*** Bug 80332 has been marked as a duplicate of this bug. ***
Comment 13 Michael Schwendt 2002-12-27 13:00:49 EST
> 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.
Comment 14 Nathan G. Grennan 2002-12-28 22:21:36 EST
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.
Comment 15 Bill Nottingham 2002-12-30 01:01:59 EST
Arjan, were there any ps/2 driver changes?
Comment 16 Martin Garton 2002-12-30 12:13:00 EST
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.
Comment 17 Michael Schwendt 2002-12-30 12:38:43 EST
Martin, exactly the symptoms you see are covered by the report I've marked as
duplicate already: bug #80332
Comment 18 Bill Nottingham 2002-12-31 23:39:44 EST
*** Bug 80552 has been marked as a duplicate of this bug. ***
Comment 19 Josh Wyatt 2003-01-02 22:20:53 EST
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...
Comment 20 Daniel Resare 2003-01-03 10:39:07 EST
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.



Comment 21 Arjan van de Ven 2003-01-03 10:42:33 EST
I've seen one such case where the ps/2 mouse probing upset the keyboard
controller.... 
Comment 22 Daniel Resare 2003-01-03 11:26:44 EST
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. 
Comment 23 Michael Schwendt 2003-01-03 12:27:45 EST
> 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.
Comment 24 Daniel Resare 2003-01-03 15:02:57 EST
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
Comment 25 Daniel Resare 2003-01-04 10:11:54 EST
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.
Comment 26 Daniel Resare 2003-01-04 10:17:22 EST
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.
Comment 27 Nathan G. Grennan 2003-01-13 01:29:43 EST
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?
Comment 28 Daniel Resare 2003-01-15 17:55:55 EST
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.
Comment 29 Nathan G. Grennan 2003-01-18 01:52:28 EST
kudzu-0.99.88-1 is out and the top of it change log says

* Thu Jan 16 2003 Bill Nottingham <notting@redhat.com> 0.99.88-1

- ps2 probe fixing
Comment 30 av3 2003-01-18 05:19:02 EST
The bug also went for non-ps2 peripherals, like XT keyboards and serial mice....
Comment 31 Nathan G. Grennan 2003-01-18 05:28:16 EST
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.
Comment 32 av3 2003-01-19 08:55:34 EST
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...
Comment 33 Nathan G. Grennan 2003-01-20 08:54:11 EST
Just fresh installed Phoebe2, it still has this keyboard problem during the
installer.
Comment 34 Nathan G. Grennan 2003-01-20 10:41:34 EST
kudzu-0.99.88 still has the same ps/2 probe problem. If no ps/2 mouse you get no
ps/2 keyboard.
Comment 35 Bill Nottingham 2003-01-20 15:27:21 EST
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.
Comment 36 Nathan G. Grennan 2003-01-20 15:52:11 EST
Then why does actually installing 0.99.69 from RedHat 8.0 work and 0.99.88 doesn't?
Comment 37 Bill Nottingham 2003-01-20 15:56:08 EST
Does it hang the keyboard when kudzu runs, or when X starts?

Your previous comments imply the latter.
Comment 38 Bill Nottingham 2003-01-20 16:24:17 EST
*** Bug 82165 has been marked as a duplicate of this bug. ***
Comment 39 Daniel Resare 2003-01-20 17:45:02 EST
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.
Comment 40 Bill Nottingham 2003-01-20 17:48:44 EST
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?
Comment 41 Daniel Resare 2003-01-20 17:59:18 EST
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.
Comment 42 Bill Nottingham 2003-01-20 18:10:04 EST
Oh, duh.

*sigh*

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

Fixed in 89.

Note You need to log in before you can comment on or make changes to this bug.