The new firewire stack in FC7t2 seems to have broken userspace tools. For example my external firewire hard drive is not any longer recognized by FC7t2 anaconda as an installation target, because firewire and sbp2 kernel drivers are not loaded. I'm not sure if they are even present on the installation media because they seem to have got new names. You should check and fix all related tools, anaconda and mkinitrd at the very least. Let me know if help/testing is needed.
Created attachment 149774 [details] anaconda.log file This is the FC7t2 anaconda log file, where firewire is not configured and external drive not detected.
Created attachment 149832 [details] Patch to mkinitrd to teach it about the new firewire modules. The patch is just a search and replace in mkinitrd, but I assume it has the desired effect, since the module structure and dependencies are the same in the new stack as in the old, just the names are different.
Created attachment 149834 [details] Patch to anaconda to teach it about the new firewire modules. Same thing for anaconda.
I think also kudzu needs to be fixed and possibly yaboot.
Yeah, kudzu definitely needs work here. Added the modules to anaconda's list, though.
Created attachment 150593 [details] kudzu patch Patch to teach kudzu about the new (not too different) sysfs structure.
Added to mkinitrd and made kudzu support both. So things should be better here now
I just tried the latest development iso, and fw-ohci module is loaded, but fw-sbp2 is not. So the external hard drive is still not set up.
All the bits are committed, but not going into rawhide as we're currently in the freeze period for test3. Things should thaw out in the next day or two
Just tried test3, and there is only slight progress: the modules are loaded, the drive is recognized, but when anaconda tries to access it, during partition search, the following error occurs: <5>fw_sbp2: sbp2_scsi_abort <5>fw_sbp2: sbp2_scsi_abort <6>sd 0:0:0:0: scsi: Device offlined - not ready after error recovery <6>sd 0:0:0:0: SCSI error: return code = 0x00020000 <4>end_request: I/O error, dev sda, sector 0 <3>sd 0:0:0:0: rejecting I/O to offline device <3>sd 0:0:0:0: rejecting I/O to offline device ... and many more of these "rejecting" lines. Of course, the same drive works fine in FC6.
Created attachment 151215 [details] anaconda log with i/o error
Created attachment 151216 [details] dmesg output
I fixed a critical error that would cause data corruption typically under heavy throughput, the fix is in kernel-2.6.20-1.3051.fc7. If you could give that a try and see if it fixed the problem, that'd be great.
Just tried the latest rawhide rescue iso (3053 kernel I think) and nothing has changed, the problem is still there :( Could this be powerpc-specific? There is a similar bug #235199 with a firewire scanner that's also on powerpc. I have also noticed that in rescue mode I get random kernel errors either during a mount attempt or during shutting down. I can write some of these down for you, but they don't occur in normal installation mode.
This should probably be reopened then.
Alex, could you provide a bit more information about your drive and you firewire controller? If you can attach output of lspci and the sysfs-dump.tar.gz file created like this: find /sys/devices -name config_rom | tar cz -T - -f sysfs-dump.tar.gz that would be a great help. Thanks.
Created attachment 153390 [details] lspci -v output
Created attachment 153391 [details] sysfs dump
There you go. Anything else? The controller is a standard Apple Powerbook G4 firewire controller, and the drive is an IDE-to-Firewire enclosure based on a Prolific PL-3507 chip. They both work fine in FC6.
I am able to duplicate this on my ppc32 G4 as well... The machine here were I can duplicate it is a total test box. I'd be happy to provide access to anyone who can fix this/look at it. Happy to also provide any info. Would the info for this box from comment #17 be of use? Feel free to drop me an email with an ssh key for access.
I think the original bug here - userspace tools not handling new firewire stack properly - is fixed. Further tracking of the new problem - firewire failures on ppc - will be done here: bug #238606
Great. In 2.6.22 the modules have been renamed once again (to firewire-*.ko), so we have to do this dance once more.
Also note the patch in bug #246496
On an udev system, module names don't matter at all. The module aliases do everything for you automatically: One of ohci1394, fw-ohci, firewire-ohci is loaded for PCI devices which implement OHCI-1394. One of sbp2, fw-sbp2, firewire-sbp2 is loaded for FireWire devices which implement SBP-2.
Or more precisely, all of them are loaded if they exist.
It matters if you need to put module files into images (anaconda, initrd) - then udev won't help you.
It's not really udev itself but what udev is doing, AFAIU: React on kernel "uevents" which contain the information necessary to load kernel modules according to their module alias. I don't see why an initrd couldn't do that. Anaconda (or kudzu?) may be a different beast.
Before initrd gets into action you need to assemble an initrd image with all the necessary module files which happens during kernel package installation. It's handled by mkinitrd script, and 2.6.22 firewire renaming broke that script again.
Actually, no, I think I'm wrong you're right, the correct modules are packaged still. :) The thing that did get broken is driver initialization wait (more info in bug 246496).
I just tried F8test1 installation, and the firewire modules are not loaded and firewire disks not recognized, because the modules got new names yet again in 2.6.22 - firewire-ohci etc. Fixing it should be similar to the patches for anaconda and kudzu provided here. Also mkinitrd script needs to be fixed, in two places - where it adds the modules and where it's using the 'stabilized' command to load them with proper delays. The mkinitrd problem is present on F7 as well.
Jeremy/Peter, sounds like another anaconda/mkinitrd update is in order?
Possibly also kudzu because the original patch had lines like: - fwdev->driver = strdup("sbp2"); + fwdev->driver = strdup("fw-sbp2");
*sigh* Adjusted module names in kudzu and building now (which will get picked up the next time anaconda is built). mkinitrd still needs the change.
Created attachment 184241 [details] fix mkinitrd to support new firewire stack The latest mkinitrd from rawhide still hasn't been updated for the new stack, so here's my patch for it. I've tested it and it seems to work. Please apply.
*** Bug 246496 has been marked as a duplicate of this bug. ***
This should be fixed in current releases for all of the firewire stacks.
The fix you have implemented is a bit wrong. It goes like this: # Firewire likes to change the subsystem name every 3 hours. :/ if [ "$module" = "sbp2" -o "$module" = "fw-sbp2" \ -o $module = "firewire-sbp2" ]; then local fwsubsys=${module%%-sbp2} fwsubsys=${fwsubsys/sbp2/ieee1394} emit "echo Waiting for driver initialization." emit "stabilized /sys/bus/${fwsubsys}/drivers/sbp2" unset fwsubsys fi But when the module name is fw-sbp2, the directory name to check is /sys/bus/firewire/drivers/sbp2 and you're checking /sys/bus/fw/drivers/sbp2 So I suggest you go with my original version instead, it's much easier to understand too: if [ "$module" = "sbp2" ]; then emit "echo Waiting for driver initialization." emit "stabilized /sys/bus/ieee1394/drivers/sbp2" fi if [ "$module" = "fw-sbp2" -o "$module" = "firewire-sbp2" ]; then emit "echo Waiting for driver initialization." emit "stabilized /sys/bus/firewire/drivers/sbp2" fi
Created attachment 195331 [details] f8test2 anaconda log where firewire is not recognized In F8test2 firewire is still not recognized and modules not loaded. Could it be because the F8test2 tree was created before the mkinitrd fix went in?