On 09/05/2009 10:07 AM, Gole, Anant wrote:
>
>> -----Original Message-----
>> From: Wolfgang Grandegger [mailto:[email protected]]
>> Sent: Friday, September 04, 2009 8:11 PM
>> To: Gole, Anant
>> Cc: [email protected]; Marc Kleine-Budde
>> Subject: Re: [PATCH V2] net-next-2.6:can: add TI CAN (HECC) driver
>>
> [snip]
>> expected: 0078: [8] 16 17 18 19 1a 1b 1c 1d
>>> received: 0078: [8] 18 19 1a 1b 1c 1d 1e 1f
>>>
>>> I am losing packets in send probably ...
>>
>> You could attach another board to the bus sniffing the traffic with
>> candump. This should make obvious what happened.
>>
>> Wolfgang.
>>
>
> Yes I did that by putting a 3rd can sniffer node and have some interesting 
> observations:
>
> 1. First I picked up the two canecho utilities from Vladislav that he 
> modified from Marc's git (Thanks to both of you)
> https://lists.berlios.de/pipermail/socketcan-core/2009-August/002871.html
>
> 2. I noticed that the write functions on both did not check for errors and 
> suspected that that might be the issue of not having enough buffers on the 
> queue and it was - After changing the write call to loop until successful I 
> was able to get traffic moving (until later when it fails again) - the change 
> was a single line on write calls (in both utilities)
> while (write(s,&tx_frames[send_pos], sizeof(*tx_frames))<  0) ;

Ah, right, I fixed that in my private version as show:

         rewrite:
                 nbytes = write(s, &tx_frames[send_pos],
                                sizeof(*tx_frames));
                 if (nbytes != sizeof(*tx_frames))
                 {
                         if (nbytes < 0)
                         {
                                 if (errno == ENOBUFS)
                                 {
                                         sched_yield();
                                         goto rewrite;
                                 }
                                 perror("write failed");
                         }
                         else
                                 fprintf(stderr, "write retruned only "
                                         "%d bytes\n", nbytes);
                         break;
                 }

Sorry, I didn't remember.

> 3. On further testing I found that at times the canecho_gen node generates a 
> duplicate frame (probably my driver is at fault here) and hence the utility 
> fails after a few seconds. The duplicate frame was verified on the 3rd node 
> on the bus (the scanner).
>
> Any clues welcome. I will continue by debug.

You can run candump on the test target to check message reception.

Wolfgang.

_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core

Reply via email to