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

Stefan Richter <[email protected]> Mon, 31 Oct 2011 17:22:35 +0100
Newsgroups gmane.comp.video.kino.devel
Message-ID <20111031172235.63d7df65@stein>
On Oct 31 Michael Shigorin 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)

I think we are still on-topic.  In the end it might even turn out to be
something that calls for changes in kino and dvgrab proper.

For lower-level or more generic discussions there are of course also
[email protected] and [email protected] (subscription
interface at https://sourceforge.net/mail/?group_id=2252).  These lists
are open for postings by non-subscribers, and just like on the
linux-kernel mailinglist it is unwritten etiquette that responders use
reply-to-all, so that non-subscribers can fully participate.

> Hm, this one seems to differ:
[...]
> [ 5006.824883] firewire_core: skipped bus generations, destroying all nodes
> [ 5007.324110] firewire_core: rediscovered device fw1
> [ 5007.324132] firewire_core: giving up on config rom for node id ffc1
> 

Right, a "giving up..." which is not followed by a "created device..."
sometime later is of course a terminal failure to probe a node.  In such a
case, there will of course not be any /dev/fw* file created for this
node.  But even though this is a probing failure, it is not necessarily an
I/O error or protocol error.  I have a 6-port repeater (a PHY without link,
but the PHY wrongly signals link-active) and an SBP-2 bridge (whose link
can be powered down while the PHY still acts as repeater if bus-powered;
likewise this PHY wrongly signals link-active when it shouldn't); these
two devices cause "giving up on config rom" messages which are correct but
do not represent an actual problem.

Sometimes "giving up on config rom" is due to an I/O error, e.g. with a
bad cable, weak power supply of a device, or a device firmware glitch that
goes away if the cable is plugged out and back in again or the device is
power-cycled.  Digital doesn't imply determinism... :-)

> > 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.

About an hour ago, the IEEE 1394 git repositories have been restored and I
can update them as before.  I am not yet able to upload tarballs and don't
know when this will happen, only that it will certainly happen.
-- 
Stefan Richter
-=====-==-== =-=- =====
http://arcgraph.de/sr/

------------------------------------------------------------------------------
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