Bug 90997 - XFree86 loses keyboard after upgrading to kernel 2.4.20-13.9
XFree86 loses keyboard after upgrading to kernel 2.4.20-13.9
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
9
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-05-16 04:48 EDT by Didier
Modified: 2007-04-18 12:53 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-01-29 08:02:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
lsmod (1.82 KB, text/plain)
2003-05-16 05:32 EDT, Didier
no flags Details

  None (edit)
Description Didier 2003-05-16 04:48:25 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030509

Description of problem:
After upgrading to kernel-2.4.20-13.9, I loose the ability to enter keystrokes
in X after an indefinite amount of time (anything between 2 and 10 minutes).

*ALL* keyboard activity is lost (Caps Lock keyboard lights, [Alt-SysReq-S]
Emergency Sync, [Ctrl-Alt-Fx], etc.).

The mouse still functions.


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

How reproducible:
Always

Steps to Reproduce:
1. [upgrade to 2.4.20-13.9]
2. startx
3. Enter keystrokes in X
    

Actual Results:  After some time, the keyboard ceases to function.

Expected Results:  Ability to continue entering keystrokes.

Additional info:

After either :
- exiting (by means of the mouse) and restarting X (*) ;
- suspending and resuming (laptop : IBM ThinkPad A30p) ;

 keyboard functionality in X seems to be fully and permanently restored, until
after the machine has been restarted (**), after which it occurs again.


(*) after exiting X, keyboard is functional in the console (however, as
mentioned, in X I'm not able to CTRL-ALT-Fx to a virtual console), so X can be
restarted again by means of 'startx'.

(**) due to crash bug #90993, apparently I'm only able to suspend/resume when
not removing USB devices.


Note 1: concerning bug #90993 : I've only been able to reproduce that crash when
resuming in X ; thought I'd mention that here too.


Note 2: this bug is reproducible with both RawHide XFree86-4.3.0-5 and Shrike
4.3.0-2.
Comment 1 Mike A. Harris 2003-05-16 04:56:20 EDT
If you've upgraded the kernel, and now something doesn't work, it stands to
reason that it is a kernel problem, not an XFree86 one, since X has not changed.

It sounds like your kernel has crashed.  Please attach your /var/log/messages
from after this problem occurs.

Reassigning to kernel component.
Comment 2 Mike A. Harris 2003-05-16 04:56:56 EDT
Also attach the output of "lsmod" from while the kernel is running please.
Comment 3 Didier 2003-05-16 05:32:16 EDT
Created attachment 91719 [details]
lsmod
Comment 4 Didier 2003-05-16 05:35:41 EDT
Nothing in /var/log/messages.


Are you sure this is a kernel issue, and not a kernel upgrade-induced XFree86
issue ?

As I reported, I can continue using XFree86 with the keyboard after exiting and
restarting X ; there is no indication of a kernel crash/oops in /var/log/messages.
Comment 5 Didier 2003-05-16 07:58:01 EDT
Additional info :

Note 1 :
I was copying some data between two external IEEE-1394 drives, when
/var/log/messages reported FS problems on one of the external drives (whether
that is a harddisk hardware problem or bugs within IEEE1394/OHCI1394/SBP2
drivers is not relevant here, I suppose).
Since then, I'm experiencing the X keyboard lockup every 5 to 10 minutes.

Please note the FS corruption is limited to one of the IEEE1394 drives, so I am
not yet concluding my laptop hardware platform is falling apart (would be very
coincidental, together with the 2.4.20-13.9 update).


Note 2 :
I already mentioned suspending/resuming to restore keyboard functionality. I
suspended by pressing laptop keys [Fn-F4], not by closing the lid. This implies
that at least (and for now, exclusively) the special (hard-wired) keyboard keys
are recognized.



For now, I'm obliged to rollback to 2.4.20-9, security fix or not. This is
pretty painful, as I'm in the midst of setting up several (to be exposed) new
servers with RHL 9 (yes, I am aware of RH ES/AS :-(  ).
Comment 6 Didier 2003-05-16 14:59:24 EDT
Putting left foot in mouth :

I just experienced the lost keyboard behaviour with kernel-2.4.20-9.

I'm assessing my latest RPM installations, and apart from the obligatory
RHN-updates (kde, xinetd, kernel & tcpdump), I only installed mozilla-1.4b
(RawHide) and alsa-0.9.3a (FreshRPMs).

I already reverted to OSS, to exclude ALSA, but it strikes me as odd that the
keyboard lock usually (but not always) happens when typing in Mozilla. As I've
been running mozilla-1.4b_gtk2 (mozilla.org) for a while without problems, I'm
very hesitant to cry wolf a second time, so I'll refrain from reassigning to the
mozilla component.

Any suggestions to debug this ?
Comment 7 Didier 2003-05-19 03:59:00 EDT
As I'm experiencing some strange anomalies with 2.4.20-9 now too, I'm having my
machine serviced.

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