Bug 477279 - Problem with with VTR controls on Firewire camcorder
Problem with with VTR controls on Firewire camcorder
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
9
All Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-19 19:35 EST by Vic Ricker
Modified: 2009-06-03 04:03 EDT (History)
5 users (show)

See Also:
Fixed In Version: 2.6.27.24-170.2.68.fc10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-03 04:03:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Vic Ricker 2008-12-19 19:35:05 EST
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.
Comment 1 Stefan Richter 2009-01-19 14:47:32 EST
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.
Comment 2 Stefan Richter 2009-01-20 15:21:16 EST
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
Comment 3 Stefan Richter 2009-02-07 07:37:59 EST
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?
Comment 4 Stefan Richter 2009-02-12 13:57:48 EST
The patch from comment 2 is available in upstream released kernels 2.6.29-rc4, 2.6.28.5, and 2.6.27.16.
Comment 5 Chuck Ebbert 2009-02-27 03:48:56 EST
kernel-2.6.27.19-78.2.30.fc9 is in updates-testing with the fix
Comment 6 Keith Bellairs 2009-05-30 16:37:24 EDT
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@xenbuilder2.fedora.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@x86-4.fedora.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

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