Re: error reading config rom directory for node 0

[Stefan R. <st...@s5...>]

On Mar 31 Carl Karsten wrote:
> What does this mean:
> 
> juser@cp333:~$ dvgrab
> rom1394_0 warning: read failed: 0x0000fffff0000414
> error reading config rom directory for node 0
> rom1394_1 warning: read failed: 0x0000fffff0000414
> error reading config rom directory for node 1

If dvgrab is started without -guid argument, it goes through all nodes on
the bus and attempts to read their Configuration ROM register (but
starting at the root directory offset 0x414 rather than the very beginning
of the register, which is at offset 0x400) until it finds a node that has
got an AV/C unit.

Here the fetching of the Configuration ROM failed immediately at the first
two nodes.  This can have had various reasons.  E.g. reading of the local
node's Configuration ROM typically fails because an unprivileged user does
typically not have access permission to the local node's /dev/fw* file.
Which is fine with dvgrab since it just tries the next node then, if there
is any.

> Error: no camera exists
> 
> one new line in dmesg:
> [  640.823116] firewire_core: Unsolicited response (source 0, tlabel 0)

Probably a read request to the remote node did actually go out over the
wire, and the remote node sent a response, but Linux received it after
firewire-core already gave up on the transaction because the split
transaction timeout passed by.

Either the remote node was rather slow to respond, or firewire-core was
too quick to time out the transaction.  Which kernel do you have?  The
split transaction timeout handling has been changed lately to be more
careful.

> juser@cp333:~$ lspci |grep Fi
> 00:0d.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev 46)
> 00:0f.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev 46)
> 
> Power cycling the device (twinpact) seems to have fixed everything.  The
> twinpact has been pretty robust, so wondering if it is really at fault.

We may never be able to find out for sure.

By the way, I am having the plan to tweak libraw1394 to cheat and
redirect all Configuration ROM read requests to the kernel's config ROM
cache.  This would save a little bit of bus bandwidth when applications
start or rescan the bus after bus resets, but more importantly, it would
eliminate IO errors from config ROM read attempts.  Should be trivial to
implement but there is always this lack of spare time...
-- 
Stefan Richter
-=====-==-== -=-- --=-=
http://arcgraph.de/sr/