Bug 9302

Summary: Kudzu probes locking up keyboard on laptop
Product: [Retired] Red Hat Linux Reporter: Joe Ceklosky <jceklosk>
Component: kudzuAssignee: Bill Nottingham <notting>
Status: CLOSED RAWHIDE QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: 6.2CC: elladan, ml, rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-04-05 14:13:25 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
short test program.
none
updated test program
none
yet another test program. none

Description Joe Ceklosky 2000-02-10 14:38:53 UTC
Kudzu....I think is locking my laptop up.  I have a Mitac 5033.  This
is the same problem I found with Beta 5.9, Redhat 6.0, and Redhat 6.1.
It's probes are locking the keyboard up.  To get around it I have to put
he laptop to sleep using the hardwired sleep key combination and then
turn it back on.  The keyboard will be unlocked.

Please cheack to see what this program is doing that could lockthe
keyboard up!!!  Or please tell me how I could debug this for you.

I am using he 6.2 Beta release.

Comment 1 Bill Nottingham 2000-02-14 23:32:59 UTC
Are there any messages in /var/log/messages around the
time that the keyboard is disabled?

Comment 2 Joe Ceklosky 2000-02-15 04:06:59 UTC
It might not be kudzu.  What runs just before the language selection
dialog comes up in text mode install?  I flipped over to another v-terminal
and the last message I see is:

...
* going to insmod fat.o (path is NULL)
* going to insmod vfat.o (path is NULL )

Also there is no /var/log/messages file on the initial install root file
system.

Comment 3 Bill Nottingham 2000-02-15 04:12:59 UTC
The very first thing before the keyboard selection is the
general newt startup; does it lock up as soon as the screen
turns blue?

Comment 4 Joe Ceklosky 2000-02-15 04:18:59 UTC
It locks up as soon as the language selection screen comes up.
So the screen is blue for a second then language selection is up and the
keyboard is locked.
Shutdown the notebook down to memory using the hotkey and turn it back on it's
unlocked.

Comment 5 Bill Nottingham 2000-02-16 16:10:59 UTC
*** Bug 5813 has been marked as a duplicate of this bug. ***

Comment 6 Joe Ceklosky 2000-02-18 19:59:59 UTC
Can we now start looking at how to track this down rather than pointing
this back to another bug report.  What is it that kudzu is doing that
it can mess up the keyboard?  Blocking interrupts?  I have the same
problem when kudzu runs to detect new hardware.  The keyboard is dead.

Comment 7 Bill Nottingham 2000-02-18 20:04:59 UTC
What happens if you run something like 'Xconfigurator' or 'setup'?

Comment 8 Justin Husted 2000-02-19 08:22:59 UTC
This seems to be happening on my Compaq LTE 5100.  It occurs during a network
ftp install immediately after the "loading second stage ramdisk" finishes.

If I sleep the laptop, then unsleep it, the keyboard works again.

Unfortunately, sleeping it turns off the PCMCIA devices, thus shutting down
the network, thus making a network install impossible since it doesn't reset
the pcmcia bus later.

Comment 9 Bill Nottingham 2000-02-21 15:57:59 UTC
Again, does this happen only in the installer and kudzu,
or in other newt-based apps, such as 'Xconfigurator'
or 'authconfig'?

Comment 10 Joe Ceklosky 2000-02-24 03:54:59 UTC
There are NO lock ups running authconfig or Xconfigurator.

Comment 11 Bill Nottingham 2000-02-24 18:55:59 UTC
OK, I'm going to attach a short program. Does it exhibit
the same behavior?

Comment 12 Bill Nottingham 2000-02-24 18:56:59 UTC
Created attachment 129 [details]
short test program.

Comment 13 Mario Lorenz 2000-02-24 20:05:59 UTC
Yes. This program does lock up my notebook keyboard. (me as of #5813 - sorry for
not responding earlier, I was on vacation)

Mario

Comment 14 Bill Nottingham 2000-02-24 20:38:59 UTC
(or does it return?)If you strace the program, where is it hanging at?

Comment 15 Mario Lorenz 2000-02-24 20:54:59 UTC
It returns. It detects the Mouse (the built in touchpad) properly and returns
to the prompt. However, the keyboard is gone by then.. Doesnt respond to any
keys, not even to sleep. The power key works, though :)

Comment 16 Bill Nottingham 2000-02-24 21:04:59 UTC
Created attachment 131 [details]
updated test program

Comment 17 Bill Nottingham 2000-02-24 21:06:59 UTC
Does the new psaux2.c program fare any better?
There's no real reason for it to lock up the keyboard,
but you knew that. ;)

Comment 18 Mario Lorenz 2000-02-25 03:35:59 UTC
Nope, keyboard still hangs.
No real reason... Well, yeah, no real reason.... Hmm, I have no idea about how
PSAUX is supposed to work, but since mouse and keyboard interface are the same
controller/port, it kinda makes sense. And since you do only a read on that
file, it would look to me like more a problem in the psaux driver than in
kudzu..

Comment 19 Bill Nottingham 2000-02-25 15:05:59 UTC
If you start gpm at boot, does it also hang the keyboard?

Comment 20 Bill Nottingham 2000-02-25 15:25:59 UTC
Also, when the keyboard locks up, are there any messages in the
system logs?

Comment 21 Mario Lorenz 2000-02-25 23:59:59 UTC
See #5813 - GPM works just fine. However there is a nice twist: While GPM is
running, psaux.c doesnt hang the keyboard either.
However as soon as I stop GPM, and try it again -> kaboom
PS: Unless you respond today or early tomorrow (saturday) I wont be available
for another week - sorry

Comment 22 Joe Ceklosky 2000-04-04 19:16:59 UTC
After reinstalling 6.2 the same keyboard locking is there on the language
selection screen.  Putting the laptop to sleep ad waking it up unlocks the
keyboard.

Also when kudzu runs (when it's trying to detect new hardware), it counts
down from 10 to 1.  During this period the keyboard does NOT repsond as well.
What is KUDZU doing while it is counting down or what did it do to the keyboard
just before starting the count down?

Comment 23 Bill Nottingham 2000-04-04 20:42:59 UTC
The countdown is most likely the countdown to enter the hardware
config screen before it times out (I'm assuming the
"Welcome to Kudzu" dialog is showing at this point.)

(yes, we didn't get a chance to get this fixed before 6.2; whatever
fix is most likely in the kernel.)

Comment 24 Joe Ceklosky 2000-04-04 21:13:59 UTC
Yes the entire Kudzu screen is up and the counter is counting
down starting at 10 9...

What is Kudzu doing during the count down.

Comment 25 Bill Nottingham 2000-04-04 21:17:59 UTC
Waiting for keyboard input. We don't want the boot process
to hang while we ask the user if they want to configure some
new device, so we set it to time out after a while.

Comment 26 Bill Nottingham 2000-04-04 21:20:59 UTC
OK, finally got ahold of a laptop here that exhibits this behavior
Does the new attachment (psaux3.c) cause the keyboard to lock
up still?

Comment 27 Bill Nottingham 2000-04-04 21:21:59 UTC
Created attachment 187 [details]
yet another test program.

Comment 28 Bill Nottingham 2000-04-04 21:30:59 UTC
*** Bug 10457 has been marked as a duplicate of this bug. ***

Comment 29 Joe Ceklosky 2000-04-04 23:53:59 UTC
The new program does NOT lock the keyboard.  I upped the sleep to
10 seconds and switched virtual consoles with no problem.
How did the old code work?

Comment 30 Bill Nottingham 2000-04-05 01:20:59 UTC
Because there's no reason to *need* the sleep there; did
it work OK before you upped the sleep to 10 seconds?

Comment 31 Joe Ceklosky 2000-04-05 01:52:59 UTC
Sure it worked fine before I upped the sleep value.
I was refering to the old version of the code where you were
opening the device.

Comment 32 Bill Nottingham 2000-04-05 14:13:59 UTC
Fixed in kudzu-0.38; will be fixed in the installer whenever it's
rebuilt against that.