On 07/05/2005 11:51 PM Jan Kiszka wrote:
> Jan Kiszka wrote:
>>> ...
>>> Also on my MPC860 module I see large calibrated master-to-slave packet
>>> delays. 440 seconds, this looks like an endianess problem or a wrong
>>> (64-bit?) calculation.
>>>
>>
>> Oops. Ok, let's wait for the binary dump - and what Ethereal dissects.
>>
>
> The dump revealed that there is some problem on the master side (you can
> follow this explanations by opening your dump in a recent Ethereal):
>
> The slave sends its calibration requests including a "Transmission Time
> Stamp". This value should be copied by the master on reception into the
> calibration reply frame ("Request Transmission Time"). For unknown
> reasons, this field is always 0 in your dump. All systems I tested so
> far did not show this effect (ok, all were x86). It immediately leads to
> such exorbitant round-trip delays.
>
> Could you try to debug this further? The involved code in the TDMA
> module can be found here:
>
> http://www.rts.uni-hannover.de/rtnet/lxr/source/stack/rtmac/tdma/tdma_proto.c#L261
>
> The copy is performed in line 297. Please check if the value is
> correctly transfered and probably overwritten afterwards (in the 3com
> driver?) or if 0 is already contained in the reply frame.
I found the problem:
/* Get and patch time stamp just before the transmission */
if (skb->xmit_stamp) {
rtos_get_time(&time);
rtos_print("xmit_stamp=%#Lx -> ", *skb->xmit_stamp);
*skb->xmit_stamp = cpu_to_be64
rtos_time_to_nanosecs(&time) +
*skb->xmit_stamp);
rtos_print("%#Lx\n", *skb->xmit_stamp);
}
/* Push the data cache so the CPM does not get stale memory
* data.
*/
flush_dcache_range((unsigned long)skb->data,
(unsigned long)skb->data + skb->len);
The "flush_dcache_range" was before modifying skb->xmit_stamp. I was not
aware, that it's pointing to skb's data :-(.
Thanks.
Wolfgang.
> Thanks again for your help,
> Jan
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> RTnet-users mailing list
> RTnet-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rtnet-users
>
>
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
