My Panasonic PV-DV401 Mini DV camcorder is not recognized by dvgrab or kino. Originally, I thought the problem was related to bug 415841 but I tried connecting the camera to a machine with a TI chipset and got the same results. When I plug the camera in, the kernel detects it and creates a /dev/fw* entry for it. Dec 19 18:20:15 nightmare kernel: firewire_core: created device fw2: GUID 00804580b0c6e001, S100 Dec 19 18:20:15 nightmare kernel: firewire_core: phy config: card 1, new root=ffc1, gap_count=5 dvgrab fails with: [root@nightmare dev]# dvgrab -guid 00804580b0c6e001 libiec61883 warning: iec61883_cmp_create_p2p_output: Failed to set the oPCR[0] plug for node 1. Established connection over channel 63 send oops send oops send oops send oops "" 0.00 MiB 0 frames Capture Stopped Error: no DV Up until today, kino did not even list the camera under AV/C devices. Today it shows in the list but the camera does not respond to the controls at all. In the terminal, I see: rom1394_1 warning: read failed: 0x0000fffff000040c rom1394_1 warning: read failed: 0x0000fffff0000410 >> Leaving Editor >> Left Editor >> Starting Editor >> Leaving Editor >> Left Editor >> Starting Capture >> AV/C Enabled >>> Using iec61883 capture send oops send oops send oops send oops send oops send oops send oops send oops send oops send oops send oops send oops send oops rom1394_1 warning: read failed: 0x0000fffff000040c rom1394_1 warning: read failed: 0x0000fffff0000410 >>> iec61883Reader::StartThread on port 1 send oops >>> AVC enabled >> Constructing File Capture tracker send oops It continually prints "send oops" at this point. I am doing everything as root and have selinux disabled. I have also tried the dvgrab under the fedora 10 live CD with the same results. I just noticed something while testing. I CAN capture video with kino. It appears that only the VTR contols are not working. If I press "Capture", then press "Play" on the camera, kino is able to capture the video. I have used this camera under linux before and it worked fine but that was a long time ago, probably under Fedora 5 or 6.
So isochronous IO works while asynchronous IO fails (often, but not always: initial async IO from firewire-core works, otherwise /dev/fw1 wouldn't be created). The same symptoms have been reported against a recent kernel with the old ieee1394 drivers: https://sourceforge.net/tracker/index.php?func=detail&aid=2492640&group_id=14103&atid=114103 Does "dvgrab -noavc" behave better? Also, please gather some info about the kind of IO failures. - Unplug the camcorder - As root, run "echo 3 > /sys/module/firewire_ohci/parameters/debug". - Plug the camera in and switch it on. - Run dvgrab. - Get the syslog and attach the relevant portions here, beginning from when you plugged the camera in. The log should contain lines like Jan 19 20:38:18 stein firewire_ohci: AR evt_bus_reset, generation 6 Jan 19 20:38:18 stein firewire_ohci: 2 selfIDs, generation 6, local node ID ffc1 Jan 19 20:38:18 stein firewire_ohci: selfID 0: 807f0882, phy 0 [p..] S100 gc=63 +0W Lci Jan 19 20:38:18 stein firewire_ohci: selfID 0: 817f89d0, phy 1 [c-.] S400 gc=63 +15W Lc ... Jan 19 20:38:18 stein firewire_ohci: AT spd 0 tl 1d, ffc1 -> ffc0, ack_pending , QR req, fffff0000400 Jan 19 20:38:18 stein firewire_ohci: AR spd 0 tl 1d, ffc0 -> ffc1, ack_complete, QR resp = 040455ee ... etc. when the firewire-core discovers the camera, and Jan 19 20:41:34 stein firewire_ohci: AT spd 0 tl 13, ffc1 -> ffc0, ack_pending , QR req, fffff0000414 Jan 19 20:41:34 stein firewire_ohci: AR spd 0 tl 13, ffc0 -> ffc1, ack_complete, QR resp = 000897bd ... etc. when dvgrab starts probing at the camera, Jan 19 20:41:34 stein firewire_ohci: AT spd 0 tl 03, ffc1 -> ffc0, ack_complete, BW req, fffff0000b00 8,0 Jan 19 20:41:34 stein firewire_ohci: AR spd 0 tl 03, ffc0 -> ffc1, ack_pending , BW req, fffff0000d00 8,0 Jan 19 20:41:34 stein firewire_ohci: AT spd 0 tl 03, ffc1 -> ffc0, ack_complete, W resp Jan 19 20:41:34 stein firewire_ohci: AT spd 0 tl 04, ffc1 -> ffc0, ack_busy_X, BW req, fffff0000b00 8,0 Jan 19 20:41:34 stein firewire_ohci: AT spd 0 tl 05, ffc1 -> ffc0, ack_complete, BW req, fffff0000b00 8,0 Jan 19 20:41:34 stein firewire_ohci: AR spd 0 tl 05, ffc0 -> ffc1, ack_pending , BW req, fffff0000d00 8,0 Jan 19 20:41:34 stein firewire_ohci: AT spd 0 tl 05, ffc1 -> ffc0, ack_complete, W resp ... etc. when dvgrab starts capture. As you can see in the last few lines (gathered from a cheap JVC camcorder), sometimes a request from PC (ffc1) to camera (ffc0) fails due to the camera being busy (ack_busy_X). The software then tries the same request again which happens to succeed in my example.
I guess this is the same as bug 449252. As I just noted there, a fix has been proposed: http://marc.info/?l=linux1394-devel&m=123247509617629
Patch was merged into Linus' linux-2.6.git a week ago, mailed to kernel.org's stable list just now. Jarod, is there a Fedora kernel with patch "firewire: ohci: increase AT req. retries, fix ack_busy_X from Panasonic camcorders and others" included? Vic, does it fix this issue for you?
The patch from comment 2 is available in upstream released kernels 2.6.29-rc4, 2.6.28.5, and 2.6.27.16.
kernel-2.6.27.19-78.2.30.fc9 is in updates-testing with the fix
The problem is now fixed in f10 (not by me, of course). I had the same bug with a Canon ZR900 in Linux version 2.6.27.21-170.2.56.fc10.i686 (mockbuild.redhat.com) (gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC) ) #1 SMP Mon Mar 23 23:37:54 EDT 2009 but it is resolved in Linux version 2.6.27.24-170.2.68.fc10.i686 (mockbuild.phx.redhat.com) (gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC) ) #1 SMP Wed May 20 23:10:16 EDT 2009