Hi Oliver, > On 01.07.2011 14:50, Bhupesh SHARMA wrote: > > >>> See details here: > >>> https://lists.berlios.de/pipermail/socketcan-users/2010- > >>> January/001226.html > >>> > >>> If it's not on the socketlayer it's worth checking the driver ;-) > >>> > >> > >> However, I did some ugly hacks and now I can run candump with -d > >> option. > >> I see the DROPCOUNT messages like this: > >> DROPCOUNT: dropped 1 CAN frame on 'can0' socket (total drops 1) > > Do you see this once or continuous with increasing 'total drops' ?
Yes, I see continuous DROPCOUNT messages with increasing total drops. See a more descriptive log below: DROPCOUNT: dropped 1 CAN frame on 'can0' socket (total drops 1) can0 1 [8] 1C 00 00 00 00 00 00 00 DROPCOUNT: dropped 2 CAN frames on 'can0' socket (total drops 3) can0 1 [8] 1F 00 00 00 00 00 00 00 DROPCOUNT: dropped 2 CAN frames on 'can0' socket (total drops 5) can0 1 [8] 22 00 00 00 00 00 00 00 DROPCOUNT: dropped 2 CAN frames on 'can0' socket (total drops 7) can0 1 [8] 25 00 00 00 00 00 00 00 DROPCOUNT: dropped 2 CAN frames on 'can0' socket (total drops 9) can0 1 [8] 28 00 00 00 00 00 00 00 DROPCOUNT: dropped 2 CAN frames on 'can0' socket (total drops 11) can0 1 [8] 2B 00 00 00 00 00 00 00 DROPCOUNT: dropped 2 CAN frames on 'can0' socket (total drops 13) can0 1 [8] 2E 00 00 00 00 00 00 00 DROPCOUNT: dropped 2 CAN frames on 'can0' socket (total drops 15) > > >> > >> Pardon my limited knowledge on this option, but how can I determine > >> whether > >> this packet was dropped by the driver or the user-space application. > > The drop that can be monitored with the '-d' option are the CAN frames > that > are lost because of the userspace application was not able to consume > the > entire data 'in-time'. Ok. Just to ensure that my driver is not losing any frames during RX, I modified my driver to expect the incoming data only in a particular sequence, say: 0100000000000000 0200000000000000 0300000000000000 . . . 2D00000000000000 2E00000000000000 2F00000000000000 0100000000000000 0200000000000000 0300000000000000 ... and so on And complain in case it doesn't see the incoming frames in this order. Then, I pump the data in this sequence from a CAN generator working as a Transmitter. I see that the driver always receives the frames in the correct order. Now, your mail also confirms this behavior. This means that the user space application is losing frames. > > > Forgot to add the `ip -d -s link show can0` output: > > > > 2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state > UNKNOWN qlen 10 > > link/can > > can state ERROR-ACTIVE restart-ms 0 > > bitrate 988095 sample-point 0.750 > > tq 253 prop-seg 1 phase-seg1 1 phase-seg2 1 sjw 1 > > c_can: tseg1 2..16 tseg2 1..8 sjw 1..4 brp 1..1024 brp-inc 1 > > clock 83000000 > > re-started bus-errors arbit-lost error-warn error-pass bus-off > > 0 0 0 0 0 0 > > RX: bytes packets errors dropped overrun mcast > > 1380496 172562 0 0 0 0 > > TX: bytes packets errors dropped carrier collsns > > 0 0 0 0 0 0 > > > > I can decipher from this dump that the packet dropped and errors > > is 0 while DROPCOUNT messages are still present in `candump -d` > output. > > The dropped counter in the netdevice has a different meaning. > > > > > Any idea, where there frames are being dropped? > > Yes - see above (in the socket receive buffer to the userspace app). > So, is there a mechanism to receive frames correctly using the 'candump' application with a socketCAN driver which implements NAPI (especially on commercial products which will expect the frames transmitted by a transmitter to be received correctly [read in-order] by an application running on the receiver side? Regards, Bhupesh _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
