Red Hat Bugzilla – Bug 125943
(FIREWIRE) Boot process freezes on "probing for new hardware" (kernel 2.6.6-1.427smp)
Last modified: 2015-01-04 17:07:01 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510
Description of problem:
Did a clean install of FC2 and updated the kernel to 2.6.6-1.427smp,
tried to reboot using the newly installed kernel, but the machine
refuses to go beyond "probing for new hardware"
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Boot into FC2 with kernel vers. 2.6.6-1.427smp
Actual Results: Freezes when "probing for new hardware"
Expected Results: normal boot
Not sure what u need, but here are my machine specs:
P4 2.6 Ghz (@3.03), 1024GB Ram, Audigy 2 Soundcard, Abit IS7-G
Motherboard, Radeon 9800pro, Logitech Elite KB (USB), Logitech MX500
(USB), 2 IDE HDDs (Maxtor DM9 250GB, Seagate 120BGB), CD-RW/DVD combo
I have the same problem and a similar configuration:
P4 2.6 Ghz fsb800, 1024GB Ram, Audigy 2 Soundcard, Abit IC7
Motherboard, Abit GeForce FX 5200, Logitech Wheel Mouse (USB),
standard IT keyboard (PS2), IDE HDDs (IBM-HITACHI 120BGB), LG DVD-ROM
, Plextor CD-Writer.
the boot process (graphical) hangs while "probing for new hardware"
and i can reboot with : ctrl+alt+<- (stop x) and ctrl+alt+del.
this happen with both smp and i686 kernel and both 427 and 435 kernel,
everything is fine with the 358 .
Both kernel-2.6.6-1.427 and kernel-2.6.6-1.435 freeze at the "probing
for new hardware" step. This is a new bug: the original FC2
kernel-2.6.5-1.358 runs fine.
do you have firewire or a firewire controller?
i do have a firewire controller
and does the problem go away if you boot with nofirewire ?
i tried to boot with nofirewire , but it still hangs the same way.
can you remove the firewire modules entirely, eg
and see if that prevents the oops ?
>can you remove the firewire modules entirely, eg
>and see if that prevents the oops ?
now i can boot ok.
ok so firewire is still bust.. sigh
That's a different failure from the one I observed with much earlier
kernels, though. It no longer freezes the kernel. It would be nice
to boot without `rhgb' to see if the kernel prints any oops message
when it hangs.
Sorry for not following up on this sooner (busy week :)) - anyway, I
can also boot if I remove the ieee1394 driver folder...
Tried booting without rhgb, but it doesn't seem to throw any extra
information at me (also I am not sure where boot logs are stored if
you want to have a look at the boot info?)
I have the same problem.
Kernel does not freezes.
Steps to get more info:
1. Boot in single mode.
2. Disable run kudzu (chkconfig kudzu off).
3. Reboot and normal boot.
4. login as root on two consoles.
5. On first console run kudzu and wait few seconds.
6. Switch to second console and run "ps axfl":
4 0 3053 3049 15 0 5644 1348 wait4 S pts/7 0:00
4 0 3086 3053 15 0 7116 1968 wait4 S pts/7 0:00
4 0 3208 3086 18 0 3024 436 nodemg D pts/7 0:00
\_ sbin/modprobe -q -r ohci1394
7. Run other commands for get additional info. :)
if you press ctrl-scrolllock you'll get a (long) backtrace of every
process in the system. It'd be interesting to see where the modprobe
process is getting stuck.
(alt-scrolllock also gives you a backtrace of current running process,
but that may be trickier to trap modprobe)
modprobe D 02349920 0 23167 23043 (NOTLB)
0d558e84 00000002 02115749 02349920 035905f0 74cfed81 0000097b 20fa8c30
20fa8dd8 12af39fc 0d558ea0 0d558ec0 0d558ed8 02281b92 00000000
02115e4e 00000000 00000000 12af3a10 00000003 00000212 00000001
[<22f10475>] nodemgr_remove_host+0x3a/0x5d [ieee1394]
[<22f0c6e4>] __unregister_host+0x17/0x7e [ieee1394]
[<22f0cfe5>] highlevel_remove_host+0x46/0x6f [ieee1394]
[<22f0c33c>] hpsb_remove_host+0x26/0x46 [ieee1394]
[<22e987f1>] ohci1394_pci_remove+0x42/0x1c3 [ohci1394]
Created attachment 101688 [details]
Created attachment 101689 [details]
strace /sbin/modprobe -q -r ohci1394
Created attachment 101690 [details]
ltrace /sbin/modprobe -q -r ohci1394
See attachments for some trace.
P.S. More simple way of reproduction:
1. modprobe -s ohci1394
2. modprobe -r ohci1394
just to let you know that I had the exact same problem with the new
kernel 2.6.7-1.494.2.2 and I solved it the exact same way: by removing
the ieee1394 directory in /lib/modules/2.6.7-1.494.2.2/kernel/drivers/
This bug is still present in FC2 kernel-2.6.7-1.494.2.2 -- my system
hangs during hardware check (the original kernel-2.6.5-1.358 runs fine).
My system has two FireWire interfaces: (1) supplied on my Asus
motherboard and (2) part of Creative Labs SB "Audigy" card. I'll
check if removing the ieee1394 directory helps to boot
Removing the ieee1394 modules fixed my boot hang problem, too. The
FireWire portion of the hardware check logic is at fault. FYI, lspci
correctly reports that there are two different FireWire interfaces on
02:00.0 FireWire (IEEE 1394): Lucent Microelectronics FW323 (rev 04)
03:0c.2 FireWire (IEEE 1394): Creative Labs SB Audigy FireWire Port
There is no need to remove the ieee1394 drivers. Roger J. Allen
that the ohci1394 driver has trouble releasing certain kinds of
FireWire devices after kudzu probing. This trouble can be worked
around by adding the line
alias ieee1394-controller ohci1394
to /etc/modprobe.conf file, so that kudzu won't have to try to release
FireWire devices after probing. I've tested this on my system and
this simple fix indeed works.
Having to use this workaround shows that the ohci1394 driver is still
The workaround identified in comment #22 works as well for kernel
2.6.8-1.521 which also has this problem. lspci on my AMD XP 1900,
Soyo K7V Dragon Plus mobo, ATI AIW 8500 Radeon DV video card
(w/Firewire I/F), 4-port Firewire card (I can't remember the vendor or
model) system reports:
00:09.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host
Controller (rev 43)
02:00.0 FireWire (IEEE 1394): Lucent Microelectronics FW323 (rev 04)
Well, I have exact same problem (Fedora Core 3 test 2, kernel 2.6.8),
but I do NOT have any FireWire controller... any idea to help?
Forgot to tell that I also had problems running setup, I've
encountered another famous bug when PC locks up during "running
/sbin/loader/", so I have to run setup with "linux nousb" command.
mass update for old bugs:
Is this still a problem with the 2.6.9 based update kernel ?
i have a similar problem with FC3. kernel 2.6.9-1.667 boots up fine, but newer
versions lock up when it gets to "probing for new hardware". i do not have
firewire. my box is a dell dimension 2400.
if you don't have firewire its unrelated to this bug, please file a new one for it.
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.