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)
Any reason dkl was removed from QA contact on this? Date: Mon, 16 Feb 2004 06:44:39 -0500 From: bugzilla To: mharris 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 changed: What |Removed |Added ---------------------------------------------------------------------------- QAContact|dkl |
*** 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 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.
*** 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] XF86Config file
Created attachment 97871 [details] X Server log file
Created attachment 97874 [details] /var/log/messages
Created attachment 97879 [details] XFree86.0.log
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.
Created attachment 97883 [details] XF86Config
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!
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.
Created attachment 97908 [details] dhabben-XFree86-4.3.0-59 log
Created attachment 97909 [details] dhabben-XFree86-4.3.0-59 Config
Created attachment 97910 [details] dhabben-XFree86-4.3.0-59 messages
Created attachment 97911 [details] XF86Config file
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] XFree log
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 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.
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!
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.
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? Thanks
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