Proper permanent setup of 1394 drivers

[Mark Knecht]

On Mon, 11 Oct 2004 16:00:49 -0700, Rick Stevens
<rstevens at vitalstream.com> wrote:
> Mark Knecht wrote:
> > Rick Stevens wrote:
> >
> >> Mark Knecht wrote:
> >>
> >>> Hi,
> >>>    Under FC2 what is the proper way to tell it to load the 1394
> >>> drivers at boot time? 
<SNIP>
> >> In /etc/modprobe.conf (the replacement for /etc/modules.conf under
> >> 2.6 kernels).  The modules.dep file shows some dependencies, but not
> >> enough to satisfy your needs.  However, we can forcefeed the modules you
> >> want as follows:
> >>
> >> 1.  Create an "/etc/modules.special" file.  In it, put in the following
> >> lines:
> >>
> >>     /sbin/modprobe ohci1394
> >>     /sbin/modprobe ieee1394
> >>     /sbin/modprobe sbp2
> >>
> >> (you can optionally stuff a little ">/dev/null 2>&1" at the end of each
> >> line if you want any possible "already loaded" messages to go to the bit
> >> bucket).  Save the file and set as owner and group root, permissions
> >> 555:
> >>
> >>     chown root:root /etc/modules.special
> >>     chmod 555 /etc/modules.special
> >>
> >> 2. Edit /etc/modprobe.conf and add these lines:
> >>
> >>     install ohci1394 /etc/modules.special
> >>     install ieee1394 /etc/modules.special
> >>     install sbp2 /etc/modules.special
> >>

<SNIP>

> > Rick,
> >    Thanks, but not working right so far:
> >
> > 1) When I booted none of the modules were actually loaded. Smallish
> > problem, but it would still require me to su to root and modprobe one of
> > the drivers, if problem 2 didn't exist...
> 
> Are the aliases still in the file?  The installs aren't triggered until
> the alias is invoked--usually due to a USB bus scan or a "plug in"
> event.

Here's a snippet of modprobe.conf. I've commented them out for fear of
a repeat of yesterday until I better understand what I'm doing:

<SNIP>
alias wlan0 ndiswrapper

#install ohci1394 /etc/modules.special
#install ieee1394 /etc/modules.special
#install sbp2 /etc/modules.special

# ALSA portion
alias char-major-116 snd
alias snd-card-0 snd-atiixp
<SNIP>

modules.special looked like:

/sbin/modprobe ohci1394 > /dev/null 2>&1
/sbin/modprobe ieee1394 > /dev/null 2>&1
/sbin/modprobe sbp2 > /dev/null 2>&1

Permissions are:

flash etc # ls -al modules.special 
-r-xr-xr-x  1 root root 119 Oct 11 15:26 modules.special
flash etc # 

> 
> > 2) modprobe sbp2 resulted in my console running away on me.  The hard
> > drive when into 100% access. (visually anyway) Going to another console
> > and running top shown only top taking up CPU accesses.
> 
> Really?  That's odd.  When you say "running away", you mean that console
> wouldn't respond?  Are you sure the disk activity wasn't caused by, say,
> an updatedb or prelink run?

To the extent 'top' would respond there was no process taking up the
CPU cycles. The disk drive was in a 100% used state visually - light
on and drive head moving a bunch. To me it looked like a run away
write process to a log file, but I saw nothing obvious in /var/log/.
messages just seemed to have normal boot messages.


> 
> sbp2 does require the scsi_mod module, but the modprobe should have
> loaded it because the modules.dep says it's a dependency.  Very weird.
> 
> >                                                        The only way out,
> > after a minute or two of this, was a power button push. Upon startign
> > again I'm greeted with 'system not shutdown cleanly' and a file system
> > check. Ctrl-D when it was done, a reboot, another file system check, and
> > then it booted.
> >
> > Not a pretty sight!
> 
> Uh, no.  Yuck!  Sorry about that. :-(

Thanks. Not your fault. This stuff happens.

> 
> > The system is back up. Nothing in dmesg or /var/log/messages of any
> > obvious interest. Nothing in lost+found. (thankfully)
> 
> Whew!
> 
> > I think something is not quite right here.... ;-)
> 
> Yeah.  Hmmm.  Well, you could add an "/sbin/modprobe scsi_mod" before
> the "/sbin/modprobe sbp2" in the modules.special file if you're willing
> to try again.  Or you can delete all that stuff I mentioned and simply
> add the appropriate modprobe commands to /etc/rc.d/rc.local.  That's
> real simple, except that they'll load every time you boot--even if you
> don't have a device that uses them.  Your call.  I don't have any 1394
> devices to play with or I'd do some testing for you.

I haven't been quite brave enough to try again just yet. I have no
problem with loading the 1394 drivers every time as I pretty much use
1394 hard drives for all of my audio work. Maybe rc.local is actually
a good choice in my case...

Thanks,
Mark