Bug 231708

Summary: new firewire stack in FC7t2 has broken userspace tools
Product: [Fedora] Fedora Reporter: Alex Kanavin <ak>
Component: mkinitrdAssignee: Kristian Høgsberg <krh>
Status: CLOSED NEXTRELEASE QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: medium    
Version: 8CC: cebbert, davej, jarod, katzj, kevin, notting, pjones, stefan-r-rhbz
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-09-14 16:12:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 150226    
Description Flags
anaconda.log file
Patch to mkinitrd to teach it about the new firewire modules.
Patch to anaconda to teach it about the new firewire modules.
kudzu patch
anaconda log with i/o error
dmesg output
lspci -v output
sysfs dump
fix mkinitrd to support new firewire stack
f8test2 anaconda log where firewire is not recognized none

Description Alex Kanavin 2007-03-10 14:42:55 UTC
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

Comment 1 Alex Kanavin 2007-03-10 15:46:26 UTC
Created attachment 149774 [details]
anaconda.log file

This is the FC7t2 anaconda log file, where firewire is not configured and
external drive not detected.

Comment 2 Kristian Høgsberg 2007-03-12 16:17:13 UTC
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.

Comment 3 Kristian Høgsberg 2007-03-12 16:26:14 UTC
Created attachment 149834 [details]
Patch to anaconda to teach it about the new firewire modules.

Same thing for anaconda.

Comment 4 Alex Kanavin 2007-03-12 18:02:50 UTC
I think also kudzu needs to be fixed and possibly yaboot.

Comment 5 Jeremy Katz 2007-03-19 20:06:36 UTC
Yeah, kudzu definitely needs work here.

Added the modules to anaconda's list, though.

Comment 6 Kristian Høgsberg 2007-03-21 15:26:27 UTC
Created attachment 150593 [details]
kudzu patch

Patch to teach kudzu about the new (not too different) sysfs structure.

Comment 7 Jeremy Katz 2007-03-23 16:11:18 UTC
Added to mkinitrd and made kudzu support both.  So things should be better here now

Comment 8 Alex Kanavin 2007-03-24 13:38:59 UTC
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.

Comment 9 Jeremy Katz 2007-03-26 14:55:38 UTC
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

Comment 10 Alex Kanavin 2007-03-29 18:07:20 UTC
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. 

Comment 11 Alex Kanavin 2007-03-29 18:09:48 UTC
Created attachment 151215 [details]
anaconda log with i/o error

Comment 12 Alex Kanavin 2007-03-29 18:11:04 UTC
Created attachment 151216 [details]
dmesg output

Comment 13 Kristian Høgsberg 2007-04-06 23:00:22 UTC
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.

Comment 14 Kristian Høgsberg 2007-04-06 23:01:39 UTC
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.

Comment 15 Alex Kanavin 2007-04-10 16:05:58 UTC
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.

Comment 16 Matthias Clasen 2007-04-17 22:35:19 UTC
This should probably be reopened then.

Comment 17 Kristian Høgsberg 2007-04-24 20:52:28 UTC
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.

Comment 18 Alex Kanavin 2007-04-24 23:03:22 UTC
Created attachment 153390 [details]
lspci -v output

Comment 19 Alex Kanavin 2007-04-24 23:04:33 UTC
Created attachment 153391 [details]
sysfs dump

Comment 20 Alex Kanavin 2007-04-24 23:09:05 UTC
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.

Comment 21 Kevin Fenzi 2007-05-12 21:23:03 UTC
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. 

Comment 22 Will Woods 2007-05-17 21:17:43 UTC
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 

Comment 23 Alex Kanavin 2007-07-23 01:09:53 UTC
Great. In 2.6.22 the modules have been renamed once again (to firewire-*.ko), so we have to do this 
dance once more. 

Comment 24 Alex Kanavin 2007-07-23 01:10:54 UTC
Also note the patch in bug #246496

Comment 25 Stefan Richter 2007-07-23 06:03:11 UTC
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.

Comment 26 Stefan Richter 2007-07-23 06:04:23 UTC
Or more precisely, all of them are loaded if they exist.

Comment 27 Alex Kanavin 2007-07-23 11:17:34 UTC
It matters if you need to put module files into images (anaconda, initrd) - then udev won't help you.

Comment 28 Stefan Richter 2007-07-23 14:14:38 UTC
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.

Comment 29 Alex Kanavin 2007-07-23 14:19:50 UTC
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.

Comment 30 Alex Kanavin 2007-07-23 14:24:18 UTC
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).

Comment 31 Alex Kanavin 2007-08-15 16:17:21 UTC
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.

Comment 32 Dave Jones 2007-08-22 21:11:38 UTC
Jeremy/Peter, sounds like another anaconda/mkinitrd update is in order?

Comment 33 Alex Kanavin 2007-08-22 21:19:23 UTC
Possibly also kudzu because the original patch had lines like:

-				fwdev->driver = strdup("sbp2");
+				fwdev->driver = strdup("fw-sbp2");

Comment 34 Jeremy Katz 2007-08-23 15:10:29 UTC
*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.

Comment 35 Alex Kanavin 2007-09-01 00:47:50 UTC
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.

Comment 36 Alex Kanavin 2007-09-01 10:45:22 UTC
*** Bug 246496 has been marked as a duplicate of this bug. ***

Comment 37 Peter Jones 2007-09-07 21:38:35 UTC
This should be fixed in current releases for all of the firewire stacks.

Comment 38 Alex Kanavin 2007-09-08 13:41:52 UTC
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}                                         
        emit "echo Waiting for driver initialization."                          
        emit "stabilized /sys/bus/${fwsubsys}/drivers/sbp2"
        unset fwsubsys                                                          

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"
    if [ "$module" = "fw-sbp2" -o "$module" = "firewire-sbp2" ]; then
        emit "echo Waiting for driver initialization."
        emit "stabilized /sys/bus/firewire/drivers/sbp2"

Comment 39 Alex Kanavin 2007-09-13 22:57:16 UTC
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?