On 07/06/2005 07:18 PM Jan Kiszka wrote:
> Wolfgang Grandegger wrote:
>> ...
>> 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 :-(.
>>
>
> ...and as the packets were sniffed on the sender side, the correct copy
> made it into the dump. Fine, another problem solved. :)
Yes, it was a nice cache problem. Thanks for help.
> Then please let me know when your tests with the new driver run fine so
> that we can roll out a 0.8.3. With the upcoming official RTDM, we need
> some reorganisation work (=>0.9), and I would like to have a cut first.
OK, I want to finish the MPC 52xx driver development end of this week
anyhow.
Wolfgang.
-------------------------------------------------------
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
