Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040518 Firefox/0.8 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 apparent problems. 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): kernel-2.6.5-1.358 How reproducible: Always Steps to Reproduce: 1. install FC2 2. attach USB device 3. boot the system Actual Results: hung system Expected Results: booted system Additional info:
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 go away?
512M of RAM.
I have the same problem with eMachines M5312 laptop, FC2. System info: ~ % cat /proc/version Linux version 2.6.8-1.521 (bhcompile@tweety.build.redhat.com) (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. AMD Athlon-XP-M 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 uname -a Linux fc2leon 2.6.10 #1 Wed Dec 29 17:40:30 CST 2004 i686 athlon i386 GNU/Linux
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. Thank you.
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'. Thank you.
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. Thank you.