Bug 115769 - atkbd.c: unknown key released - XFree86 shouldn't access hardware directly
atkbd.c: unknown key released - XFree86 shouldn't access hardware directly
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: XFree86 (Show other bugs)
rawhide
i386 Linux
low Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
:
: 109516 113265 116144 116373 116629 117919 (view as bug list)
Depends On:
Blocks: FC2Blocker
  Show dependency treegraph
 
Reported: 2004-02-15 17:29 EST by Brian Krahmer
Modified: 2009-08-24 15:35 EDT (History)
20 users (show)

See Also:
Fixed In Version: 4.3.0-60
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-02-26 22:37:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
X server log as per mharris's request (32.39 KB, text/plain)
2004-02-20 12:06 EST, Jack Aboutboul
no flags Details
X config file as per mharris' request (3.13 KB, text/plain)
2004-02-20 12:07 EST, Jack Aboutboul
no flags Details
/var/log/messages as per mharris' reuqest (293.71 KB, text/plain)
2004-02-20 12:10 EST, Jack Aboutboul
no flags Details
XF86Config file (3.12 KB, text/plain)
2004-02-20 12:26 EST, Paul Black
no flags Details
X Server log file (44.48 KB, text/plain)
2004-02-20 12:27 EST, Paul Black
no flags Details
/var/log/messages (60.50 KB, text/plain)
2004-02-20 12:45 EST, Paul Black
no flags Details
XFree86.0.log (29.55 KB, text/plain)
2004-02-20 14:44 EST, Deji
no flags Details
/var/log/messages (trimmed) (114.52 KB, text/plain)
2004-02-20 15:03 EST, Deji
no flags Details
XF86Config (3.06 KB, text/plain)
2004-02-20 15:04 EST, Deji
no flags Details
dhabben-XFree86-4.3.0-59 log (42.55 KB, text/plain)
2004-02-21 10:54 EST, Dave Habben
no flags Details
dhabben-XFree86-4.3.0-59 Config (6.44 KB, text/plain)
2004-02-21 10:55 EST, Dave Habben
no flags Details
dhabben-XFree86-4.3.0-59 messages (51.05 KB, text/plain)
2004-02-21 10:56 EST, Dave Habben
no flags Details
XF86Config file (2.84 KB, text/plain)
2004-02-21 12:38 EST, petrosyan
no flags Details
XFree86 log file (30.71 KB, text/plain)
2004-02-21 12:38 EST, petrosyan
no flags Details
trimmed /var/log/messages file (20.80 KB, text/plain)
2004-02-21 12:39 EST, petrosyan
no flags Details
XFree log (45.82 KB, text/plain)
2004-02-22 08:43 EST, Markku Kolkka
no flags Details
XFree86 config file (3.16 KB, text/plain)
2004-02-22 08:44 EST, Markku Kolkka
no flags Details
/var/log/messages from latest boot to error (20.08 KB, text/plain)
2004-02-22 08:49 EST, Markku Kolkka
no flags Details
XFree86-4.3.0-60 log file (29.75 KB, text/plain)
2004-02-26 16:00 EST, petrosyan
no flags Details
trimmed messages file (20.46 KB, text/plain)
2004-02-26 16:01 EST, petrosyan
no flags Details

  None (edit)
Description Brian Krahmer 2004-02-15 17:29:53 EST
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):
XFree86-4.3.0-55

How reproducible:
every boot

Additional info:
# 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)
Comment 1 Mike A. Harris 2004-02-16 07:21:38 EST
Any reason dkl was removed from QA contact on this?



Date: Mon, 16 Feb 2004 06:44:39 -0500
From: bugzilla@redhat.com
To: mharris@redhat.com
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.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115769


mulix@mulix.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          QAContact|dkl@redhat.com              |


Comment 2 Mike A. Harris 2004-02-17 01:49:18 EST
*** Bug 113265 has been marked as a duplicate of this bug. ***
Comment 3 Thomas Covello 2004-02-17 17:22:41 EST
sorry for the bugspam, adding myself to cc list.
Comment 4 Mike A. Harris 2004-02-19 02:47:54 EST
*** Bug 116144 has been marked as a duplicate of this bug. ***
Comment 6 Mike A. Harris 2004-02-19 02:50:26 EST
Adding bugzilla bug alias "atkbd" to this bug report, for easier
closure of duplicates and whatnot.
Comment 7 Mike A. Harris 2004-02-20 11:43:00 EST
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
directly"

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
following:

- Please make _sure_ you are using 4.3.0-58 or newer, which can
  be obtained currently via ftp or yum from:

    ftp://people.redhat.com/mharris/testing/unstable

- 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.
Comment 8 Mike A. Harris 2004-02-20 12:04:55 EST
*** Bug 116373 has been marked as a duplicate of this bug. ***
Comment 9 Jack Aboutboul 2004-02-20 12:06:01 EST
Created attachment 97861 [details]
X server log as per mharris's request

This is my X server log running -58
Comment 10 Jack Aboutboul 2004-02-20 12:07:18 EST
Created attachment 97862 [details]
X config file as per mharris' request

X config file
Comment 11 Jack Aboutboul 2004-02-20 12:10:39 EST
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?
Comment 12 Paul Black 2004-02-20 12:26:00 EST
Created attachment 97868 [details]
XF86Config file
Comment 13 Paul Black 2004-02-20 12:27:11 EST
Created attachment 97871 [details]
X Server log file
Comment 14 Paul Black 2004-02-20 12:45:18 EST
Created attachment 97874 [details]
/var/log/messages
Comment 15 Deji 2004-02-20 14:44:20 EST
Created attachment 97879 [details]
XFree86.0.log
Comment 16 Deji 2004-02-20 15:03:01 EST
Created attachment 97882 [details]
/var/log/messages (trimmed)

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.
Comment 17 Deji 2004-02-20 15:04:23 EST
Created attachment 97883 [details]
XF86Config
Comment 18 Mike A. Harris 2004-02-20 16:16:09 EST
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
finishes compiling.

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.

Thanks again!
Comment 19 Mike A. Harris 2004-02-21 03:27:49 EST
XFree86-4.3.0-59 is now available for download via 'yum' and ftp
at the following URL:

    ftp://people.redhat.com/mharris/testing/unstable

Please upgrade to this release and follow the instructions in
comment #7 above.

Thanks in advance.
Comment 20 Dave Habben 2004-02-21 10:54:26 EST
Created attachment 97908 [details]
dhabben-XFree86-4.3.0-59 log
Comment 21 Dave Habben 2004-02-21 10:55:24 EST
Created attachment 97909 [details]
dhabben-XFree86-4.3.0-59 Config
Comment 22 Dave Habben 2004-02-21 10:56:40 EST
Created attachment 97910 [details]
dhabben-XFree86-4.3.0-59 messages
Comment 23 petrosyan 2004-02-21 12:38:01 EST
Created attachment 97911 [details]
XF86Config file
Comment 24 petrosyan 2004-02-21 12:38:44 EST
Created attachment 97912 [details]
XFree86 log file
Comment 25 petrosyan 2004-02-21 12:39:14 EST
Created attachment 97913 [details]
trimmed /var/log/messages file
Comment 26 Mike A. Harris 2004-02-22 06:00:00 EST
*** Bug 109516 has been marked as a duplicate of this bug. ***
Comment 27 Markku Kolkka 2004-02-22 08:43:02 EST
Created attachment 97928 [details]
XFree log
Comment 28 Markku Kolkka 2004-02-22 08:44:30 EST
Created attachment 97929 [details]
XFree86 config file
Comment 29 Markku Kolkka 2004-02-22 08:49:47 EST
Created attachment 97930 [details]
/var/log/messages from latest boot to error
Comment 30 Mike A. Harris 2004-02-22 13:33:17 EST
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) 
Comment 31 Mike A. Harris 2004-02-23 17:48:22 EST
*** Bug 116629 has been marked as a duplicate of this bug. ***
Comment 32 andrej 2004-02-23 18:08:23 EST
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! 
 
Comment 33 Mike A. Harris 2004-02-23 19:13:23 EST
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
keyboard controller.

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.
Comment 34 andrej 2004-02-24 02:42:25 EST
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...
many thanks!
Comment 35 Mike A. Harris 2004-02-26 15:13:43 EST
Anyway...

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.
Comment 36 petrosyan 2004-02-26 16:00:30 EST
Created attachment 98087 [details]
XFree86-4.3.0-60 log file
Comment 37 petrosyan 2004-02-26 16:01:05 EST
Created attachment 98088 [details]
trimmed messages file
Comment 38 petrosyan 2004-02-26 16:02:25 EST
the bug seems to be fixed
Comment 39 Mike A. Harris 2004-02-26 22:37:33 EST
Ok, the next build will remove the debugging info.  The ioport
bashing code is permanently disabled to prevent future problems.

Thanks for testing guys.

Comment 40 Aleksey Nogin 2004-03-02 15:37:05 EST
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).
Comment 41 Mike A. Harris 2004-03-02 17:13:41 EST
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.
Comment 42 Aleksey Nogin 2004-03-02 19:19:45 EST
OK, filed bug 117346 on this.
Comment 43 Mike A. Harris 2004-03-09 21:33:08 EST
*** Bug 117919 has been marked as a duplicate of this bug. ***
Comment 44 Roger Seet 2004-03-31 09:57:31 EST
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??
Comment 45 Marius Andreiana 2005-03-29 12:07:09 EST
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? 

Thanks
Comment 46 JanS 2009-08-24 15:17:19 EDT
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).

Thanks

Note You need to log in before you can comment on or make changes to this bug.