Re: Embedded 1394 device difficulties...

Steve Kinneberg wrote:
> On Fri, 2004-01-23 at 09:43, Russel Hill wrote:
>
>>We have a set of 3 embedded 1394 devices using the TSB12LV32/TSB41AB3.
>>These devices are implemented using the data mover port and an FPGA.
>>They are not IRM capable. In addition to the embedded devices, we have
>>two linux boxes running the 2.6.1 kernel, ieee1394 svn version 1105, and
>>libraw1394 svn version 139. Two of the embedded devices are spewing
>>data, one of the linux boxes consumes this data and spews data to the
>>remaining embedded device. In this situation the remaining linux box
>>hangs on the 1394 bus but neither generates or consumes 1394 data.
>>
>>Occasionally, the final embedded device stops receiving data from the
>>linux box. All the transmitters appear to be transmitting. This seems
>>to occur after a bus reset. Often it recovers with out intervention,
>>but sometimes it does not. The syslog messages associated with these
>>events are:
>>
>>ieee1394: Node changed: 0-04:1023 -> 0-02:1023
>>ieee1394: Current remote IRM is not 1394a-2000 compliant, resetting...
>>ieee1394: The root node is not cycle master capable; selecting a new
>>root node and resetting...
>
>
> Is the above message when it recovers or when it doesn't recover?

These messages have been extracted from the logs. They occur
sporatically. The test generates a bus reset every 20 seconds.

The "Node changed" message seems to be correlated to recovery. However,
we left the test running last night and after a few hours the device
stalled and the last message in the log was a "Node changed" message.

> You'll probably need to use a FireWire snooper to get to the bottom of
> your problem.

By firewire snooper do you mean something like a FireInspector
(http://www.catc.com/products/fireinspector.html)?

Or, is there something lighter weight?

Not sure it matters. We've already started the process of renting a
FireInspector. Have you had experience with them?

> Without it you can't truely verify if the Linux box has
> restarted transmission of the if the receiving embedded device is
> listening. Also, if the root node changes after the bus reset, it's
> likely that the IRM has changed as well. If you are using isochronous
> channels for sending data, then the channels may have changed and your
> embedded device is listening on the wrong channel. This is just
> speculation of course.

I'm guessing there isn't a way to discover the answers without a snooper.

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
mailing list Linux1394-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux1394-user
Received on Thu Jan 29 10:58:59 2004