Bug 122164 - usb controller not configured, therefore USB mouse no worky
usb controller not configured, therefore USB mouse no worky
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kudzu (Show other bugs)
rawhide
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Bill Nottingham
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-05-01 04:09 EDT by Rick Richardson
Modified: 2014-03-16 22:44 EDT (History)
3 users (show)

See Also:
Fixed In Version: fc3test3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-16 09:01:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rick Richardson 2004-05-01 04:09:57 EDT
I did a fresh install of FC2-test3 on a system with an Intel D845PEBT2
mobo.  This system had previously run both RH8 and RH9 without any
incidents.

The mouse was functional throughout the installation process.

However, upon rebooting, the mouse was dead.  I did an lsmod and
noticed that anaconda (or whatever) did not configure any USB
controller, even though this system has a couple of them:

00:1d.0 USB Controller: Intel Corp. 82801DB (ICH4) USB UHCI #1 (rev
02) (prog-if 00 [UHCI])
        Subsystem: Intel Corp.: Unknown device 4232
        Flags: bus master, medium devsel, latency 0, IRQ 11
        I/O ports at e800 [size=32]

00:1d.1 USB Controller: Intel Corp. 82801DB (ICH4) USB UHCI #2 (rev
02) (prog-if 00 [UHCI])
        Subsystem: Intel Corp.: Unknown device 4232
        Flags: bus master, medium devsel, latency 0, IRQ 3
        I/O ports at e880 [size=32]

00:1d.2 USB Controller: Intel Corp. 82801DB (ICH4) USB UHCI #3 (rev
02) (prog-if 00 [UHCI])
        Subsystem: Intel Corp.: Unknown device 4232
        Flags: bus master, medium devsel, latency 0, IRQ 5
        I/O ports at ec00 [size=32]

00:1d.7 USB Controller: Intel Corp. 82801DB (ICH4) USB2 EHCI
Controller (rev 02) (prog-if 20 [EHCI])
        Subsystem: Intel Corp.: Unknown device 4232
        Flags: bus master, medium devsel, latency 0, IRQ 9
        Memory at febffc00 (32-bit, non-prefetchable)
        Capabilities: <available only to root>


Just for laughs, I did a modprobe uhci and the USB system fired up and
all connected USB devices were recognized, including the all-important
mouse.

In addition to getting this problem fixed in the installer, could you
let me know what I should add to what config file in order to cause
the uhci driver to load on boot?  I could just add "modprobe uhci" to
/etc/rc.d/rc.local, but I'd really like to fix this in the same manner
that a working installation program would have.
Comment 1 Bruno De Wolf 2004-05-03 11:17:10 EDT
For what it's worth: similar problems over here. Note that I switched
from FC1 to FC2T2 and later to FC2R3 via 'yum upgrade', so the problem
is probably not anaconda's but rather the initscripts themselves.

Also note that I am using the ohci controller. My external usb mouse
did not respond until I executed 'modprobe usb-ohci' from the bash prompt.

Kind regards,

Bruno
Comment 2 John S. Monaco 2004-05-03 12:27:18 EDT
    I'd like to see the USB stuff recognized before I need to use it.

    I do a sys-unconfig at the end of %post section in my KickStart
script, and when the newly built system comes back up and prompts for
the new root password, I can't enter it on my USB keyboard.

    I suspect Bruno is correct about this not being anaconda's issue.
I can use the USB keyboard to monitor the KickStart build via
alt-F(1-5). It's only after the booting of a newly built system that I
can't access them... kind of a catch 22 situation, unless I use a PS/2
keyboard for the "firstboot" session, but that shouldn't be necessary.
Comment 3 Rick Richardson 2004-05-03 14:13:53 EDT
I'll be the first to admit that I have no clue how RedHat's installer
and kudzu work together to create the proper configuration files.

I just now read the "kudzu" man page for the first time.  Armed with
this dangerous knowledge, I ran "kudzu -p", and the output definitely
contains information about the UHCI and EHCI controllers on my mobo.

So I'm at a complete loss to understand which of the two programs
failed to complete its job properly, and why this problem has been
moved to kudzu rather than anaconda.

-Rick
Comment 4 Bill Nottingham 2004-05-03 14:51:16 EDT
So, there are no 'usb-controller' entries in /etc/modprobe.conf?
Comment 5 Rick Richardson 2004-05-03 14:56:08 EDT
Yes, that is correct.  There is only a single line there:

$ cat modprobe.conf
alias eth0 e100
Comment 6 John S. Monaco 2004-05-04 15:11:51 EDT
I didn't check yesterday for the usb-controller entries in
/etc/modprobe.conf, but as of today, using the 2.6.5-1.349 kernel, I
have two entries for usb-controller in /etc/modprobe.conf:

alias usb-controller uhci-hcd
alias usb-controller usb-uhci

I'm thinking that this isn't so much a kudzu issue either. kudzu seems
to be working great in my case, but kudzu isn't ran until after the
root password has been changed on a sys-unconfig'ed system.

I can't even use my USB keyboard during the grub screen anymore. Both
of these things worked fine for a good long while, and was only broken
recently. Maybe within the past three weeks?
Comment 7 Bill Nottingham 2004-05-04 15:16:19 EDT
No keyboard in the grub screen usually means a BIOS issue.
Comment 8 Bruno De Wolf 2004-05-04 15:22:22 EDT
>> So, there are no 'usb-controller' entries in /etc/modprobe.conf?

Ha, now we're getting somewhere (in my case anyway):
modprobe.conf contained the following line:
alias usb-controller ehci-hcd

My mouse problems were solved after changing this to
alias usb-controller usb-ohci

Only (less important) question remaining for me: how did this line
came in in the first place - I know it was ohci in FC1. My guess is it
was added by an old buggy version of kudzu, so I don't pay too much
attention to it - or is this supposed to contain 'ehci'?

Kind regards,

Bruno
Comment 9 Bill Nottingham 2004-05-04 15:26:09 EDT
Bruno: No, you *probably* have both. What's the output of lspci?
Comment 10 Bruno De Wolf 2004-05-04 15:44:52 EDT
Bill,

You're right (I should stop guessing on subjects that I don't master).

[root@avon root]# lspci
00:00.0 Host bridge: Intel Corp. 82845 845 (Brookdale) Chipset Host
Bridge (rev 04)
00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP
Bridge (rev 04)
00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 42)
00:1f.0 ISA bridge: Intel Corp. 82801CAM ISA Bridge (LPC) (rev 02)
00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 02)
00:1f.3 SMBus: Intel Corp. 82801CA/CAM SMBus Controller (rev 02)
00:1f.5 Multimedia audio controller: Intel Corp. 82801CA/CAM AC'97
Audio Controller (rev 02)
00:1f.6 Modem: Intel Corp. 82801CA/CAM AC'97 Modem Controller (rev 02)
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon
Mobility M7 LW [Radeon Mobility 7500]
02:05.0 USB Controller: NEC Corporation USB (rev 41)
02:05.1 USB Controller: NEC Corporation USB (rev 41)
02:05.2 USB Controller: NEC Corporation USB 2.0 (rev 02)
02:06.0 FireWire (IEEE 1394): NEC Corporation IEEE 1394 Host
Controller (rev 01)02:07.0 CardBus bridge: Texas Instruments PCI1520
PC card Cardbus Controller (rev 01)
02:07.1 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus
Controller (rev 01)
02:08.0 Ethernet controller: Intel Corp. 82801CAM (ICH3) PRO/100 VE
(LOM) Ethernet Controller (rev 42)

lspci -v for the USB entries:

02:05.0 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI])
        Subsystem: NEC Corporation: Unknown device 8185
        Flags: bus master, medium devsel, latency 64, IRQ 5
        Memory at e8200000 (32-bit, non-prefetchable)
        Capabilities: [40] Power Management version 2
 
02:05.1 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI])
        Subsystem: NEC Corporation: Unknown device 8186
        Flags: bus master, medium devsel, latency 64, IRQ 10
        Memory at e8201000 (32-bit, non-prefetchable)
        Capabilities: [40] Power Management version 2
 
02:05.2 USB Controller: NEC Corporation USB 2.0 (rev 02) (prog-if 20
[EHCI])
        Subsystem: NEC Corporation: Unknown device 8187
        Flags: medium devsel, IRQ 10
        Memory at e8202000 (32-bit, non-prefetchable) [disabled]
        Capabilities: [40] Power Management version 2
 
02:06.0 FireWire (IEEE 1394): NEC Corporation IEEE 1394 Host
Controller (rev 01) (prog-if 10 [OHCI])
        Subsystem: NEC Corporation: Unknown device 80fa
        Flags: medium devsel, IRQ 5
        Memory at e8203000 (32-bit, non-prefetchable) [disabled]
        Capabilities: [60] Power Management version 2
 
So, both ohci and ehci indeed.

How should modprobe.conf look like in this case?

Thanks,

Bruno
Comment 11 Rick Richardson 2004-05-04 15:58:48 EDT
This bug report has taken a turn towards "how can I repair my broken
installation", and its my fault for originally suggesting that I
wanted to know what how to repair it in a manner like a working
installation program would.

I hope that Redhat, et al, are taking this report for what it is: a
serious failure of the installer, kudzu, or whatever to leave the
customer with a working installation on a brand name mobo that was
pretty popular about 14 months ago.

I would be more than happy to try out a fresh install with a new
installer to see if it can get it right.  Note also that I have a
similar bug report on this mobo with the sound system, so if you guys
can kill both bugs with one new installer that would be great.
Comment 12 Bill Nottingham 2004-05-04 16:01:01 EDT
Rick: please try rawhide - you're the only report I've seen so far
that has *nothing* configured right.
Comment 13 John S. Monaco 2004-05-04 17:01:43 EDT
Rick is right. Please, don't lose sight of the problem.

    Bill, thanks for the suggestion, but it's definitely not a BIOS issue.

    I have KickStart server on my desk that I use to evaluate Red Hat
7.3, Red Hat 9, Fedora Core 1, Fedora Core 2, and White Box EL. I have
two motherboards that I test with, the SuperMicro P4DP6, and the
SuperMicro X5DP8-G2. All of these Linux flavors allow me to enter a
new root password after a sys-unconfig. All of these, except Red Hat
7.3, have allowed me to use my USB keyboard in the grub screen. As I
had said before, Fedora Core 2 has only had a problem in the past few
weeks. 

    I have Red Hat 7.3 installed on nearly 1,000 servers, and we are
currently considering which direction to go after this. I have
recommended that the 2.6 kernel would be the best direction to go;
because it offers a lot of solutions for problems we are experiencing
with the 2.4 kernel. I'm hoping that my input here helps Fedora Core 2
be a little more robust when when y'all release it as ready for public
consumption, which I am hoping will make RHEL 4.0 something we will
want to use on our servers.

Bruno,

    I like seeing this:

>02:07.0 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus
Controller (rev 01)
>02:07.1 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus
Controller (rev 01)

    Stuff like that keeps me employed.

Comment 14 Rick Richardson 2004-05-04 17:15:01 EDT
Sorry to be a pain, but I'm going to need a little more info than try
rawhide.  I need at least a URL to it.  Then, will I find a boot disk
CD-ROM .iso there with a newer installer on it than is on the FC2T3 DVD?
Comment 15 Bill Nottingham 2004-05-04 18:11:58 EDT
John: if it's not a BIOS issue, it's grub itself. Obviously, if you're
just in the grub screen, there's not really a chance for anything else
to screw up the USB keyboard. The only other possibility is that the
kernel is doing something odd on warm vs. cold boot and it depends on
what you booted prior to rebooting, but that's a real long shot.

Rick: rawhide is the development snapshot; it contains boot isos that
you can use to then install the tree via NFS/HTTP/FTP. It's
at http://download.fedora.redhat.com/pub/fedora/linux/core/development/
Note that it may take some bandwidth to pull down the whole tree; you
can't just use the new installer against the FC2t3 ISOs.
Comment 16 John S. Monaco 2004-05-05 17:37:22 EDT
Bill,

    I discovered a few things today.

    First of all, I hadn't realized the rc.sysinit was changed when
the new initscripts package was introduced recently; so it took me a
bit to narrow down the sys-unconfig problem I was experiencing. We had
a slightly customized version of rc.sysinit that was over-writing the
new and improved version in the %post section of our KickStart script.
As I had said before, this used to work great up until about three
weeks ago, and no wonder:

#ls -al initscripts*
-rw-r--r--    1 jmonaco  ttcdev     880224 Apr 20 08:30
initscripts-7.50-1.i386.rpm
-rw-r--r--    1 jmonaco  ttcdev     898431 May  4 15:40
initscripts-7.51-1.i386.rpm

My hats off to the guys doing the new initscripts. They are solid!

    Secondly, the grub & USB keyboard problem seems to only be
apparent on certain motherboard chipsets. The Intel 845GE chipset
doesn't seem to have the problem, but the Intel 7500 and 7501 chipsets
do. This problem also popped up about three weeks ago. Today, I
noticed that the time/date stamp on the grub package:

-rw-r--r--    1 jmonaco  ttcdev     371205 Apr 19 15:23
grub-0.94-4.i386.rpm

    Before this update, I was able to use a USB keyboard on Fedora
Core 2. I am not sure what the prior grub version was. The USB
keyboards that we use, Sun Type 6 USB, have worked in the grub screen
since we started evaluating Red Hat 9, which shipped with
grub-0.93-4.i386.rpm, and it does not work with Red Hat 7.3's default
grub-0.91-4.i386.rpm.

    After narrowing these problems down, I'd say that "sys-unconfig &
USB keyboard" problem is not really an issue, but the "grub & USB
keyboard" problem is an issue, but not related to Rick's original
problem. 
Comment 17 Rick Richardson 2004-10-16 09:01:18 EDT
This is fixed in fc3test3.  Thank you.

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