Red Hat Bugzilla – Bug 9302
Kudzu probes locking up keyboard on laptop
Last modified: 2014-03-16 22:12:27 EDT
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.
Are there any messages in /var/log/messages around the
time that the keyboard is disabled?
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
The very first thing before the keyboard selection is the
general newt startup; does it lock up as soon as the screen
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
*** Bug 5813 has been marked as a duplicate of this bug. ***
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.
What happens if you run something like 'Xconfigurator' or 'setup'?
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.
Again, does this happen only in the installer and kudzu,
or in other newt-based apps, such as 'Xconfigurator'
There are NO lock ups running authconfig or Xconfigurator.
OK, I'm going to attach a short program. Does it exhibit
the same behavior?
Created attachment 129 [details]
short test program.
Yes. This program does lock up my notebook keyboard. (me as of #5813 - sorry for
not responding earlier, I was on vacation)
(or does it return?)If you strace the program, where is it hanging at?
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 :)
Created attachment 131 [details]
updated test program
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. ;)
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
If you start gpm at boot, does it also hang the keyboard?
Also, when the keyboard locks up, are there any messages in the
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
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?
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.)
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.
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.
OK, finally got ahold of a laptop here that exhibits this behavior
Does the new attachment (psaux3.c) cause the keyboard to lock
Created attachment 187 [details]
yet another test program.
*** Bug 10457 has been marked as a duplicate of this bug. ***
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?
Because there's no reason to *need* the sleep there; did
it work OK before you upped the sleep to 10 seconds?
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.
Fixed in kudzu-0.38; will be fixed in the installer whenever it's
rebuilt against that.