Christian Keydel wrote: > Hi, I have added socketcan (trunk rev. 1033 from 8/11/2009) to a Linux board > support package for an ARM9-based processor running at 208 MHz. The Linux > kernel version is 2.6.27.8. The environment has busybox and no suitable > netlink interface (ip command doesn't allow setting CAN properties) so I can > use the sysfs interface only. The CAN bitrate is 250 kbps and I am using > max. clock at the SPI interface to the MCP2515 (10 MHz). We are using the > CAN RAW driver.
You could download and cross-compile the latest 'ip' from the iproute2 packet as show: git://git.kernel.org/pub/scm/network/iproute2/iproute2.git This would also allow to inspect the CAN statistics. The SysFS interface is deprecated. > In principle the setup works, but we appear to be dropping CAN packets at > the driver level. We have added several filters in the application level CAN > driver, and these filters appear to work under nominal message traffic > loads, but when we increase the message traffic on the CAN bus, the > controller driver appears to drop packets. > > Here is the code snippet for the software filters that we have added in the > application level driver: > > rfilter[0].can_id = 0x41; > rfilter[0].can_mask = 0xFF; > rfilter[1].can_id = 0xFFF1D8; > rfilter[1].can_mask = 0xFFFFFF; > rfilter[2].can_id = 0xFFF2D8; > rfilter[2].can_mask = 0xFFFFFF; > rfilter[3].can_id = 0xEAFF00; > rfilter[3].can_mask = 0xFFFF00; > > setsockopt(canSocket, SOL_CAN_RAW, CAN_RAW_FILTER, &rfilter, > sizeof(rfilter)); > > We do a non-blocking (flags = MSG_DONTWAIT) call to recvfrom() at a 10 msec > update rate. We are generating the following msgs at the given rates: > > 0x18EA1D41 (filter[0]) at once per 5 secs rate. > 0x18FEF341 (filter[0]) at once per second rate. > 0x18FFF1D8 (filter[1]) at once per 100msecs rate. > > We are additionally broadcasting messages that do not pass any filters to > make up a 300 messages per second traffic load. You can run # candump any,0:0,#FFFFFFFF in a separate window to check what messages are delivered and realize eventual error messages. > We have broadcast and dropped the following messages, apparently at the > controller driver level, over a run of approx. 16 minutes and 30 seconds: > > 0x18EA1D41 - broadcast 183 times received at app driver 180 > 0x18FEF341 - broadcast 997 times received at app driver 982 > 0x18FFF1D8 - broadcast 9460 times received at app driver 9290 > > Can someone give me any hints on how to troubleshoot this? Is there any > debug output available that could help? Right now I don't even know at which > level the frames are dropped. What does ifconfig show you? Also you can enable the kernel option CAN_DEBUG_DEVICES and look for CAN kernel messages using dmesg. Furthermore, you find some CAN network statistics in /proc/net/can. It could happen that the socket receive buffer gets full. You could trying to increase the receive buffer size setsockopt(..SO_RCVBUF..). Looking to the code (raw.c) it seems that the skb is dropped silently. It would be nice to increment some statistics or to use a dev_dbg(), at least. Or have I missed something? Wolfgang. _______________________________________________ Socketcan-users mailing list Socketcan-users@lists.berlios.de https://lists.berlios.de/mailman/listinfo/socketcan-users
