Bug 9302 - Kudzu probes locking up keyboard on laptop
Summary: Kudzu probes locking up keyboard on laptop
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kudzu   
(Show other bugs)
Version: 6.2
Hardware: i386 Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
: 5813 10457 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2000-02-10 14:38 UTC by Joe Ceklosky
Modified: 2014-03-17 02:12 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-04-05 14:13:25 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
short test program. (397 bytes, patch)
2000-02-24 18:56 UTC, Bill Nottingham
no flags Details | Diff
updated test program (456 bytes, patch)
2000-02-24 21:04 UTC, Bill Nottingham
no flags Details | Diff
yet another test program. (468 bytes, patch)
2000-04-04 21:21 UTC, Bill Nottingham
no flags Details | Diff

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

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

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)


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

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

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.

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