Bug 19902 - /dev/raw1394 stopped working
Summary: /dev/raw1394 stopped working
Status: CLOSED INVALID
Alias: None
Product: Drivers
Classification: Unclassified
Component: IEEE1394 (show other bugs)
Hardware: All Linux
: P1 high
Assignee: drivers_ieee1394
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-08 06:54 UTC by Werner Lemberg
Modified: 2010-10-10 11:11 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.36-rc5 and newer
Tree: Mainline
Regression: Yes


Attachments

Description Werner Lemberg 2010-10-08 06:54:47 UTC
[openSuSE kernel 2.6.36-rc4-18]
[openSuSE kernel 2.6.36-rc6-25]

Up to and including 2.6.36-rc4, attaching my Panasonic Digital Video Camera (NV-GS3) worked just fine; the kernel message was

  ieee1394: Node added: ID:BUS[0-00:1023]  GUID[0080458050f5706f]
  ieee1394: Node changed: 0-00:1023 -> 0-01:1023
  ieee1394: raw1394: /dev/raw1394 device initialized

Starting with 2.6.36-rc5, I get this

  firewire_ohci: isochronous cycle inconsistent
  firewire_core: created device fw1: GUID 0080458050f5706f, S100
  firewire_core: phy config: card 0, new root=ffc1, gap_count=5
  firewire_core: IRM is not 1394a compliant, making local node (ffc0) root.
  firewire_core: phy config: card 0, new root=ffc0, gap_count=5
  ieee1394: raw1394: /dev/raw1394 device initialized

and `dvgrab' aborts with

  Error: no camera exists
Comment 1 Werner Lemberg 2010-10-08 07:01:56 UTC
In case it is of importance: In the boot log of 2.6.36-rc6, I find these lines:

  firewire_ohci 0000:03:01.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
  firewire_ohci: Added fw-ohci device 0000:03:01.0, OHCI v1.10, 4 IR + 4 IT contexts, quirks 0x1
  firewire_core: created device fw0: GUID 434fc000134a9850, S400
Comment 2 Werner Lemberg 2010-10-08 07:47:50 UTC
And the rc4 log shows

  ohci1394 0000:03:01.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
  ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[19]  MMIO=[ef9fd800-ef9fdfff]  Max Packet=[2048]  IR/IT contexts=[4/4]
  ieee1394: Host added: ID:BUS[0-00:1023]  GUID[434fc000134a9850]
Comment 3 Stefan Richter 2010-10-08 12:18:57 UTC
This is may be an installation issue.

There are two IEEE 1394 kernel driver stacks:
older: ohci1394 + ieee1394 + raw1394/video1394/dv1394
newer: firewire-ohci + firewire-core

The userspace interface of raw1394 is /dev/raw1394, a single file for all 1394 controllers in the system and all nodes attached to all these cards.

The userspace interface of firewire-core is /dev/fw*, multiple files which are created and destroyed on the fly separately for each detected node.

/dev/raw1394 as well as /dev/fw* are managed by udev, including their ownership and access permissions.

Libraw1394 (which operates between dvgrab and kernel) is able to transparently switch between these interfaces since version 2.0.

With kernel 2.6.36-rc4, you happened to use the older stack, but with 2.6.36-rc6 you happened to use the newer one.  The reason for this change of default behavior is a side effect of this otherwise unrelated commit after 2.6.36-rc4/ before 2.6.36-rc5:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8702d33aa6e6d753ef99163afe48aba1323374ef

Anyway.  Comment #0 shows that the newer drivers detected the camera just fine (as "fw1: GUID 0080458050f5706f, S100").  Therefore a /dev/fw1 should exist and, if library version and /dev/fw* access permissions are correct, should be used by libraw1394, fully transparent for dvgrab.

When the camcorder is plugged in and switched on, please check whether /dev/fw1 exists and whether your user has permission to access it.

Some more information is available at https://ieee1394.wiki.kernel.org/index.php/Juju_Migration -- including directions how you configure modprobe to automatically load either firewire-ohci or ohci1394 according to _your_ preference rather than dependent on some obscure circumstances in the kernel build system.
Comment 4 Stefan Richter 2010-10-08 12:46:27 UTC
Loosely related downstream ticket:
https://bugzilla.novell.com/show_bug.cgi?id=586172
Comment 5 Werner Lemberg 2010-10-08 17:12:58 UTC
Thanks a lot for your detailed and concise answer!  It was indeed a configuration issue: dvgrab as distributed with the current openSuSE factory is linked to libraw1394.so.8, which is too old.  Compiling dvgrab manually and forcing a link to libraw1394.so.11 makes it work.  I've written a report to the opensuse-factory mailing list.

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