Red Hat Bugzilla – Bug 120832
Keyboard unusable without CONFIG_USB_UHCI_HCD=y
Last modified: 2015-01-04 17:05:17 EST
Description of problem:
My laptop (eMachines M6807) is buggy in many ways, but it seems the
showstopper currently is that I am unable to use the keyboard until
usb-uhci is loaded. I have built a custom kernel using the suggestions
found at http://www.muru.com/linux/amd64/ including patches for acpi
and apic to make other things like pcmcia and ip-apic work right, as
well as changing the configuration option:
which will allow my keyboard to be used. I was thinking that since we
have given up on trying to fit on a boot floppy that there would be
less resistance to building the kernel with low-level usb drivers
included so that things like keyboards and mice work as they should
even in runlevel 1, or emergency mode.
As far as the patches go, they apply cleanly to kernel-2.6.5 from
kernel.org and may not be acceptable as written, but I hope you can
make a patch for our trees that can fix the same problems these do for
*** Bug 120833 has been marked as a duplicate of this bug. ***
This was mentioned on the internal kernel list and I suggested
putting modules into initrd. But this may be too hard for FC2.
Arjan/DaveJ have to bunch together and decide what to do.
Don't forget about systems with OHCI. If UHCI goes in, so should OHCI.
EHCI always has OHCI compatibility mode, so perhaps it can be left out.
Um, This machine is an x86_64, not a Mac (ppc).
Do the Mac's also need this compiled in, or did we get the wrong
blocker bug number?
Given how few modern machines lack OHCI/UHCI maybe it should be
compiled in on all of them ?
Yes, the blocker bug number is wrong. This is an x86_64 machine.
I tried putting these modules into the initrd manually, the kernel
still complains very loudly before the initrd is loaded, but it does
eventually work. It's much neater logging wise to have them already
compiled in however.
The blocker bug is wrong, Macs use OHCI USB controllers.
http://www.rmecc.com/~v2/em/ is a wonderful resource -- it solves this
problem nicely. The bottom line is that the BIOS is quite borked as
shipped by eMachines. Updating the BIOS permits FC3T1 (current as I
write this) to install on the eMachines M6805 without any kernel
command line options. The install is in progress as I type, so I'll
update this with any other info once it's done & I get a chance to see
what hath been wrought.
I know about that site, see mine (which points to that one):
I should add that the bios upgrade from that page is UNOFFICIAL, and
not supported by eMachines. If you choose to do that upgrade you are
almost certainly voiding any warranties you may otherwise have
any better with teh current updates ?
Fedora Core 2 has now reached end of life, and no further updates will be
provided by Red Hat. The Fedora legacy project will be producing further kernel
updates for security problems only.
If this bug has not been fixed in the latest Fedora Core 2 update kernel, please
try to reproduce it under Fedora Core 3, and reopen if necessary, changing the
product version accordingly.