Proper permanent setup of 1394 drivers

[Rick Stevens]

Mark Knecht wrote:
> 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>

Hmmm.  The only alias is for ndiswrapper.  So the driver loads are
invoked via hotplug--not via the kernel monitor.

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

That all looks legit.  As I said, the modprobe of sbp2 should also bring
in scsi_mod if it's not already loaded.

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

As I said, it could have been an updatedb or prelink run.  Those can
flog the drive.  A "ps -ax" and scanning for "prelink" or "updatedb"
would have been nice.  I hate coincidences.

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

It's certainly the easiest place to control.  I'll have to look at the
hotplug configs to see if there's an easy way to make sure your drivers
get loaded.  I don't know why I didn't think of that before, since 1394
is a hotplug thing.  Sheesh!
----------------------------------------------------------------------
- Rick Stevens, Senior Systems Engineer     rstevens at vitalstream.com -
- VitalStream, Inc.                       http://www.vitalstream.com -
-                                                                    -
-   "I was remembering the immortal words of Socrates when he said,  -
-   'I drank what?'"                 -- Val Kilmer in "Real Genius"  -
----------------------------------------------------------------------