Bug 246496 - PATCH: fix mkinitrd to force waiting for fw-ohci and fw-sbp2 initialization
Summary: PATCH: fix mkinitrd to force waiting for fw-ohci and fw-sbp2 initialization
Status: CLOSED DUPLICATE of bug 231708
Alias: None
Product: Fedora
Classification: Fedora
Component: mkinitrd
Version: 7
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
Depends On: 238606
TreeView+ depends on / blocked
Reported: 2007-07-02 17:46 UTC by Alex Kanavin
Modified: 2007-11-30 22:12 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2007-09-01 10:45:21 UTC

Attachments (Terms of Use)
fix mkinitrd to force waiting for fw-sbp2 initialization (same way as old sbp2 driver) (714 bytes, patch)
2007-07-02 17:46 UTC, Alex Kanavin
no flags Details | Diff

Description Alex Kanavin 2007-07-02 17:46:17 UTC
There is a new firewire stack in F7, but mkinitrd has not been fully updated to
support it. This patch adds the waiting for fw-ohci and fw-sbp2 modules
initialization, just like it's done for the older sbp2 module. This is necessary
when e.g. booting from a firewire drive, so that DM/LVM doesn't get loaded too
soon and fw-sbp2 doesn't try to initialize before fw-ohci finishes loading. I
have tested it on my system (installed on an external firewire drive) and it
seems to work.

Comment 1 Alex Kanavin 2007-07-02 17:46:17 UTC
Created attachment 158360 [details]
fix mkinitrd to force waiting for fw-sbp2 initialization (same way as old sbp2 driver)

Comment 2 Stefan Richter 2007-07-23 06:07:02 UTC
Why wait for driver initialization?  Aren't you rather interested in _device

Comment 3 Alex Kanavin 2007-07-23 11:12:01 UTC
Don't ask me, this is how things have always worked with older stack. I simply have updated mkinitrd to 
support the new module file and directory names.

I need to boot the system from my firewire drive: propose some other method, and I can test it.

Comment 4 Stefan Richter 2007-07-23 14:44:42 UTC
I am not familiar with Fedora's initrd, as I never used Fedora myself.  I even
switched all my PCs which had different (usually initrd based) boot sequences to
initrd-less setups, thus never had the need to dig into the innards of any initrd.

The thing with the old sbp2 driver is:  *If* ieee1394 and ohci1394 were already
up and running as early enough to have any SBP-2 devices already discovered as
such, then the "modprobe sbp2" process would synchronously perform SBP-2 login,
SCSI inquiry, and further SCSI stuff like asking for cache data and disk size
until the /dev/sd* was ready. --- But if ieee1394 would come to know of the
SBP-2 device just a little bit too late, then "modprobe sbp2" would return
quickly, and the rest which I described would have been done later by a kernel

Now, the new drivers work a bit different:  Similar things as about ieee1394 and
ohci1394 can be said about fw-core and fw-ohci.  But no matter if fw-sbp2 was
kicked on before or after fw-core got to know about the SBP-2 device, fw-sbp2
will perform the SBP-2 login, SCSI inquiry and so on *asynchronously* as a
delayed work, in the context of the kernel's event queue thread.  In effect, the
"modprobe fw-sbp2" process (or with mainline 2.6.22: modprobe firewire-sbp2)
will always return quickly before all the SCSI setup was done.  Or that's what I
understood about the implementation.

But again, whether "modprobe sbp2" would synchronously set up the respective
/dev/sd* --- or would only prepare for deferred asynchronous setup --- has
always been a matter of luck, depending on the timing of ohci1394 and ieee1394
and, notably, on the timing of the SBP-2 device's firmware and HDD mechanism itself.

So, the only sane thing to do is to
  - load all modules which are necessary (ideally on demand per module
    alias as soon as the kernel detected a hardware),
  - wait until the desired /dev/sd* with the later root filesystem on it

However, the SCSI folks have implemented a mechanism which provides a
synchronization point for initrds and the like.  The mechanism works by loading
a certain dummy module.  (I am too lazy right now to look up this module's name.
 scsi_wait_scan or something like that.)  This modprobe would block until all
SCSI drivers which are integrated with this framework told the module that they
finished scanning.  I haven't looked into the details of this framework but it
may be possible to add support for it in sbp2/fw-sbp2.  I am using
http://bugzilla.kernel.org/show_bug.cgi?id=3225 as my reminder to investigate
this when I got time.

Comment 5 Alex Kanavin 2007-07-23 15:22:13 UTC
Fedora's initrd is using a custom "stabilized" function for firewire, usb and other things, which seems to 
check existence and mtime of its argument every once in a while (the default is 0.75 seconds). If these 
things haven't changed since the last check, it proceeds. I'm not sure how robust this apporach is, but 
that's how things worked with the old stack and it definitely fixes the problem for me in the new stack - 
maintainers simply forgot to update the module names. Check the patch for the actual paths that it's 

Comment 6 Alex Kanavin 2007-07-23 17:30:53 UTC
Actually, bug 238606 should be solved first, so I'm adding a dependency on that.

Comment 7 Alex Kanavin 2007-09-01 10:44:51 UTC
Comment on attachment 158360 [details]
fix mkinitrd to force waiting for fw-sbp2 initialization (same way as old sbp2 driver)

The bug 238606 has been solved with latest rawhide kernels, and the correct
mkinitrd patch has been submitted to bug 231708, so this bug can be closed.

Comment 8 Alex Kanavin 2007-09-01 10:45:21 UTC

*** This bug has been marked as a duplicate of 231708 ***

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