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
Steps to Reproduce:
1. Install RHEL4 U2 or above on a machine with DRAC3 card plugged in
2. Enable console redirection
Pressing a key will result in multiple characters of that key being displayed on
One keypress should result in one character on the console
The attached patch to atkbd.c fixes the issue and has been tested by Dell.
Please include this in the next update of RHEL4.
Created attachment 124611 [details]
nosoftrepeat patch to atkbd.c
Increasing severity as this is critical for Dell. We expect this patch to be in U4.
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?
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
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,
This has not been sent upstream (yet).
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.
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.
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.
Created attachment 125071 [details]
Candidate #2 - Vojtech's alternative
From: Vojtech Pavlik <firstname.lastname@example.org>
Cc: Pete Zaitcev <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.
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?
I did look at it when he sent it--I think it's perfect! Thanks.
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.
committed in stream U4 build 34.17. A test kernel with this patch is available
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.