From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 Description of problem: Hardware: Compaq Aramad M700 laptop When X11 starts, the keyboard lights flash for anywhere from 3-25 seconds, with a system freeze, until eventually X11 starts up. Many times after finally starting either the keyboard or mouse are not functional. Nov 8 13:40:07 localhost kernel: Keyboard timed out[1] Messages like above are logged after such an incident. This has been tested on two seperate machines. The same problem existed in Redhat 9. The problem can also be reproduced by switching to the console, and then back to X11 (no restart of X11 required). Version-Release number of selected component (if applicable): XFree86-4.3.0-2 How reproducible: Always Steps to Reproduce: 1. Start X11 Additional info:
The keyboard lights flashing are a kernel debugging morse code thing. That, and your above log file snippet, show this to be kernel related. Also, you have filed this against Fedora Core 1, and indicate: "XFree86-4.3.0-2". That is the release that came with RHL 9, not 4.3.0. Just pointing that out in case it was a typo or something. Reassigning to kernel.
If this is a kernel panic, there will be a backtrace and the likes in the logs / dmesg output. We'll need that to get anywhere with this bug.
that said, the blinking LEDs is done by panic(), which doesn't return. Ever. The bug report above mentions that it continues after a while, which sounds like it isn't a kernel panic at all.
Correct, there is no kernel panic. Further testing shows that this occurs even when launching the graphical installer of FC1 from the boot CD.
I have the same error. Fedora Core 1, Medion MD6100 laptop.
Same thing here on an Compaq Armada M700. It appears to be an XFree86 bug. With the 2.6.2-rc2 kernel, the problem goes away but I get the following in the log instead: Jan 27 15:12:59 localhost kernel: atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0). Jan 27 15:12:59 localhost kernel: atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly. Jan 27 15:12:59 localhost kernel: atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0). Jan 27 15:12:59 localhost kernel: atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly.
Kernel people are claiming the above error indicates an XFree86 bug. A more reasonable and accurate description, is that XFree86 directly accesses hardware for it's own purposes, and that might possibly conflict with the kernel. The direct hardware access being intentional, and not an unintentional "bug". While I agree that the XFree86 issue should be fixed in the future so that this error message isn't triggered, it isn't clear wether or not this specific problem is causing the kernel to hang or not. XFree86 doesn't make the keyboard LEDs flash for example. I'll need a kernel person to decide wether or not this keyboard issue is causing the problem reported in this bug or not, or if there are 2 separate issues here.
I've discussed this further with Alan, and here is more background on the problem. Aparently, the kernel didn't have an interface to permit userland applications to set the keyboard rate before, and so XFree86 had no other way than doing direct I/O to the keyboard controller. 2.4.x kernels if I understand correctly, at some point added a new ioctl to allow keyboard rate setting, and XFree86 was enhanced to support this new interface. The current code tries to use the kernel ioctl to set the rate, and if that fails, it falls back to trying another ioctl which is aparently on sparc, possibly other arches, and then finally it falls back to doing direct I/O on i386, ia64, and alpha. After analyzing the code, I believe the ioport code should never ever be called if the person is using a Red Hat supplied kernel which properly supplies the KDKBDRATE ioctl(). If my assumption is correct, then their kernel is missing this ioctl, or the ioctl is failing for some reason or another. I have added debugging messages to the X keyboard driver to try to help pinpoint what is going on here. One further possiblity, is if the kernel headers installed on the machine that X is compiled on, do not have the KDKBDRATE ioctl, then this codepath wont be compiled in, and ioport based rate setting will be used always. I have added a #error to the source in order to fail the build in this case. I'm going to reassign this back to myself for now as I'll be collecting further data to try and determine what the real cause here is, and wether or not XFree86, the kernel, or both need changes to deal with this properly.
*** This bug has been marked as a duplicate of 115769 ***
Created attachment 97927 [details] Xfree log followed by /var/log/messages I get an error message when starting XFree86 on my Dell lattitude c840 reporting that I may be encountering this bug and please attach log output
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.