Description of problem: Not sure where to file this. When an application tries to open /dev/raw1394, the raw1394 is not loaded on demand like it should be. modprobe -c shows that the built-in alias is there: alias char-major-171 raw1394 and looks correct. But after 'modprobe raw1394', the application trying to open /dev/raw1394 works, and dmesg shows that the raw1394 module has loaded. Perhaps this is an initscripts problem (should the initscripts load raw1394 when dealing with firewire?), or a modutils problem (not finding the module for some reason?) or a kernel problem (not requesting a module load in ieee1394_core?). Just don't know.
Hm, I just tried it here, and it loaded raw1394 and ieee1394.
On a fresh install? I just did a kickstart install and tried it earlier today, and it would not work. How were you trying it? I was using kino originally, but could reproduce the failure with 'cat </dev/raw1394'. Also, do you have a fireware card installed on the machine you tried it on? I think that might be important; perhaps ieee1394_core provides backing for that device and forgets to load the relevant low-level driver or something. On boot, this machine has ohci1394 and ieee1394 loaded (but not raw1394 or video1394).
A not-so-fresh-install; it's a freshen from one of the betas. I got the modules to load just by running 'cat /dev/raw1394' (which failed with EINVAL). This machine does *not* have a firewire card, however.
I get the same on a machine without a firewire card. But the problem persists on a machine with fireware card installed. I think this must be related to the ohci1394/ieee1394 modules being already loaded. During boot, it says about initializing the firewire card (which is when it loads the modules, presumably). Perhaps it should just load raw1394 and video1394 at that stage?
Eek, this is old. My apologies. Does it still happen on FC4?
I have different hardware now, so I don't know.
OK. Will assume it has fixed itself with newer release.