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

On Mon, Oct 31, 2011 at 5:47 AM, Michael Shigorin <[email protected]> wrote:
> PreScriptum: is it acceptable on kino-dev@ or should I subscribe
> to another ML? (what's lucky for me might be spam for others as
> the issue at hand doesn't relate to kino as has been shown)

It is fine. Regarding the polling interval, you can change it in
~/.kinorc:avcPollIntervalMs, which is in milliseconds. Try with 2000.

>
> On Mon, Oct 31, 2011 at 01:05:16PM +0100, Stefan Richter wrote:
>> > It's Canon MVX-25i;
>> Reviews on the web indicate that this is a model from 2004. =A0I
>> have got a Canon MV5i MC which appears to be a model from 2002.
> [...]
>> All in all it looks very similar to what you describe.
>
> Yup; well at least there's the locally reproducible case.
>
>> > dmesg:
>> 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.
>
> Hm, this one seems to differ:
>
> $ dmesg | grep firewire
> [ =A0 =A07.822220] firewire_ohci 0000:01:07.0: PCI INT A -> Link[APC2] ->=
 GSI 17 (level, low) -> IRQ 17
> [ =A0 =A07.884112] firewire_ohci: Added fw-ohci device 0000:01:07.0, OHCI=
 v1.0, 4 IR + 8 IT contexts, quirks 0x11
> [ =A0 =A07.884359] firewire_ohci 0000:01:0e.0: PCI INT A -> Link[APC3] ->=
 GSI 18 (level, low) -> IRQ 18
> [ =A0 =A07.940124] firewire_ohci: Added fw-ohci device 0000:01:0e.0, OHCI=
 v1.10, 4 IR + 8 IT contexts, quirks 0x2
> [ =A0 =A08.384212] firewire_core: created device fw0: GUID 4d5a9000030000=
00, S400
> [ =A0 =A08.440203] firewire_core: created device fw1: GUID 000fea000060c6=
e6, S400
> [ =A0210.747460] firewire_core: skipped bus generations, destroying all n=
odes
> [ =A0211.244078] firewire_core: rediscovered device fw1
> [ =A0211.244090] firewire_core: giving up on config rom for node id ffc0
> [ =A0214.383938] firewire_core: skipped bus generations, destroying all n=
odes
> [ =A0214.880083] firewire_core: rediscovered device fw1
> [ =A0214.880101] firewire_core: phy config: card 1, new root=3Dffc1, gap_=
count=3D5
> [ =A0219.907652] firewire_core: created device fw2: GUID 0000850000a1eb41=
, S100, 1 config ROM retries
> [ 2880.652123] firewire_core: skipped bus generations, destroying all nod=
es
> [ 2881.152093] firewire_core: rediscovered device fw1
> [ 2881.152116] firewire_core: giving up on config rom for node id ffc1
> [ 2884.290444] firewire_core: skipped bus generations, destroying all nod=
es
> [ 2884.788047] firewire_core: rediscovered device fw1
> [ 2884.788063] firewire_core: phy config: card 1, new root=3Dffc1, gap_co=
unt=3D5
> [ 2889.819376] firewire_core: created device fw2: GUID 0000850000a1eb41, =
S100, 1 config ROM retries
> [ 5006.824883] firewire_core: skipped bus generations, destroying all nod=
es
> [ 5007.324110] firewire_core: rediscovered device fw1
> [ 5007.324132] firewire_core: giving up on config rom for node id ffc1
>
>> 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).
>
> Of course! =A0Postponing the known things for the chance to
> bundle not-quite-diagnosed problem fixes isn't that effective,
> and I'm more than willing to test git builds.
>
>> 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.
>
> Seems like it's a "not-quite-predictable" thing so far.
>
>> OK, so you and I can look into that independently. =A0For example,
>> firewire-ohci's debug logging might perhaps show something interesting
>> (echo 3 > /sys/module/firewire_ohci/parameters/debug).
>
> Thanks, I'll try to get back to this as the hardware's back.
>
>> > Is the "giving up on config rom" appearing above the definite
>> > sign of the problem described in aaff120? =A0That is, what's up
>> > with that message followed by kino being able to capture?
>> In this case it is only a temporary glitch: =A0The 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. =A0When 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.
>
> Thank you for the explanation. =A0I used to solder my own stuff
> some twenty years ago but that was purely analog one...
>
> --
> =A0---- WBR, Michael Shigorin <[email protected]>
> =A0------ Linux.Kiev http://www.linux.kiev.ua/
>
> -------------------------------------------------------------------------=
-----
> Get your Android app more play: Bring it to the BlackBerry PlayBook
> in minutes. BlackBerry App World&#153; now supports Android&#153; Apps
> for the BlackBerry&reg; PlayBook&#153;. Discover just how easy and simple
> it is! http://p.sf.net/sfu/android-dev2dev
> _______________________________________________
> Kino-dev mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/kino-dev
>



-- =

+-DRD-+

---------------------------------------------------------------------------=
---
Get your Android app more play: Bring it to the BlackBerry PlayBook =

in minutes. BlackBerry App World&#153; now supports Android&#153; Apps =

for the BlackBerry&reg; PlayBook&#153;. Discover just how easy and simple =

it is! http://p.sf.net/sfu/android-dev2dev