Re: error reading config rom directory for node 0
Brought to you by:
aeb,
bencollins
|
From: Stefan R. <st...@s5...> - 2011-04-05 18:48:51
|
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/ |