Description of problem: We have a Dell Chicony USB keyboard (model KU-9985) which fails to work when plugged in. There are ugly messages in /var/log/messages, and "lsusb" will hang. It turns out that this keyboard says that it has both a keyboard and a mouse, though there really is no mouse at all (no PS/2 port, no mouse). When Linux issues a "get_report" for the mouse reports, the keyboard stalls, and things go downhill. This keyboard works fine if we add it to the blacklist with the "NOGET" quirk. Version-Release number of selected component (if applicable): How reproducible: Very easy. Steps to Reproduce: 1. Boot up system. 2. Plug in KU-9985 Chicony usb hub keyboard. 3. Actual results: Keyboard doesn't work, there are ugly messages, and "lsusb" will hang. Expected results: Keyboard should work, lsusb should work normally. Additional info: I will attach the patch.
Created attachment 110212 [details] patch to add this keyboard to the blacklist with "noget" quirk
Created attachment 112198 [details] A cleaned version suitable for application Stuart forgot to diff for patch -p1 and also swapped arguments. Tsk tsk :-) This ought to work a little better.
How embarrassing! Thank you.
I swear this was committed long time ago. I just verified -40.6.EL, the fix is present. Stuart, could you check if U7 has the fix and close the bug?
It doesn't appear to be in U7 (2.4.21-40.EL). I guess it didn't bother too many people, because I never heard anything else about it...
Pete, the patch in comment #2 has never been committed to the RHEL3 kernel, and there is no reference to USB_VENDOR_ID_CHICONY in any of my patch tracking files (across all updates).
Oh yuk, it appears that I made Stuart to work for nothing, because I confused unpacked trees locally. I very, very sorry.
:) It was really no problem.
This bug is filed against RHEL 3, which is in maintenance phase. During the maintenance phase, only security errata and select mission critical bug fixes will be released for enterprise products. Since this bug does not meet that criteria, it is now being closed. For more information of the RHEL errata support policy, please visit: http://www.redhat.com/security/updates/errata/ If you feel this bug is indeed mission critical, please contact your support representative. You may be asked to provide detailed information on how this bug is affecting you.