Re: sorta solved: "AVC Status: Unknown state" on recent kernels

On Oct 30 Michael Shigorin wrote:
> On Sun, Oct 30, 2011 at 07:38:52PM +0100, Stefan Richter wrote:
> > > just for the record: kino-1.3.4 rebuilt against libdc1394 at
> > Don't you mean libraw1394 or libacv1394?  And if it is
> > libraw1394, which exact version are you using now?
> 
> I meant libdc1394-22-2.1.2 (just updated the package to 2.1.3
> as well) -- went over Debian package diff looking what could
> differ.  But guess they rather looked at ffmpeg/ for that matter,
> upon having a closer look.

Oh, right --- ffmpeg (libavformat?) on your system is linked against
libdc1394 for an IIDC input module I suppose.  So this was just the build;
kino itself does not use the IEEE 1394 I/O modules of libavformat; at
runtime it uses libraw1394 (via libiec61883, libavc1394, librom1394) for
that.

> It's Canon MVX-25i;

Reviews on the web indicate that this is a model from 2004.  I have got a
Canon MV5i MC which appears to be a model from 2002.

Now that you brought this up, I tried AV/C tape control on this camcorder
possibly for the first time.  While I can start playback with a bit of
luck and stop it, kino is then seemingly unable to get it to rewind the
tape.  Ditto with "dvgrab -i".  All in all it looks very similar to what
you describe.

Oh, and gscanbus dies with a segfault when I click on the camcorder icon
in order to bring up the window with node information and tape control.

(I don't use my three camcorders for anything real, just as test specimen
for the FireWire drivers.  Most of the time I merely tested DV capture in
camera mode.  Tape control does work however with my newer JVC camcorder
and older Panasonic camcorder.)

> dmesg:
> 
> [  210.747460] firewire_core: skipped bus generations, destroying all nodes
> [  211.244078] firewire_core: rediscovered device fw1
> [  211.244090] firewire_core: giving up on config rom for node id ffc0
> [  214.383938] firewire_core: skipped bus generations, destroying all nodes
> [  214.880083] firewire_core: rediscovered device fw1
> [  214.880101] firewire_core: phy config: card 1, new root=ffc1, gap_count=5
> [  219.907652] firewire_core: created device fw2: GUID 0000850000XXXXXX, S100, 1 config ROM retries

This is how it looks here when I switch the camcorder from off into play
mode after it had been plugged in earlier:

Oct 31 12:17:14 stein kernel: firewire_core: phy config: card 1, new root=ffc1, gap_count=5
Oct 31 12:17:15 stein kernel: firewire_core: giving up on config rom for node id ffc0
Oct 31 12:17:18 stein kernel: firewire_core: skipped bus generations, destroying all nodes
Oct 31 12:17:18 stein kernel: firewire_ohci: isochronous cycle inconsistent
Oct 31 12:17:18 stein kernel: firewire_core: rediscovered device fw1
Oct 31 12:17:18 stein kernel: firewire_core: created device fw9: GUID 00008500005c16a7, S100
Oct 31 12:17:18 stein kernel: firewire_core: phy config: card 1, new root=ffc1, gap_count=5

So that looks pretty standard for this sort of device.  On one out of six
occasions I had "created device fw9: GUID 00008500005c16a7, S100, 1 config
ROM retries" like yours.

> > On October 22, I pushed an update to
> > git://git.user.in-berlin.de/s5r6/libraw1394.git which improves
> > reliability of AV/C control and status polling with some old
> > Panasonic and Grundig camcorder models.
> > https://redmine.user.in-berlin.de/projects/libraw1394/repository/revisions/8e433bf58413725365654c27fb4fad0aad88b516
> 
> Thanks; is it going to be released relatively soon or should
> build the patched package in the meantime?

While I haven't tried tape control of MV5i with that recent libraw1394
change reverted, the fact alone that I apparently can reproduce your issue
indicates that this issue is independent of the post 2.0.7 changes in
libraw1394.

Said said, I suppose I should tag a new release sometime soon.  But before
that, I still want to look into some old issue reports and old proposed
patches and commit the low-hanging fruit (if there are ones among them).
Also I need to see whether I can reinstate the libraw1394 repository and
tarball http/ftp download directory at kernel.org (a) in a reasonable time
frame and (b) at the very same URLs as before the kernel.org compromise and
downtime.

> The camera *is* showing up in dmesg and /dev/fw* gets there,
> kino status line is "AV/C enabled" but the control buttons
> get weird -- I can try to elaborate on the description
> (probably with a screen video) or dvgrab it if that helps;
> the camera will travel again for something like a week since
> tomorrow but likely to settle at home after that.
> 
> The rewind was essentially not working at all yesterday,
> today's fiddling with package rebuilds (the kino binary package
> and corresponding libs were built a year ago or so and might
> have missed kernel header changes) made rewind sort of work.
> Actual capture was working after on-camera "rewind" button
> and in-kino "record" button, thus the job was done. :)

OK, so you and I can look into that independently.  For example,
firewire-ohci's debug logging might perhaps show something interesting
(echo 3 > /sys/module/firewire_ohci/parameters/debug).

Or maybe it is the same problem that Dan recently noted on linux1394-devel
about an older JVC camcorder:  The rather frequent status polling that
both kino and dvgrab perform, as well as the requesting of status right
before issuing a control command, confuses the camcorder.  Dan found that
even delays in the order of hundreds of milliseconds between status poll
and control request don't help, but removing this polling entirely in the
application code did.

> Is the "giving up on config rom" appearing above the definite
> sign of the problem described in aaff120?  That is, what's up
> with that message followed by kino being able to capture?

In this case it is only a temporary glitch:  The camcorder signals by its
self-identification packet that its link layer is ready, so the kernel
begins to probe it; but in fact isn't ready.  When the camcorder brought
everything up for real three seconds later, it issues another bus reset
and the kernel succeeds to probe the camcorder's config ROM now, evident
by the "created device" message and /dev/fw* showing up in the filesystem.
--

-- 
Stefan Richter
-=====-==-== =-=- =====
http://arcgraph.de/sr/

------------------------------------------------------------------------------
Get your Android app more play: Bring it to the BlackBerry PlayBook 
in minutes. BlackBerry App World™ now supports Android™ Apps 
for the BlackBerry® PlayBook™. Discover just how easy and simple 
it is! http://p.sf.net/sfu/android-dev2dev