Firewire camera is not recognized

[Risto H. Kurppa]

Problem:
The system doesn't recognize DV camera over firewire

System:
Fresh install of Ubuntu 12.04 LTS
Motherboard: Intel DG33TL
DV Camera: Sony TRV-900
Firewire adapter: 06:03.0 FireWire (IEEE 1394): LSI Corporation FW322/323 (rev 70)

seems to be recognized OK:
[ 1.905253] firewire_ohci 0000:06:03.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
[ 1.960063] firewire_ohci: Added fw-ohci device 0000:06:03.0, OHCI v1.0, 8 IR + 8 IT contexts, quirks 0x0
[ 2.460101] firewire_core: created device fw0: GUID 0090270002069b55, S400

On plugging in the DV camera nothing happens in dmesg, no messages.
/dev/fw0 exists all the time, dv1394/raw1394/ieee1394 are not created at any stage

Camera shows 'DV IN' on the screen when the cable is connected and the cam is in VTR mode.

dvgrab tells me 'Error: no camera exists'

When disconnecting / switching of the camera, the following lines appear in dmesg:
[114691.393704] firewire_core: skipped bus generations, destroying all nodes
[114691.892030] firewire_core: rediscovered device fw0

People have reported that this both the adapter and the camera should work OK on Linux:
Adapter: http://hardware4linux.info/component/14298/
Camera: http://ubuntuforums.org/showthread.php?t=1188918 and http://www.digipedia.pl/usenet/thread/18793/3402/

I have found several 'Camera not recognized by Ubuntu' messages on both ubuntuforums and launchpad:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/670210
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/950879
http://ubuntuforums.org/showthread.php?t=1742787
http://ubuntuforums.org/showthread.php?t=1410418
http://ubuntuforums.org/showthread.php?t=784385
I have also had the same problem with different setup: Ubuntu 11.10, different adapter and camera..
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/670210/comments/30

That is the reason I decided to go for bugrep instead of asking what I'm doing wrong. I can't be sure it's not me or broken hardware but.. I'm happy to assist in triaging this with my HW and hope it'll help many others struggling with the cameras not recognized by Ubuntu / the new FW stack.

(and I was also suggested to report a new bug instead of adding stuff to an existing report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/670210/comments/38 )

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: linux-image-3.2.0-29-generic 3.2.0-29.46
ProcVersionSignature: Ubuntu 3.2.0-29.46-generic 3.2.24
Uname: Linux 3.2.0-29-generic x86_64
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
ApportVersion: 2.0.1-0ubuntu12
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: rhk 1434 F.... pulseaudio
CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211 not found.
Card0.Amixer.info:
 Card hw:0 'Intel'/'HDA Intel at 0xe0420000 irq 48'
   Mixer name : 'SigmaTel STAC9271D'
   Components : 'HDA:83847627,80864001,00100201'
   Controls : 43
   Simple ctrls : 24
Date: Sun Sep 2 19:51:44 2012
HibernationDevice: RESUME=UUID=8eab950b-57b9-4bbf-b136-c54be9cb17ff
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Release amd64 (20120425)
IwConfig:
 lo no wireless extensions.

 eth0 no wireless extensions.
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 LANG=fi_FI.UTF-8
 SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-29-generic root=UUID=80c96512-f57a-49f1-a46b-a6347e9441b7 ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.2.0-29-generic N/A
 linux-backports-modules-3.2.0-29-generic N/A
 linux-firmware 1.79
RfKill:

SourcePackage: linux
StagingDrivers: mei
UpgradeStatus: No upgrade log present (probably fresh install)
WifiSyslog:
 Sep 2 10:06:15 videoripa dhclient: DHCPREQUEST of 192.168.1.51 on eth0 to 192.168.1.1 port 67
 Sep 2 10:06:16 videoripa dhclient: DHCPACK of 192.168.1.51 from 192.168.1.1
 Sep 2 10:06:16 videoripa dhclient: bound to 192.168.1.51 -- renewal in 38620 seconds.
 Sep 2 19:51:36 videoripa kernel: [114691.393704] firewire_core: skipped bus generations, destroying all nodes
 Sep 2 19:51:36 videoripa kernel: [114691.892030] firewire_core: rediscovered device fw0
dmi.bios.date: 10/02/2007
dmi.bios.vendor: Intel Corp.
dmi.bios.version: DPP3510J.86A.0293.2007.1002.1519
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: DG33TL
dmi.board.vendor: Intel Corporation
dmi.board.version: AAD89517-803
dmi.chassis.type: 2
dmi.modalias: dmi:bvnIntelCorp.:bvrDPP3510J.86A.0293.2007.1002.1519:bd10/02/2007:svn:pn:pvr:rvnIntelCorporation:rnDG33TL:rvrAAD89517-803:cvn:ct2:cvr:

[Stefan Richter (stefan-r-ubz)]

As root, run
# echo -1 > /sys/module/firewire_ohci/parameters/debug
Then plug in/ switch on the camcorder. This should normally produce lots of output in dmesg. Please post the output here, if any.

[Risto H. Kurppa (risto.kurppa)]

Thanks Stefan!

Did that.

When connecting, I get these lines:
[159271.828275] firewire_ohci: IRQ 00000010 AR_req
[159271.828279] firewire_ohci: AR evt_bus_reset, generation 156
[159271.828778] firewire_ohci: IRQ 00000010 AR_req
[159271.828781] firewire_ohci: AR evt_bus_reset, generation 157
[159271.829278] firewire_ohci: IRQ 00000010 AR_req
[159271.829281] firewire_ohci: AR evt_bus_reset, generation 158

where 156..157..158 loop between 0(1?) and 255 very fast.

And after disconnecting I see this in dmesg:

[159271.830281] firewire_ohci: IRQ 00000010 AR_req
[159271.830284] firewire_ohci: AR evt_bus_reset, generation 160
[159271.830784] firewire_ohci: IRQ 00000010 AR_req
[159271.830787] firewire_ohci: AR evt_bus_reset, generation 161
[159271.831284] firewire_ohci: IRQ 00000010 AR_req
[159271.831287] firewire_ohci: AR evt_bus_reset, generation 162
[159271.831662] firewire_ohci: IRQ 00000010 AR_req
[159271.831665] firewire_ohci: AR evt_bus_reset, generation 163
[159271.831840] firewire_ohci: IRQ 00010000 selfID
[159271.831853] firewire_ohci: 1 selfIDs, generation 163, local node ID ffc0
[159271.831856] firewire_ohci: selfID 0: 807f8852, phy 0 [--.] S400 gc=63 +0W Lci
[159271.831859] firewire_core: skipped bus generations, destroying all nodes
[159272.328031] firewire_core: rediscovered device fw0
[159277.649992] firewire_ohci: IRQ 00200000 cycle64Seconds

Does this tell anything useful?

[Risto H. Kurppa (risto.kurppa)]

I noticed now that after disconnecting multiple lines like these start to appear in dmesg:
[159277.649992] firewire_ohci: IRQ 00200000 cycle64Seconds
[159341.650674] firewire_ohci: IRQ 00200000 cycle64Seconds
[159405.651352] firewire_ohci: IRQ 00200000 cycle64Seconds
[159469.652031] firewire_ohci: IRQ 00200000 cycle64Seconds

[penalvch (penalvch)]

Risto H. Kurppa, thank you for reporting this and helping make Ubuntu better. Could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the kernel in the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested and remove the tag:
needs-upstream-testing

This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the text:
needs-upstream-testing

If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested.

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested.

If you are unable to test the mainline kernel, please comment as to why specifically you were unable to test it and add the following tags:
kernel-unable-to-test-upstream
kernel-unable-to-test-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested.

Please let us know your results. Thank you for your understanding.

[Risto H. Kurppa (risto.kurppa)]

Thanks Christopher, did that.

Installed the following files
12256346 syys 3 11:19 linux-headers-3.6.0-999_3.6.0-999.201209030419_all.deb
894186 syys 3 11:26 linux-headers-3.6.0-999-generic_3.6.0-999.201209030419_amd64.deb
12260178 syys 3 11:25 linux-image-3.6.0-999-generic_3.6.0-999.201209030419_amd64.deb
24322806 syys 3 11:26 linux-image-extra-3.6.0-999-generic_3.6.0-999.201209030419_amd64.deb

root@videoripa:/home/rhk# uname -a
Linux videoripa 3.6.0-999-generic #201209030419 SMP Mon Sep 3 08:20:00 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

root@videoripa:/home/rhk# dmesg|tail
[ 1229.293862] firewire_ohci 0000:06:03.0: IRQ 00000010 AR_req
[ 1229.293866] firewire_ohci 0000:06:03.0: AR evt_bus_reset, generation 46
[ 1229.294039] firewire_ohci 0000:06:03.0: IRQ 00010000 selfID
[ 1229.294055] firewire_ohci 0000:06:03.0: 1 selfIDs, generation 46, local node ID ffc0
[ 1229.294058] firewire_ohci 0000:06:03.0: selfID 0: 807f8852, phy 0 [--.] S400 gc=63 +0W Lci
[ 1229.792029] firewire_core 0000:06:03.0: rediscovered device fw0
[ 1312.547251] firewire_core 0000:06:03.0: parent port inconsistency for node 0: parent_count=1
[ 1312.547256] firewire_core 0000:06:03.0: topology build failed
[ 1313.044029] firewire_core 0000:06:03.0: rediscovered device fw0
[ 1335.152030] firewire_core 0000:06:03.0: rediscovered device fw0
root@videoripa:/home/rhk#

New kernel doesn't seem to make a difference unless that parent port thing counts. However I only saw this parent port / topology message once when trying several times.

Dvgrab still can't see the camera.

[penalvch (penalvch)]

Risto H. Kurppa, thank you for testing the mainline kernel.

Did this problem not occur for you personally (not quoting from a forum or other source) in a Ubuntu release prior to Precise with the Sony TRV-900?

[Risto H. Kurppa (risto.kurppa)]

I haven't tried it with older installations but that's also an option if older images are still available and you feel it might be useful.

I'll download 10.04.3 first and try on USB live session what happens. If you think I should try also newer one, let me know.

[Risto H. Kurppa (risto.kurppa)]

To test the cable, I connected it between the desktop PC and a laptop.

DESKTOP machine (same HW as described above)
06:03.0 FireWire (IEEE 1394): LSI Corporation FW322/323 (rev 70) (6-pin)
ubuntu 12.04LTS
3.6.0-999-generic #201209030419 SMP Mon Sep 3 08:20:00 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Ran echo -1 > /sys/module/firewire_ohci/parameters/debug to get more messages to dmesg

This is what dmesg shows me when I connect and disconnect the cable twice:
[10732.425494] firewire_ohci 0000:06:03.0: IRQ 00000010 AR_req
[10732.425504] firewire_ohci 0000:06:03.0: AR evt_bus_reset, generation 122
[10732.860240] firewire_ohci 0000:06:03.0: IRQ 00000010 AR_req
[10732.860245] firewire_ohci 0000:06:03.0: AR evt_bus_reset, generation 123
[10732.860418] firewire_ohci 0000:06:03.0: IRQ 00010000 selfID
[10732.860434] firewire_ohci 0000:06:03.0: 1 selfIDs, generation 123, local node ID ffc0
[10732.860439] firewire_ohci 0000:06:03.0: selfID 0: 807f8852, phy 0 [--.] S400 gc=63 +0W Lci
[10733.360029] firewire_core 0000:06:03.0: rediscovered device fw0
[10769.817890] firewire_ohci 0000:06:03.0: IRQ 00000010 AR_req
[10769.817899] firewire_ohci 0000:06:03.0: AR evt_bus_reset, generation 124
[10770.254637] firewire_ohci 0000:06:03.0: IRQ 00000010 AR_req
[10770.254643] firewire_ohci 0000:06:03.0: AR evt_bus_reset, generation 125
[10770.254813] firewire_ohci 0000:06:03.0: IRQ 00010000 selfID
[10770.254828] firewire_ohci 0000:06:03.0: 1 selfIDs, generation 125, local node ID ffc0
[10770.254832] firewire_ohci 0000:06:03.0: selfID 0: 807f8852, phy 0 [--.] S400 gc=63 +0W Lci
[10770.752032] firewire_core 0000:06:03.0: rediscovered device fw0

On connection it printed 8 lines but nothing on disconnection.

LAPTOP
03:09.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (4-pin)
Ubuntu 12.04LTS
3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 17:49:24 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Ran echo -1 > /sys/module/firewire_ohci/parameters/debug to get more messages to dmesg

On connecting the cable, no messages were shown in dmesg.

However after disconnecting, lines like these start appearing:
[ 1036.782522] firewire_ohci: IRQ 00200000 cycle64Seconds
[ 1100.782153] firewire_ohci: IRQ 00200000 cycle64Seconds
[ 1164.781775] firewire_ohci: IRQ 00200000 cycle64Seconds
[ 1228.781389] firewire_ohci: IRQ 00200000 cycle64Seconds
[ 1292.781019] firewire_ohci: IRQ 00200000 cycle64Seconds

The cable I use is a 4-to-6 pin one. I can't test the camera on the laptop, for that I'd need a 4-to-4 pin one I currently don't have available.

Will proceed to test Ubuntu 10.04.3 live.

[Risto H. Kurppa (risto.kurppa)]

Forgot that I haven't found a way to boot from USB on the desktop machine (and can't understand it - doesn't it really support it or can't I just figure out what to press..)

Anyway I booted the laptop with 10.04.3 64-bit live image and ran the same test as above, connecting the 12.04 desktop (6-pin) and 10.04.3 laptop (4-pin).

No messages on laptop, nothing.

On desktop I again saw this:
[ 340.358583] firewire_ohci 0000:06:03.0: IRQ 00000010 AR_req
[ 340.358592] firewire_ohci 0000:06:03.0: AR evt_bus_reset, generation 4
[ 340.795969] firewire_ohci 0000:06:03.0: IRQ 00000010 AR_req
[ 340.795974] firewire_ohci 0000:06:03.0: AR evt_bus_reset, generation 5
[ 340.796147] firewire_ohci 0000:06:03.0: IRQ 00010000 selfID
[ 340.796163] firewire_ohci 0000:06:03.0: 1 selfIDs, generation 5, local node ID ffc0
[ 340.796167] firewire_ohci 0000:06:03.0: selfID 0: 807f8852, phy 0 [--.] S400 gc=63 +0W Lci
[ 341.296029] firewire_core 0000:06:03.0: rediscovered device fw0

Please tell me which of the earlier Ubuntu versions You want me to try, I'll burn a CD.

[Stefan Richter (stefan-r-ubz)]

The cycle64Seconds interrupt is a regular interrupt caused by a timer of the FireWire chip. It is normal and intended (in this version of the kernel; kernel 3.6 does not enable this interrupt unless an application requests a certain register which depends on that timer).

The bus reset loop in comment 3, i.e. the cycling endlessly through generations 0...255 while the camcorder is connected, is indicating a problem low at the physical layer. Since we are talking about a camcorder from 1998 which implements IEEE 1394:1995 but not the amendment IEEE 1394a:2000, I first suspected that maybe the recent kernel drivers enable 1394a:2000 physical layer features too optimistically, so that the camcorder PHY is throwing a fit.

However, seeing that a connection between PC and laptop does not succeed either, the most likely cause is rather a hardware defect of the cable or of the PC's card or (less likely) of the laptop's port.

Here is how a successful bus reset with two nodes on the bus should look like, with firewire-ohci debug parameter set to 2:
Sep 3 22:34:39 stein kernel: firewire_ohci 0000:0a:00.0: 2 selfIDs, generation 151, local node ID ffc1
Sep 3 22:34:39 stein kernel: firewire_ohci 0000:0a:00.0: selfID 0: 807fc494, phy 0 [p--] beta gc=63 -3W L
Sep 3 22:34:39 stein kernel: firewire_ohci 0000:0a:00.0: selfID 0: 817f8972, phy 1 [-c.] S400 gc=63 +15W Lci
(After this hardware-triggered bus reset with self-ID-complete event, one or a few more software-triggered bus resets and self-ID-complete events may follow when firewire-core or a remote node's firmware or system software reconfigures the bus or starts up the node's higher functions.)

So the absence of a second self-identification packet on the PC and the absence of any interrupt at all on the laptop --- which both have 1394a:2000 compliant PHYs which are known to work with current Linux drivers --- show that defective hardware (e.g. the cable) is much more likely to be the culprit here than the drivers.

If you try an older Ubuntu, best would be one which still has the ieee1394/ ohci1394/ raw1394 kernel drivers, i.e. with kernel 2.6.36 or older. I don't remember when these were removed from Ubuntu; distrowatch.com says at least that Ubuntu 10.10 had kernel 2.6.35.

[Risto H. Kurppa (risto.kurppa)]

Thanks Stefan!

Bought a new 4-to-6 FW cable.

Desktop - to TRV-900

On connection the bus reset loop starts running, nothing else
On disconnection I got this:

[ 379.757580] firewire_ohci 0000:06:03.0: AR evt_bus_reset, generation 240
[ 379.758079] firewire_ohci 0000:06:03.0: IRQ 00000010 AR_req
[ 379.758083] firewire_ohci 0000:06:03.0: AR evt_bus_reset, generation 241
[ 379.758579] firewire_ohci 0000:06:03.0: IRQ 00000010 AR_req
[ 379.758583] firewire_ohci 0000:06:03.0: AR evt_bus_reset, generation 242
[ 379.759028] firewire_ohci 0000:06:03.0: IRQ 00010000 selfID
[ 379.759045] firewire_ohci 0000:06:03.0: 1 selfIDs, generation 242, local node ID ffc0
[ 379.759049] firewire_ohci 0000:06:03.0: selfID 0: 807f8892, phy 0 [p-.] S400 gc=63 +0W Lci
[ 379.759055] firewire_core 0000:06:03.0: parent port inconsistency for node 0: parent_count=1
[ 379.759059] firewire_core 0000:06:03.0: topology build failed
[ 379.759137] firewire_ohci 0000:06:03.0: IRQ 00000010 AR_req
[ 379.759141] firewire_ohci 0000:06:03.0: AR evt_bus_reset, generation 243
[ 379.759315] firewire_ohci 0000:06:03.0: IRQ 00010000 selfID
[ 379.759327] firewire_ohci 0000:06:03.0: 1 selfIDs, generation 243, local node ID ffc0
[ 379.759330] firewire_ohci 0000:06:03.0: selfID 0: 807f8852, phy 0 [--.] S400 gc=63 +0W Lci
[ 380.256036] firewire_core 0000:06:03.0: rediscovered device fw0

Desktop to laptop, both runnint Ubuntu 12.04:

This is what desktop gave on connection:
[ 688.643976] firewire_ohci 0000:06:03.0: IRQ 00000010 AR_req
[ 688.643985] firewire_ohci 0000:06:03.0: AR evt_bus_reset, generation 244
[ 689.082176] firewire_ohci 0000:06:03.0: IRQ 00000010 AR_req
[ 689.082181] firewire_ohci 0000:06:03.0: AR evt_bus_reset, generation 245
[ 689.082353] firewire_ohci 0000:06:03.0: IRQ 00010000 selfID
[ 689.082370] firewire_ohci 0000:06:03.0: 1 selfIDs, generation 245, local node ID ffc0
[ 689.082374] firewire_ohci 0000:06:03.0: selfID 0: 807f8852, phy 0 [--.] S400 gc=63 +0W Lci
[ 689.580029] firewire_core 0000:06:03.0: rediscovered device fw0

Nothing on laptop.

I suppose this points to defect HW? Propably the (integrated) adapter on the desktop?
How easy are these things to break?

Will try older Ubuntu later.

[Stefan Richter (stefan-r-ubz)]

> I suppose this points to defect HW?

Yes.

> How easy are these things to break?

Ports which adhere to the old IEEE 1394:1995 specification are electrically more prone to damage during hotplugging than later 1394a:2000 hardware. And the 4-pin iLink ports are mechanically not very reliable. Damaged 6-pin 1394a ports or 9-pin 1394b ports on the other hand are not very common but do occasionally happen.

> Will try older Ubuntu later.

If you have the opportunity, please do so. A driver regression is unlikely to be the cause of this problem but it would be good if you could test with older firewire-ohci + firewire-core kernel drivers, or ideally with the ohci1394 + ieee1394 + raw1394 kernel drivers of kernel 2.6.36 or older to be sure.

[Risto H. Kurppa (risto.kurppa)]

Tried again on Ubuntu 10.04 LIVE CD
Same HW.

ubuntu@ubuntu:~$ uname -a
Linux ubuntu 2.6.32-33-generic #70-Ubuntu SMP Thu Jul 7 21:13:52 UTC 2011 x86_64 GNU/Linux

ubuntu@ubuntu:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 10.04.3 LTS
Release: 10.04
Codename: lucid

ubuntu@ubuntu:~$ lspci|grep FireWire
06:03.0 FireWire (IEEE 1394): Agere Systems FW322/323 (rev 70)

(The adapter is recognized with different name in more recent versions of Ubuntu)

dmesg recognition
[ 4.127940] ohci1394 0000:06:03.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
...
[ 4.183290] ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[19] MMIO=[e0000000-e00007ff] Max Packet=[2048] IR/IT contexts=[8/8]
[ 4.186208] alloc irq_desc for 30 on node -1
[ 4.186214] alloc kstat_irqs on node -1
[ 4.186224] i915 0000:00:02.0: irq 30 for MSI/MSI-X
...
[ 5.512735] ieee1394: Host added: ID:BUS[0-00:1023] GUID[0090270002069b55]

On connecting the camera nothing shows up in dmesg and no new devices in /dev
dvgrab shows 'Error: no camera exists'

However the camera shows 'DV IN' so at some level it recognizes the connection.

Can you confirm that this points to HW problems in the camera?

It's just kind of hard to believe that I've broken 2 cameras more or less the same way when trying to connect them to Linux, after they've been used for years on Windows environments. I might be able to test the camera with another computer at some point.

[Stefan Richter (stefan-r-ubz)]

Thank you very much for testing with the old drivers. The fact that nothing gets added to dmesg at the time when the camera is plugged in shows that the older drivers do not recognize the camera either, fully or partially.

But could you please run "grep . /sys/bus/ieee1394/devices/*/*" before and after you connected the (switched-on) camcorder? There is for example a file in there with a node count, which would normally be 1 before a device gets added and 2 after successful addition of a device.

/dev/* files won't be added by the old drivers regardless whether devices are detected or not. But after "modprobe raw1394" as root, a /dev/raw1394 is created. Temporarily give your user permission to read and write this file, e.g. "chmod a+rw /dev/raw1394", again ran as root user. Then retry dvgrab.

[Risto H. Kurppa (risto.kurppa)]

Thanks Stefan for your contribution!

Before connection:
ubuntu@ubuntu:~$ grep . /sys/bus/ieee1394/devices/*/*
/sys/bus/ieee1394/devices/0090270002069b55/bus_options:IRMC(1) CMC(1) ISC(1) BMC(0) PMC(0) GEN(3) LSPD(2) MAX_REC(2048) MAX_ROM(2) CYC_CLK_ACC(100)
/sys/bus/ieee1394/devices/0090270002069b55/capabilities:0x0083c0
/sys/bus/ieee1394/devices/0090270002069b55/guid:0x0090270002069b55
/sys/bus/ieee1394/devices/0090270002069b55/guid_vendor_id:0x009027
/sys/bus/ieee1394/devices/0090270002069b55/nodeid:0xffc0
/sys/bus/ieee1394/devices/0090270002069b55/vendor_id:0x009027
/sys/bus/ieee1394/devices/0090270002069b55/vendor_name_kv:Linux - ohci1394
/sys/bus/ieee1394/devices/fw-host0/in_bus_reset:0
/sys/bus/ieee1394/devices/fw-host0/is_busmgr:0
/sys/bus/ieee1394/devices/fw-host0/is_cycmst:1
/sys/bus/ieee1394/devices/fw-host0/is_irm:1
/sys/bus/ieee1394/devices/fw-host0/is_root:1
/sys/bus/ieee1394/devices/fw-host0/node_count:1
/sys/bus/ieee1394/devices/fw-host0/nodes_active:1
/sys/bus/ieee1394/devices/fw-host0/selfid_count:1
/sys/bus/ieee1394/devices/fw-host0/uevent:DRIVER=nodemgr

After connection:
ubuntu@ubuntu:~$ grep . /sys/bus/ieee1394/devices/*/*
/sys/bus/ieee1394/devices/0090270002069b55/bus_options:IRMC(1) CMC(1) ISC(1) BMC(0) PMC(0) GEN(3) LSPD(2) MAX_REC(2048) MAX_ROM(2) CYC_CLK_ACC(100)
/sys/bus/ieee1394/devices/0090270002069b55/capabilities:0x0083c0
/sys/bus/ieee1394/devices/0090270002069b55/guid:0x0090270002069b55
/sys/bus/ieee1394/devices/0090270002069b55/guid_vendor_id:0x009027
/sys/bus/ieee1394/devices/0090270002069b55/nodeid:0xffc0
/sys/bus/ieee1394/devices/0090270002069b55/vendor_id:0x009027
/sys/bus/ieee1394/devices/0090270002069b55/vendor_name_kv:Linux - ohci1394
/sys/bus/ieee1394/devices/fw-host0/in_bus_reset:1
/sys/bus/ieee1394/devices/fw-host0/is_busmgr:0
/sys/bus/ieee1394/devices/fw-host0/is_cycmst:0
/sys/bus/ieee1394/devices/fw-host0/is_irm:0
/sys/bus/ieee1394/devices/fw-host0/is_root:1
/sys/bus/ieee1394/devices/fw-host0/node_count:0
/sys/bus/ieee1394/devices/fw-host0/nodes_active:1
/sys/bus/ieee1394/devices/fw-host0/selfid_count:0
/sys/bus/ieee1394/devices/fw-host0/uevent:DRIVER=nodemgr
ubuntu@ubuntu:~$

camera switched off, cable connected but output is identical to the one shown when cable disconnected.

ubuntu@ubuntu:~$ grep . /sys/bus/ieee1394/devices/*/*
/sys/bus/ieee1394/devices/0090270002069b55/bus_options:IRMC(1) CMC(1) ISC(1) BMC(0) PMC(0) GEN(3) LSPD(2) MAX_REC(2048) MAX_ROM(2) CYC_CLK_ACC(100)
/sys/bus/ieee1394/devices/0090270002069b55/capabilities:0x0083c0
/sys/bus/ieee1394/devices/0090270002069b55/guid:0x0090270002069b55
/sys/bus/ieee1394/devices/0090270002069b55/guid_vendor_id:0x009027
/sys/bus/ieee1394/devices/0090270002069b55/nodeid:0xffc0
/sys/bus/ieee1394/devices/0090270002069b55/vendor_id:0x009027
/sys/bus/ieee1394/devices/0090270002069b55/vendor_name_kv:Linux - ohci1394
/sys/bus/ieee1394/devices/fw-host0/in_bus_reset:0
/sys/bus/ieee1394/devices/fw-host0/is_busmgr:0
/sys/bus/ieee1394/devices/fw-host0/is_cycmst:1
/sys/bus/ieee1394/devices/fw-host0/is_irm:1
/sys/bus/ieee1394/devices/fw-host0/is_root:1
/sys/bus/ieee1394/devices/fw-host0/node_count:1
/sys/bus/ieee1394/devices/fw-host0/nodes_active:1
/sys/bus...

[Stefan Richter (stefan-r-ubz)]

> Before connection:
[...]
> /sys/bus/ieee1394/devices/fw-host0/in_bus_reset:0
[...]
> /sys/bus/ieee1394/devices/fw-host0/node_count:1

Good.

> After connection:
[...]
> /sys/bus/ieee1394/devices/fw-host0/in_bus_reset:1
[...]
> /sys/bus/ieee1394/devices/fw-host0/node_count:0

Bad, as this should become 0 and 2 respectively. This is consistent with what you got with the newer kernel: While the camera is connected (and switched on), the bus is permanently reset and never finishes a reset successfully with a self-ID-complete event, after which it would become usable for system software.

This and the fact that you already replaced the cable and also tested a PC-to-laptop connection unsuccessfully leaves pretty much only the conclusion that the port (or the ports) on your FW322/323 based board are dead.

[Stefan Richter (stefan-r-ubz)]

PS,
since the kernel never gets a chance to go from in_bus_reset:1 back to in_bus_reset:0 while the camera is on, the kernel cannot transmit and receive on the bus, and hence dvgrab cannot do anything either.

[Risto H. Kurppa (risto.kurppa)]

"This and the fact that you already replaced the cable and also tested a PC-to-laptop connection unsuccessfully leaves pretty much only the conclusion that the port (or the ports) on your FW322/323 based board are dead."

I'm very glad to hear this - the adapter is much cheaper to replace than fix the camera :)

Thanks, will now try to find 4-to-4-pin cable to test the same stuff on laptop. Will close the bug now. Thanks Stefan!

[Risto H. Kurppa (risto.kurppa)]

Problems caused by defect HW, not drivers.