Bug 125943 - (FIREWIRE) Boot process freezes on "probing for new hardware" (kernel 2.6.6-1.427smp)
Summary: (FIREWIRE) Boot process freezes on "probing for new hardware" (kernel 2.6.6-1...
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
(Show other bugs)
Version: 2
Hardware: i686 Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact:
Depends On:
Blocks: 126004
TreeView+ depends on / blocked
Reported: 2004-06-14 13:56 UTC by Morten Nielsen
Modified: 2015-01-04 22:07 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-16 05:42:00 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
syslog (1010 bytes, text/plain)
2004-07-07 20:19 UTC, Serg Oskin
no flags Details
strace /sbin/modprobe -q -r ohci1394 (3.20 KB, text/plain)
2004-07-07 20:20 UTC, Serg Oskin
no flags Details
ltrace /sbin/modprobe -q -r ohci1394 (1.31 KB, text/plain)
2004-07-07 20:21 UTC, Serg Oskin
no flags Details

Description Morten Nielsen 2004-06-14 13:56:22 UTC
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):

How reproducible:

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

Additional info:

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

Comment 1 filippo david 2004-06-14 19:06:15 UTC
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 .

Comment 2 josip 2004-06-16 07:17:59 UTC
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.

Comment 3 Arjan van de Ven 2004-06-16 13:12:02 UTC
do you have firewire or a firewire controller?

Comment 4 filippo david 2004-06-16 20:45:13 UTC
i do have a firewire controller

Comment 5 Dave Jones 2004-06-17 00:01:34 UTC
and does the problem go away if you boot with nofirewire ?

Comment 6 filippo david 2004-06-17 07:12:17 UTC
i tried to boot with nofirewire , but it still hangs the same way.

Comment 7 Arjan van de Ven 2004-06-19 12:20:07 UTC
can you remove the firewire modules entirely, eg
rm /lib/modules/2.6.6-1.435smp/kernel/drivers/ieee1394/* 
and see if that prevents the oops ?

Comment 8 filippo david 2004-06-19 16:35:52 UTC
>can you remove the firewire modules entirely, eg
>rm /lib/modules/2.6.6-1.435smp/kernel/drivers/ieee1394/* 
>and see if that prevents the oops ?

now i can boot ok.

Comment 9 Arjan van de Ven 2004-06-19 16:38:58 UTC
ok so firewire is still bust.. sigh

Comment 10 Alexandre Oliva 2004-06-20 01:39:18 UTC
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.

Comment 11 Morten Nielsen 2004-06-20 21:00:44 UTC
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?)

Comment 12 Serg Oskin 2004-06-29 19:28:43 UTC
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   
  \_ -bash
4     0  3086  3053  15   0  7116 1968 wait4  S    pts/7      0:00   
      \_ kudzu
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. :)

Comment 13 Dave Jones 2004-07-04 13:47:05 UTC
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)

Comment 14 Serg Oskin 2004-07-07 19:01:40 UTC
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
Call Trace:
 [<02115749>] activate_task+0x51/0x5c
 [<02281b92>] wait_for_completion+0x79/0xa3
 [<02115e4e>] default_wake_function+0x0/0xc
 [<02115e4e>] default_wake_function+0x0/0xc
 [<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]
 [<02197d34>] pci_device_remove+0x16/0x28
 [<021db000>] device_release_driver+0x3c/0x46
 [<021db022>] driver_detach+0x18/0x26
 [<021db1f7>] bus_remove_driver+0x37/0x64
 [<021db4d3>] driver_unregister+0xc/0x2a
 [<02197ea5>] pci_unregister_driver+0xb/0x13
 [<02126b65>] sys_delete_module+0x122/0x162
 [<02138df5>] unmap_vma+0x4a/0x60
 [<02138e19>] unmap_vma_list+0xe/0x17
 [<02139110>] do_munmap+0xfd/0x107
 [<021143fc>] do_page_fault+0x0/0x446

Comment 15 Serg Oskin 2004-07-07 20:19:35 UTC
Created attachment 101688 [details]

Comment 16 Serg Oskin 2004-07-07 20:20:37 UTC
Created attachment 101689 [details]
strace /sbin/modprobe -q -r ohci1394

Comment 17 Serg Oskin 2004-07-07 20:21:27 UTC
Created attachment 101690 [details]
ltrace /sbin/modprobe -q -r ohci1394

Comment 18 Serg Oskin 2004-07-07 20:22:52 UTC
See attachments for some trace.

P.S. More simple way of reproduction:
1. modprobe -s ohci1394
2. modprobe -r ohci1394

Comment 19 Jean-Christophe Baillie 2004-08-05 19:50:05 UTC

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/

Comment 20 josip 2004-08-13 11:21:29 UTC
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

Comment 21 josip 2004-08-13 11:36:49 UTC
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
my system:

02:00.0 FireWire (IEEE 1394): Lucent Microelectronics FW323 (rev 04)
03:0c.2 FireWire (IEEE 1394): Creative Labs SB Audigy FireWire Port

Comment 22 josip 2004-08-13 12:11:13 UTC
There is no need to remove the ieee1394 drivers.  Roger J. Allen
discovered (see
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

Comment 23 George Lunsford 2004-08-21 19:50:57 UTC
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)

Comment 24 Alexander Nagorny 2004-09-28 06:02:09 UTC
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?

Comment 25 Alexander Nagorny 2004-09-28 10:39:25 UTC
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.

Comment 26 Dave Jones 2004-11-27 20:21:49 UTC
mass update for old bugs:

Is this still a problem with the 2.6.9 based update kernel ?

Comment 27 timothy nguyen 2005-04-13 03:10:32 UTC
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.

Comment 28 Dave Jones 2005-04-13 03:24:32 UTC
if you don't have firewire its unrelated to this bug, please file a new one for it.

Comment 29 Dave Jones 2005-04-16 05:42:00 UTC
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.

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