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' ? >> >> 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'. > 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). Regards, Oliver _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
