Red Hat Bugzilla – Bug 127848
USB hang in early boot on new install w/ devices attached
Last modified: 2015-01-04 17:07:52 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Description of problem:
I've installed FC2 on an eMachines M2350 laptop. When I boot the
machine with any of my USB devices (a Logitech mouse, a SanDisk Cruzer
memory key, and a USB/IDE adapter) attached, the boot will hang very
early in the init process. The message about loading the EHCI module
was displayed, and the system would hang (I waited about 15 minutes,
with no further signs of life).
Booting the machine without any USB devices attached works fine, and I
can then attach the devices later and they'll work without any
This also occurred with kernel-2.6.6-1.435.2.3
I have also tried FC3test1 on this same machine -- the USB modules
load fine when I have no devices attached. With any device attached,
there's a notable pause immediately after loading the EHCI and OHCI
modules, but before RHGB gets started. This pause is not seen when
booting without attached devices. The system hangs, however, upon
running kudzu (Checking for new hardware) (waited 10 minutes for
something to happen).
Again, with FC3test1, I can boot w/o devices attached, and attach the
later without any apparent trouble.
FC3test1 is version kernel-2.6.7-1.478
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. install FC2
2. attach USB device
3. boot the system
Actual Results: hung system
Expected Results: booted system
Created attachment 101910 [details]
output from lspci -vv
Created attachment 101911 [details]
FC2 lsusb -vv output
Created attachment 101912 [details]
FC3test1 output from lsusb -vv
I just installed the 2.6.7-1.494.2 kernel. Booting this kernel makes
it past the USB driver loading, albeit with a message about IRQ #11
being disabled. But the system hangs when I get to kudzu. I've
disabled kudzu, and now my external USB mouse is not working. When I
run lsusb, that process hangs.
After I boot the system to the gdm login, I can attach the external
USB mouse and things work. But I still cannot boot the machine with
the mouse attached during the boot sequence. The system hang has
moved from the USB driver loading to the kudzu step.
How much RAM does your laptop have? If it has tons of RAM, does
booting with something like "mem=1024m" or "mem=2048m" make the freeze
512M of RAM.
I have the same problem with eMachines M5312 laptop, FC2. System
~ % cat /proc/version
Linux version 2.6.8-1.521 (firstname.lastname@example.org) (gcc
version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)) #1 Mon Aug 16 09:01:
18 EDT 2004
~ % uname -a
Linux dfavro-3 2.6.8-1.521 #1 Mon Aug 16 09:01:18 EDT 2004 i686
athlon i386 GNU/Linux
I have the same problem.
emachines M5310 laptop FC3 upgraded from fc2.
Logitech USB M-BD58
Linux version 2.6.10 (root@fc2leon) (gcc version 3.4.2 20041017 (Red
Hat 3.4.2-6.fc3)) #1 Wed Dec 29 17:40:30 CST 2004
Linux fc2leon 2.6.10 #1 Wed Dec 29 17:40:30 CST 2004 i686 athlon i386
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.
This is still a problem with FC3, using kernel 2.6.11-1.14_FC3 (and most, if not
all, previous FC3 kernels).
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem. Please update to this new kernel, and
report whether or not it fixes your problem.
If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.
This bug has been automatically closed as part of a mass update.
It had been in NEEDINFO state since July 2005.
If this bug still exists in current errata kernels, please reopen this bug.
There are a large number of inactive bugs in the database, and this is the only
way to purge them.