Bug 125943

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
rm /lib/modules/2.6.6-1.435smp/kernel/drivers/ieee1394/* 
and see if that prevents the oops ?

>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.

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   
  \_ -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. :)

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
20fa8c30
       02115e4e 00000000 00000000 12af3a10 00000003 00000212 00000001
20fa8c30
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

Created attachment 101688 [details]
syslog

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

I,

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/
Thanks,
JCB

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
kernel-2.6.7-1.494.2.2.

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

There is no need to remove the ieee1394 drivers.  Roger J. Allen
discovered (see
http://www.redhat.com/archives/fedora-list/2004-June/msg04335.html)
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
busted.

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.

Thank you.