Re: inconsistent Self-ID

On 4 Mar, Mark Knecht wrote:
> Stefan Richter wrote:
>> On 4 Mar, Dai Yuwen wrote:
>>>OHCI.o: inconsistent self-ID [0Xxxxxxxxx/0Xxxxxxxxx]
>>>then the system hangs. So, what does the above info mean?
[...]
>> The check in ohci1394 that returns the "SelfID is inconsistent"
>> message simply compares the 1st half of each packet with the
>> second half. The standard requires that the 2nd is the binary
>> inverse of the 1st. That is, the packets were either defective in
>> the firts place or were corrupted during transmission or
>> reception.
>>
>> But the system (the kernel at least) should not hang because of
>> this.
[...]
> The one other thing I can think of that might effect this would be
> that during Iso time it's possible that a transmitting device will send
> an Iso packet with no payload. This packet will be 2 quadlets only. It's
> important that the stack check *any* 2 quadlet packet to see if it is 1)
> A Self-ID or 2) An Iso packet with no data payload. Is it possible that
> this is a properly formated Iso packet with a data payload of 0, but the
> stack has a corner condition problem in the code that isn't recognizing it?

Hmmm, indeed. Dai Yuwen, could you please post just one sample of
the exact [0Xxxxxxxxx/0Xxxxxxxxx] messages so that we could
identify the type of packet?

In theory, the OHCI chip should "know" which packets to put in
the self-ID packet buffer. But perhaps the chip designers missed
this possibility of 64byte iso packets (or any other 64byte
packets for that matter) during self-ID stage.

There are some checks in the low level drivers (ohci1394 and
pcilynx) and later in the mid level, but as far as I can see
there are no checks on the packet type. There could be later an
error notice by the mid level that one of the packets contains an
invalid phy ID. (The phy ID of the self ID packets resides in the
range of the data length field of the iso packet.) The mid level
would then reset the bus. After 20 retrys, it would give up with
the message "Stopping out-of-control reset loop/ Warning -
topology map and speed map will not be valid". I.e. it would not
hang.

If the camery has the phy ID 0, and the OHCI chip triggers the
selfIDComplete interrupt after it recieved exactly on iso packet
and generated its own self-ID packets, this check would let it
slip as far as I understand. Then the mid level builds the speed
map using the port connection and phy speed data from the self-ID
packets. Might yield some interesting results.

-- 
Stefan Richter
-=====-=-=-- --== --=-=
http://arcgraph.de/sr/
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
mailing list Linux1394-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux1394-user