Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 513934

Summary: Keyboard LEDs constantly lit
Product: Red Hat Enterprise Linux 5 Reporter: Tomas Pelka <tpelka>
Component: kernelAssignee: Pete Zaitcev <zaitcev>
Status: CLOSED ERRATA QA Contact: Red Hat Kernel QE team <kernel-qe>
Severity: medium Docs Contact:
Priority: low    
Version: 5.4CC: dzickus
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-11-25 00:41:04 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
dmesg output
none
log files
none
Test patch 1 - simplest memset for RHEL 5 none

Description Tomas Pelka 2009-07-27 07:37:40 UTC
Description of problem:
LEDs on my USB keyboard Dell SK-8115 light constantly. But only by debug version of kernel booted. Keys (CapsLock, NumLock and ScrollLock) works properly. 

Version-Release number of selected component (if applicable):
2.6.18-159.el5debug

How reproducible:
always

Steps to Reproduce:
1. Boot debug version of kernel.
2.
3.
  
Actual results:
Keyboard LEDs constantly lit.

Expected results:
LEDs should lit only when relevant key (CapsLock, NumLock and ScrollLock) is activated.

Additional info:
This feature was first noticed by kernel 2.6.18-156.

Comment 1 Pete Zaitcev 2010-01-28 00:19:48 UTC
I installed the 2.6.18-159.el5debug on my workstation, but everything works
as usual (e.g. RHEL 5 always forgot to clear the residual NumLock that BIOS
leaves, but otherwise no change from non-debug kernels).

We have to separate possible causes of:
 - Specific unit or type of systems with their BIOS
 - Specific keyboard
 - Something in RHEL

First question:
 - Does this happen on various systems, or just on one specific system?

Also, please attach dmesg (do not drop it into the comments box).

Comment 2 Tomas Pelka 2010-02-02 11:51:00 UTC
Still reproducible on my box (dmesg attached).

Fresh installed RHEL5.5-Client-20100117.0 with 2.6.18-185.el5debug.
Keyboard: Bus 004 Device 002: ID 413c:2003 Dell Computer Corp. Keyboard

No changes in BIOS, non-debug kernel work fine.

Comment 3 Tomas Pelka 2010-02-02 11:52:13 UTC
Created attachment 388274 [details]
dmesg output

Comment 4 Pete Zaitcev 2010-02-19 22:43:33 UTC
Thanks for the dmesg.
Still, the question stands: does this happen also on:
 - other box with the same keyboard
 - same box with a different keyboard

Comment 5 Tomas Pelka 2010-02-24 09:26:52 UTC
Same box other keyboard (Cherry RS 6000 USB and HP SK-2885) works fine.

Comment 6 Pete Zaitcev 2010-02-24 15:52:44 UTC
Another question: what does happen if you unplug the Dell keyboard and
plug it back in while OS is up (debug kernel)? The question is important
because if LEDs turn on, we can trace it with usbmon.

Comment 7 Tomas Pelka 2010-02-24 16:05:46 UTC
I know what you mean.
Try all variants:
1) only non-Del keyboard attahced - LEDs are fine,
2) plug off non-Dell keyboard and plug in my Dell keyboard - all LEDs lit,
3) plug all keyboards (yes I use my desktop with three keyboards) - only LEDs on Dell keyboard lids.

Sounds dtrange, I know.

Comment 8 Pete Zaitcev 2010-02-24 17:35:50 UTC
Perfect! (2) is what I was looking for.

Please do this:

0. Boot affected kernel (debug kernel)
1. Choose a connector to which to plug (it will select the bus number)
2. Plug a keyboard in (no matter which)
3. Look at /proc/bus/usb/devices and find the Bus=# for the keyboard
4. unplug it
5. mount -t debugfs nonedebug /sys/kernel/debug
6. cat /sys/kernel/debug/usbmon/#t > 513934.mon.ok <--- the # is the bus number
7. Plug a "good" keyboard, let it settle, unplug
8. Interrupt cat with ^C
9. Capture dmesg with  dmesg > 513934.dmesg.ok  <--- should match usbmon trace
10. cat /sys/kernel/debug/usbmon/#t > 513934.mon.bad
11. Plug in the Dell keyboard, verify that LEDs are on
    If LEDs are not on, STOP and let me know that it does not reproduce
    You can hit a couple of keys on it now, e.g. try CapsLock
12. Unplug Dell keyboard
13. Interupt cat with ^C, run  dmesg > 513934.dmesg.bad

Attach the 4 resulting files.

Comment 9 Tomas Pelka 2010-02-25 17:03:44 UTC
Created attachment 396330 [details]
log files

Hope I done it correct.

Comment 10 Pete Zaitcev 2010-03-04 06:11:40 UTC
Yes, this is perfect. Unfortunately, there's no difference between the good
and bad cases (we still write same things to switch LEDs). I'll need to think
about the next step.

Comment 11 Pete Zaitcev 2010-03-04 06:32:50 UTC
Actually, I think I may be able to reproduce this. I bought an IBM keyboard
that does the same thing. The non-debug kernel sends normally looking LED
masks:

ffff810136c8ad80 3410506464 S Co:004:00 s 21 09 0200 0000 0001 1 = 04

The debug kernel sends the same value as in included traces in comment #9:

ffff810137e72188 3973996036 S Co:004:00 s 21 09 0200 0000 0001 1 = ac

Which is clearly bogus. The mystery is, why some keyboards are OK with it.

Comment 14 Pete Zaitcev 2010-03-04 16:59:40 UTC
Created attachment 397864 [details]
Test patch 1 - simplest memset for RHEL 5

Comment 15 Pete Zaitcev 2010-03-04 23:49:39 UTC
Please test kernel-debug-2.6.18-191.el5.bz513934.1 for i686 and x86_64
as found at this location:
 http://people.redhat.com/zaitcev/ftp/513934/

Comment 16 Pete Zaitcev 2010-03-05 00:02:06 UTC
Upstream posting:
 http://www.spinics.net/lists/linux-input/msg07327.html
 Subject: "Zeroing the report before setting fields"

Comment 17 Tomas Pelka 2010-03-05 09:45:07 UTC
It works with 2.6.18-191.el5.bz513934.1debug. 

Great job, thanks Pete.

Comment 20 RHEL Program Management 2010-05-20 12:41:06 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 22 Jarod Wilson 2010-05-25 21:10:28 UTC
in kernel-2.6.18-200.el5
You can download this test kernel from http://people.redhat.com/jwilson/el5

Detailed testing feedback is always welcomed.

Comment 24 Pete Zaitcev 2010-11-25 00:41:04 UTC
I'm closing this, this was fixed long time ago.