Red Hat Bugzilla – Bug 115769
atkbd.c: unknown key released - XFree86 shouldn't access hardware directly
Last modified: 2009-08-24 15:35:42 EDT
Description of problem:
From /var/log/messages during boot:
Feb 15 14:18:27 selkirk kernel: atkbd.c: Unknown key released
(translated set 2, code 0x7a on isa0060/serio0).
Feb 15 14:18:27 selkirk kernel: atkbd.c: This is an XFree86 bug. It
shouldn't access hardware directly.
Version-Release number of selected component (if applicable):
# uname -a
Linux selkirk.krahmer.com 2.6.1-1.65 #1 Fri Jan 30 17:28:54 EST 2004
i686 athlon i386 GNU/Linux
Fedora Core release 1.90 (FC2 Test 1)
Any reason dkl was removed from QA contact on this?
Date: Mon, 16 Feb 2004 06:44:39 -0500
Content-Type: text/plain; charset=utf-8
Subject: [Bug 115769] atkbd.c: unknown key released - XFree86
shouldn't access hardware directly
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
What |Removed |Added
*** Bug 113265 has been marked as a duplicate of this bug. ***
sorry for the bugspam, adding myself to cc list.
*** Bug 116144 has been marked as a duplicate of this bug. ***
Adding bugzilla bug alias "atkbd" to this bug report, for easier
closure of duplicates and whatnot.
This request is for everyone using Fedora Core test1 release, or
otherwise using a 2.6.x kernel on a Fedora Core system, who are
experiencing periodic lockups perhaps and/or are seeing the following
error, reported in /var/log/messages
"atkbd.c: unknown key released - XFree86 shouldn't access hardware
I am trying to debug the issue, and so I would like for those
experiencing this problem, to upgrade to XFree86 4.3.0-58 or
later as soon as possible if you haven't already, and then do the
- Please make _sure_ you are using 4.3.0-58 or newer, which can
be obtained currently via ftp or yum from:
- add yourself to the CC on this bug (if not already)
- trigger the error, use xset to set the keyboard rate if necessary
- attach your X server log, X config file, and /var/log/messages to
the bug report as individual uncompressed file attachments
using the bugzilla file attachment feature.
This information will be helpful to fix the problem.
Thanks in advance.
*** Bug 116373 has been marked as a duplicate of this bug. ***
Created attachment 97861 [details]
X server log as per mharris's request
This is my X server log running -58
Created attachment 97862 [details]
X config file as per mharris' request
X config file
Created attachment 97863 [details]
/var/log/messages as per mharris' reuqest
This one is a big one. Just scroll down to 2/20/04 I guess?
Created attachment 97868 [details]
Created attachment 97871 [details]
X Server log file
Created attachment 97874 [details]
Created attachment 97879 [details]
Created attachment 97882 [details]
OT: Never mind the bunch of avc:denied ~ in my log, I don't know what to do
with this selinux of a thing :). I've been getting that since morning when I
was forced to reinstall the devel-tree to continue FC2 test.
Created attachment 97883 [details]
Ok, everyone's log files, etc. have shown that the problem is not
present where we believed it to be at first. I have made a new
patch which patches another place in the code that could be triggering
this problem, and this will be in XFree86 4.3.0-59 as soon as it
Thanks to everyone who has responded so far.
For now, please hold off adding more log files, etc. until I
announce 4.3.0-59 and get everyone to try it. The new build
should give us the information I need I believe. I'll make
a new posting to the fedora-test-list also when 4.3.0-59
is ready for testing.
XFree86-4.3.0-59 is now available for download via 'yum' and ftp
at the following URL:
Please upgrade to this release and follow the instructions in
comment #7 above.
Thanks in advance.
Created attachment 97908 [details]
Created attachment 97909 [details]
Created attachment 97910 [details]
Created attachment 97911 [details]
Created attachment 97912 [details]
XFree86 log file
Created attachment 97913 [details]
trimmed /var/log/messages file
*** Bug 109516 has been marked as a duplicate of this bug. ***
Created attachment 97928 [details]
Created attachment 97929 [details]
XFree86 config file
Created attachment 97930 [details]
/var/log/messages from latest boot to error
Ok, here's an update on the issue... I believe I've fixed this
bug now. With my new patch applied, I can trace the keyboard driver
and see it calling the KDKBDREP ioctl() which succeeds, and things
appear to work properly. The debug messages for failure cases
no longer print for me.
So my current patch does 3 things:
1) Fix the ioctl failure (needs more testing to be conclusive)
2) Remove the ioport fallback code. If the ioctl fails now, the
keyboard rate is unsettable. This is superior to having your
machine lock up and possibly lose data.
3) Leaves a bit of debugging code around just in case there are
any more problems.
This will be in 4.3.0-60, which should be available within
24 hours. I will update this report within that time.
Once this is confirmed to fix the problem for everyone, I'd like
to revamp the patch to do it the "right" way cleanly, in which
case I will need to know which official Linus Linux kernel versions
have the KDKBDREP ioctl in the 2.4.x series that are known to
be stable and reliable. If anyone cares to dig that information
up it'd be appreciated. Time for some sleep for me now. ;o)
*** Bug 116629 has been marked as a duplicate of this bug. ***
bug116629: I have to precise I saw the messages 'Xfree86 shouldn't
access the hardware directly' with kernel 2.6.1 as well...but
Xfree86 worked nevertheless
...while after the kernel upgrade it just did not any more!
andrej) I'm not quite sure what you're trying to say in comment #32,
as your statements seem conflicting. Could you clarify?
In the mean time, let me clarify the real problem here. XFree86
has programmed the keyboard repeat rate up until now by directly
programming the keyboard controller. That is /bad/ because it
can result in hardware contention if the kernel is programming
the hardware at the same time. It is the job of the kernel to
arbitrate access to shared hardware resources.
In the past, and in particular with 2.4.x kernels, it "just
worked", which was more luck than anything technically correct.
There has _always_ been a race here. It has only recently
become an actual problem and cause of kernel lockups.
I have traced the problem down to the XFree86 code incorrectly
calling the kernel ioctl to set the keyboard rate, which is
the /safe/ way to do this. The code will fall back to doing
it with port I/O if the ioctl fails for any reason - and it does
fail - always, because it is programmed incorrectly.
As such, wether or not the kernel displays the "atkbd.c ..."
error message reported here does not matter. The problem is not
the kernel logging an error message, but rather the problem is
the kernel locking up due to what XFree86 is doing with the
This problem is fixed internally, and the fix is not yet released
for people to test it. If you upgrade your kernel and find the
problem no longer occurs, that is interesting, but that does not
indicate there is a problem in the kernel. It is definitely an
XFree86 bug, and one that I have now fixed.
Once I release the new XFree86, everyone can test it and indicate
if their problems go away or not.
Hope this helps.
OK sorry for the confusion, I'll try to be more clear:
-on a new installation of FC2-test1 (I think kernel 2.6.1-1.65) I do
receive messages, that the has been a Xfree86 bug detected - direct
acces to resources; and Xfree86 works seemingly with no problems
-upgrading the kernel to 2.6.3-"and something" (It's not important
really, since I get that problem with all subsequent kernels) and
rebooting => xfree86 just doesn't want to start
here I'd like to point out, that in fact while booting with this new
kernel, I can see kudzu's notification of detected hardware change
(well - there is no change really)
kudzu thinks I have added a new AT 2 -"some-type-of-keyboard" + a new
mouse (previously the setting "generic 3button ps/2 mouse" worked
well; now I get something like "generic 3 button Ps/2 with wheel").
And now, with this new kernel installed & the PC rebooted, I just
can't start xfree86
I guess I should perhaps have explicitly mentioned it before (I
thought it was cited in the logs) but as a reason for this failure
Xfree86 mentions a probable problem with the mouse.)
Now, if I boot with the previous 2.6.1-1.65 kernel, build a custom
kernel out of the source of the new 2.6.3-xxx kernel and boot it -
xfree86 gets now up&running with no apparent problems.
So, if you think it could be useful, pls revert and I can send you the
.config file I used to build the custom kernel and (whatever the
reason) helped me solve the problem I had ... otherwise I guess we can
consider the issue closed here ... and let's wait for the new patch to
be released & tested...
The XFree86 bug which causes 2.6.x kernels to trigger an error
message as reported above, has been fixed, and is available in
XFree86 4.3.0-60 which should now be in rawhide. I would like
all users who were experiencing this specific problem, to please
upgrade to the new XFree86 release, and also upgrade to the new
rawhide kernel, which fixes other problems that caused XFree86
to not be able to start up.
After testing the new XFree86 release, once X has started up,
please examine your X server log file in /var/log. It should
still contain some debugging messages that I've left in place.
Please attach your new X server log, and a copy of /var/log/messages
from your last boot onward as uncompressed individual file
attachments, and please indicate if the atkbd.c related problem is
no longer hanging your machine.
I've got 99% certainity that this particular issue is now solved,
and once I get users confirming this problem is fixed for them now,
I will update the patch to remove the debugging bits.
Thanks in advance.
Created attachment 98087 [details]
XFree86-4.3.0-60 log file
Created attachment 98088 [details]
trimmed messages file
the bug seems to be fixed
Ok, the next build will remove the debugging info. The ioport
bashing code is permanently disabled to prevent future problems.
Thanks for testing guys.
I am seeing
(EE) lnx_kbd.c: Unable to set the keyboard repeat rate using the
KDKBDREP ioctl(). This may be caused by a buggy kernel.
in my X logs. Is this caused by a fix to this bug?
I am currently running XFree86-4.3.0-62 and kernel-2.6.3-1.116
(recompiled with CONFIG_SOFTWARE_SUSPEND enabled).
Yes, that error message was added in the patch that fixes this
bug. If the KDKBDREP ioctl is not present in your kernel, or
fails, you will see this error message. The ioport bashing code
has been removed, so if the kernel does not support keyboard
repeat rate setting via ioctl, then you will not be able to
modify your repeat rate under X at all anymore.
OK, filed bug 117346 on this.
*** Bug 117919 has been marked as a duplicate of this bug. ***
I am using Armada E500 and have this problem. I did not try 4.3.0-60
but found the following interesting thing about the bug : if somehow
the mouse driver failed to load (e.g. wrong XF86Config entries), this
problem does not occur. (ie the keyboard can be used without any
access error at all) Of course, I cannot use the mouse in this case.
Just being curious, can you explain this behaviour??
I'm getting these on a FC3 system in production:
Mar 29 18:29:01 os kernel: atkbd.c: Unknown key released (translated set 2, code
0x75 on isa0060/serio0).
Mar 29 18:29:01 os kernel: atkbd.c: Use 'setkeycodes 75 <keycode>' to make it known.
Mar 29 18:29:02 os kernel: input: AT Translated Set 2 keyboard on isa0060/serio0
System is started in runlevel 3, without X being ever started.
Is the bug back?
Could someone change alias of this bug to some other than "atkbd"?
It makes impossible to search for bugs with a word "atkbd", cause such search is instantly redirected to This bug (closed years ago, by the way).