Bug 109516

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.