Activate Firewire inteface in Tumbleweed

Hi all,

I want to connect my Sony camcorder trough the firewire interface in my system, but I dont’t know how to enable firewire on Tumbleweed.
On the same hardware I got a connection in former (I think 13.x, or maybe even 12.x or earlier) opensuse versions, and for as far I can remember I had to modprobe raw1394 to accomplish that.
Then I could read from /dev/raw1394.

Now when trying to modprobe raw1394 the module doesn’t exist:


modprobe raw1394
modprobe: FATAL: Module raw1394 not found in directory /lib/modules/4.11.8-1-default

Hence /dev/raw1394 doesn’t exist either.

modprobe firewire-ohci did succeed:

lsmod | grep firewire
firewire_ohci          45056  0
firewire_core          73728  1 firewire_ohci
crc_itu_t              16384  1 firewire_core

As a normal user, dvgrab gives

dvgrab
raw1394 - failed to get handle: Too many open files.

and as root:

dvgrab
rom1394_0 warning: read failed: 0x0000fffff0000414
error reading config rom directory for node 0
Error: no camera exists

Anyone an idea how to do this?

IIRC it wasn’t raw1394, but dv1394… But, 'locate -i 1394 doesn’t show any kernelmodules. So, something must have changed.

I am not at all familiar with firewire devices, but


grep FIREWIRE /boot/config-4.11.8-1-default 
CONFIG_FIREWIRE=m
CONFIG_FIREWIRE_OHCI=m
CONFIG_FIREWIRE_SBP2=m
CONFIG_FIREWIRE_NET=m
CONFIG_FIREWIRE_NOSY=m
CONFIG_SND_FIREWIRE=y
CONFIG_SND_FIREWIRE_LIB=m
CONFIG_SND_FIREWIRE_DIGI00X=m
CONFIG_SND_FIREWIRE_TASCAM=m
CONFIG_FIREWIRE_SERIAL=m

these would be my starting points for further investigations.

AK

P.S.

See also the comments in:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/drivers/firewire/Kconfig?h=linux-4.11.y

Hey come on. I’m not a kernel specialist, neither is the OP, nor can you expect us to understand what you’re saying. Why not provide some noob-level info, I know you can.

  1. See my P.S. (was added as an edit, maybe you didn’t/couldn’t see it whe writing your reply)

  2. Neither am I a specialist and I am pretty sure using the “usual suspects” (dmesg etc.) is certainly not beyond your (and the OPs) capabilities.

  3. No, can’t provide such info for FireWire stuff, only what my own Google-FU brings up and there again, see 2).

AK

I have the same results from as Akoellh:

grep FIREWIRE /boot/config-4.11.8-1-default
CONFIG_FIREWIRE=m
CONFIG_FIREWIRE_OHCI=m
CONFIG_FIREWIRE_SBP2=m
CONFIG_FIREWIRE_NET=m
CONFIG_FIREWIRE_NOSY=m
CONFIG_SND_FIREWIRE=y
CONFIG_SND_FIREWIRE_LIB=m
CONFIG_SND_FIREWIRE_DIGI00X=m
CONFIG_SND_FIREWIRE_TASCAM=m
CONFIG_FIREWIRE_SERIAL=m

but no idea what is said there. Especially no idea what “=m” means - is it active or not?

I read the comment in the link Akoellh gave, but this also doesn’t ring a bell with me.
Something about compiling a kernel I think, but that’s beyond my expertise, and besides that I think I would have to do that after each kernel update from Tumbleweed.

But thanks for reacting!

Nope, =m means “Module” (see also below).

Seriously?

Let me quote:


config FIREWIRE
    tristate "FireWire driver stack"
    select CRC_ITU_T
    help
      **This is the new-generation IEEE 1394 (FireWire) driver stack**
      a.k.a. Juju, a new implementation designed for robustness and
      simplicity.
      See http://ieee1394.wiki.kernel.org/index.php/Juju_Migration
      for information about migration from **the older Linux 1394 stack
      to the new driver stack.**

      **To compile this driver as a module, say M here**: the module will be
      called firewire-core.

Even your question “What does the M mean?” is answered there, and the other answer is most likely “Things have been changed and modules might have new names now”.

AK

Seriously? Seriously… I didn’t see the connection. Maybe you overestimate my technical insights here; I’m sorry!.
But, thanks for the explanation. Seriously!:wink:

I noticed the word dmesg in your former post, so I did

dmesg | grep firewire
    4.058602] firewire_ohci 0000:07:0e.0: added OHCI v1.10 device as card 0, 4 IR + 8 IT contexts, quirks 0x2
    4.570646] firewire_core 0000:07:0e.0: created device fw0: GUID 00cab7e20000241d, S400
[23637.164086] firewire_core 0000:07:0e.0: giving up on node ffc0: reading config rom failed: bus reset
[23637.164126] firewire_core 0000:07:0e.0: rediscovered device fw0
[23639.884444] firewire_core 0000:07:0e.0: rediscovered device fw0
[23643.468857] firewire_core 0000:07:0e.0: rediscovered device fw0
[23646.317218] firewire_core 0000:07:0e.0: rediscovered device fw0
[23648.365479] firewire_core 0000:07:0e.0: rediscovered device fw0
[23648.365498] firewire_core 0000:07:0e.0: phy config: new root=ffc1, gap_count=5
[23648.877723] firewire_core 0000:07:0e.0: rediscovered device fw0
[23650.381676] firewire_core 0000:07:0e.0: giving up on node ffc0: reading config rom failed: timeout
[27294.826924] firewire_core 0000:07:0e.0: giving up on node ffc0: reading config rom failed: bus reset
[27295.358236] firewire_core 0000:07:0e.0: rediscovered device fw0
[36345.456142] firewire_core 0000:07:0e.0: rediscovered device fw0
[36345.456160] firewire_core 0000:07:0e.0: phy config: new root=ffc1, gap_count=5
[36345.968212] firewire_core 0000:07:0e.0: rediscovered device fw0
[36346.061049] firewire_core 0000:07:0e.0: created device fw1: GUID 080046010247290e, S100
[36347.472152] firewire_core 0000:07:0e.0: giving up on node ffc0: reading config rom failed: timeout

There is a fw0 in /dev:

l /dev/fw*
crw------- 1 root root 247, 0  8 jul 12:43 /dev/fw0

but no /dev/ffc<somenumber>

Anyway, any hints to what can I do now to make dvgrab work? Or kino (which, I thought, depends on dvgrab)?

This here

dmesg | grep firewire
[23650.381676] firewire_core 0000:07:0e.0: giving up on node ffc0: **reading config rom failed: timeout**
[27294.826924] firewire_core 0000:07:0e.0: giving up on node ffc0: **reading config rom failed: bus rese**t

sounds pretty bad to me.

The ROM on a device can not be read, either there is

a) an error in the driver

b) something missing (i.e. firmware)

c) some hardware defect

As for b) I don’t have any clue if this applies to firewire devices, but if I search for

“giving up on node ffc0: reading config rom failed: timeout”

with my favourite search engine, I find quite a few examples for a) and c).

AK

On Sun 09 Jul 2017 05:06:01 PM CDT, jehojakim wrote:

Seriously? Seriously… I didn’t see the connection. Maybe you
overestimate my technical insights here; I’m sorry!.
But, thanks for the explanation. Seriously!:wink:

I noticed the word dmesg in your former post, so I did

Code:

dmesg | grep firewire
4.058602] firewire_ohci 0000:07:0e.0: added OHCI v1.10 device as
card 0, 4 IR + 8 IT contexts, quirks 0x2 4.570646] firewire_core
0000:07:0e.0: created device fw0: GUID 00cab7e20000241d, S400
[23637.164086] firewire_core 0000:07:0e.0: giving up on node ffc0:
reading config rom failed: bus reset [23637.164126] firewire_core
0000:07:0e.0: rediscovered device fw0 [23639.884444] firewire_core
0000:07:0e.0: rediscovered device fw0 [23643.468857] firewire_core
0000:07:0e.0: rediscovered device fw0 [23646.317218] firewire_core
0000:07:0e.0: rediscovered device fw0 [23648.365479] firewire_core
0000:07:0e.0: rediscovered device fw0 [23648.365498] firewire_core
0000:07:0e.0: phy config: new root=ffc1, gap_count=5 [23648.877723]
firewire_core 0000:07:0e.0: rediscovered device fw0 [23650.381676]
firewire_core 0000:07:0e.0: giving up on node ffc0: reading config rom
failed: timeout [27294.826924] firewire_core 0000:07:0e.0: giving up on
node ffc0: reading config rom failed: bus reset [27295.358236]
firewire_core 0000:07:0e.0: rediscovered device fw0 [36345.456142]
firewire_core 0000:07:0e.0: rediscovered device fw0 [36345.456160]
firewire_core 0000:07:0e.0: phy config: new root=ffc1, gap_count=5
[36345.968212] firewire_core 0000:07:0e.0: rediscovered device fw0
[36346.061049] firewire_core 0000:07:0e.0: created device fw1: GUID
080046010247290e, S100 [36347.472152] firewire_core 0000:07:0e.0:
giving up on node ffc0: reading config rom failed: timeout

There is a fw0 in /dev:

Code:

l /dev/fw*
crw------- 1 root root 247, 0 8 jul 12:43 /dev/fw0


but no /dev/ffc<somenumber>

Anyway, any hints to what can I do now to make dvgrab work? Or kino
(which, I thought, depends on dvgrab)?

Hi
If you reboot the system with the camera attached, does this make a
difference?

Wonder if a kernel module parameter (firewire-ohci) may help for your
device.


Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.2|GNOME 3.20.2|4.4.74-18.20-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

Yes it does! As root I can simply issue “dvgrab -autosplit” and it reads the tape to disk. Have to see if kino works, but that’s not too important.
It is somewhat inconvenient to have to do this as root, but that will be an issue of giving the right rights to /dev/fw<x> I think? Besides, it’s not more than inconvenient.

Wonder if a kernel module parameter (firewire-ohci) may help for your
device.

Not necessary now I think?

Thanks!

I recall an old thread on this topic, where I described how udev is supposed to provide ACL access. Obviously, the rules don’t get triggered in your case (and more investigation would be needed to figure out why).

Anyway, perhaps a simple custom rule might suffice to set appropriate group permissions instead eg /etc/udev/rules.d/90-firewire.rules

KERNEL=="fw*", GROUP="video", MODE="0664"

then just add the relevant user to the video group.

YMMV.

Am Mon, 10 Jul 2017 07:56:01 GMT
schrieb jehojakim <jehojakim@no-mx.forums.microfocus.com>:

> malcolmlewis;2829529 Wrote:
> > Hi
> > If you reboot the system with the camera attached, does this make a
> > difference?
> >
>
> Yes it does! As root I can simply issue “dvgrab -autosplit” and it reads
> the tape to disk.

Leaving aside the potential problem with ACL/udev, but AFAIK Firewire should be
a hot-pluggable interface (correct me if I’m wrong).

So if hot-plug does not work, I would consider a bug report at
bugzilla.opensuse.org (but be aware you might get “redirected” to
bugzilla.kernel.org).

AK

Never attribute to malice that which can be adequately explained by stupidity.
(R.J. Hanlon)