|Summary:||Console redirection on DRAC 3 results in repeated key strokes (P1)|
|Product:||Red Hat Enterprise Linux 4||Reporter:||Charles Rose <charles_rose>|
|Component:||kernel||Assignee:||Pete Zaitcev <zaitcev>|
|Status:||CLOSED ERRATA||QA Contact:||Brian Brock <bbrock>|
|Version:||4.0||CC:||jbaron, stuart_hayes, tao, wwlinuxengineering|
|Fixed In Version:||RHSA-2006-0575||Doc Type:||Enhancement|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-08-10 22:16:52 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
|Bug Blocks:||181409, 185127, 185624|
Description Charles Rose 2006-02-14 12:10:03 UTC
Description of problem: On Dell PowerEdge systems with a DRAC3 card plugged in, using console redirection feature of the DRAC3 card results in repeated keystrokes. Version-Release number of selected component (if applicable): 2.6.9-22.0.2.EL and 2.6.9-31.EL How reproducible: Always Steps to Reproduce: 1. Install RHEL4 U2 or above on a machine with DRAC3 card plugged in 2. Enable console redirection Actual results: Pressing a key will result in multiple characters of that key being displayed on the console Expected results: One keypress should result in one character on the console Additional info: The attached patch to atkbd.c fixes the issue and has been tested by Dell. Please include this in the next update of RHEL4.
Comment 1 Charles Rose 2006-02-14 12:10:03 UTC
Created attachment 124611 [details] nosoftrepeat patch to atkbd.c
Comment 2 Charles Rose 2006-02-17 09:36:16 UTC
Increasing severity as this is critical for Dell. We expect this patch to be in U4.
Comment 3 Pete Zaitcev 2006-02-17 19:24:57 UTC
Firstly, this seems too much of an ad-hoc approach. It would be much better (long term) not to add knobs, but to take off some signature of DRAC3. Please attach a dmesg for starters (I may request necessary files from the /sys/devices/platform/* later). Also, what is the upstream status of this? Did Dell try to contact Dmitry and/or Vojtech on this topic? Do you want us to liason with them?
Comment 5 Stuart Hayes 2006-02-17 21:46:46 UTC
Let me explain the problem in more detail. Dell's DRAC3 stuffs keystrokes into the 8042 keyboard controller, so that, to the system, it looks like keystrokes are coming in from the main PS/2 keyboard. It was done that way because USB keyboard support wasn't ubiquitous when the DRAC3 was designed. However, the DRAC3 card does NOT fully emulate a keyboard. This causs a problem on systems that have no real keyboard plugged in, since atkbd probes for the keyboard, and won't take control of the port if it doesn't see one. To get around this issue, we tell users to use the "i8042.dumbkbd=1" kernel command line option. This causes the port not to have a "serio->write" function, so atkbd skips the keyboard probe and just takes control of the port. That was fine in RHEL3. However, at some point in the 2.6 kernel, the atkbd driver was changed, so that it now turns on "atkbd_softrepeat" if there's no "write" function (i.e., if the "i8042.dumbkbd=1" option was used). Presumably, this was done on the assumption that any "dumb" keyboard wouldn't auto repeat by itself--but this isn't the case here. With softrepeat on, the atkbd driver will auto-repeat a key that has been held down for (a hired-coded value of) 250ms. Our DRAC3 firmware and/or remote console Java client causes keystrokes from the DRAC3 to appear to be held down for 500ms. So, you can't just type one of anything... every time you hit a key, you get lots of them. We have provided a DKMS driver for customers to use for now, but we (and our customers) are very eager to get this patch into RHEL4 U4 so that the extra driver is not necessary. This patch adds an option that would only be required for people running older Dell hardware (with DRAC3 hardware), RHEL4, and no physical keyboard. We thought this would be the best way to work around this issue, since it adds very little code and very little risk, so we could get it in quickly. If you still want to see dmesg, any sysfs files, or you have any other questions, please ask. I don't think there's much to see in dmesg. If you have a better idea for a workaround or fix, please feel free to suggest that, as well. This has not been sent upstream (yet). Thanks!
Comment 6 Pete Zaitcev 2006-02-17 22:05:02 UTC
This makes complete sense, thank you, Stuart. Let me pass it by upstream (Dmitry), and then I post it for the inside review. The main concern here is, it's a pain to add new variables, get them documented in 65 languages, then remove them again if upstream changes. Better do it once.
Comment 8 Stuart Hayes 2006-02-22 18:02:18 UTC
Regarding the comments from Dmitry & Vojtech--"kbdrate -d 1000" isn't a good workaround, because sometimes the DRAC3 will take longer than 1s to deliver keyboard events. It worked for me in the lab, but our product support folks tried this earlier and found that it was not a robust workaround. (This doesn't make DRAC3 as unusable as it sounds--it will deliver multiple keyboard events when it does get around to delivering them.) And I don't think that the /sys/bus/serio/devices/serioX/softrepeat interface is present in RHEL4. Although--if that is in the latest kernel.org kernel, we wouldn't have to push this patch upstream, though we still need some sort of fix in RHEL4.
Comment 9 Pete Zaitcev 2006-02-22 19:34:37 UTC
Stuart, it would be better if you sent these comments to the thread instead of posting to Bugzilla. I haven't posted anything because the public discussion is not over, so there's no summary yet.
Comment 10 Pete Zaitcev 2006-02-22 22:59:40 UTC
Created attachment 125071 [details] Candidate #2 - Vojtech's alternative
Comment 11 Pete Zaitcev 2006-02-22 23:01:20 UTC
From: Vojtech Pavlik <firstname.lastname@example.org> To: email@example.com Cc: Pete Zaitcev <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org Subject: Re: Suppressing softrepeat Date: Wed, 22 Feb 2006 23:09:54 +0100 > I am not keen on changing the default behaviour... How many dumb > keyboards are out there? Apart from the DRAC3, some home-made Sun-to-PS2 converter, and a single non-x86 embedded box, I don't recall anything. Answer: very few. There may be users, though, that use this option to force the detection of the keyboard when not really plugged in, eg. for flaky KVMs. I've Googled for that usage, but found none.
Comment 12 Larry Troan 2006-03-16 12:37:56 UTC
Stuart, have you reviewed Vojtech's altrnative (attached to this bug)? Comments? Have you commented back on the thread? Pete, any resolution yet? Can we get something implemented for U4?
Comment 13 Stuart Hayes 2006-03-16 14:58:16 UTC
I did look at it when he sent it--I think it's perfect! Thanks.
Comment 17 Bob Johnson 2006-04-11 16:26:55 UTC
This issue is on Red Hat Engineering's list of planned work items for the upcoming Red Hat Enterprise Linux 4.4 release. Engineering resources have been assigned and barring unforeseen circumstances, Red Hat intends to include this item in the 4.4 release.
Comment 18 Jason Baron 2006-04-12 13:00:10 UTC
committed in stream U4 build 34.17. A test kernel with this patch is available from http://people.redhat.com/~jbaron/rhel4/
Comment 22 Red Hat Bugzilla 2006-08-10 22:16:59 UTC
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2006-0575.html