Yeah I do not know why, but it does seem you’re using different sources than I used. Here are some “exact steps” I used to create a virtual can development machine. Note: That the only real differences I did here was using vcan, instead of a physical canX device. And vcan in this case does not need bit timing as the log files created have timestamps.
After many canplayer / candump sessions:
william@debian-can:~/can-dev$ sudo ifconfig vcan0
[sudo] password for william:
vcan0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
UP RUNNING NOARP MTU:16 Metric:1
RX packets:567011 errors:0 dropped:0 overruns:0 frame:0
TX packets:567011 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4161973 (3.9 MiB) TX bytes:4161973 (3.9 MiB)
However, this is in a virtual machine using 4GB RAM, and 4 cores @ 2.5Ghz. The speed between this virtual machine, and the BBB is very noticeable. You may consider using the same sources to build can-utils, if you can. They may be newer / more up to date . . .but no guarantee it will make a difference. Also, you will have to make some changes obviously . . .
EXACT STEPS:
william@debian-can:~$ sudo apt-get install build-essential autoconf libtool git
william@debian-can:~$ mkdir dev
william@debian-can:~$ cd dev
william@debian-can:~/dev$ git clone https://github.com/linux-can/can-utils.git
Cloning into ‘can-utils’…
remote: Counting objects: 1080, done.
remote: Total 1080 (delta 0), reused 0 (delta 0), pack-reused 1080
Receiving objects: 100% (1080/1080), 294.56 KiB | 106 KiB/s, done.
Resolving deltas: 100% (711/711), done.
william@debian-can:~/dev$ cd can-utils
william@debian-can:~/dev/can-utils$ ./autogen.sh
Anyway, got to run for a while and do some work. If you have any further questions I can try and answer when I get back.
One more thing that comes to mind that could be effecting your dropped packets. I’m running cmd line only on our BBB’s. Where you’re running X ( LXDE ? ).
It’s been my experience with the BBB is that with X, it can be incredibly sluggish, depending on what you’re doing. I have always guessed that this has to do with the BBB only having 512MB RAM, and X + running apps use up a lot of this. Anyway, it is possible that the combination of running X + whatever apps you’re running is using up so much RAM that socketCAN + can-utils apps could be limited in how much RAM can be used for buffering. It is also possible that various things could be competing for CPU time.
So, if you must run X, and I’m guessing you must because of the LCD cape. Then I would explore how to limit memory and CPU usage while running X. e.g. reduce running apps to a minimum, and google around for memory / CPU optimization and minimization techniques.
heh keep forgetting to add information . . . Anyway, no dropped packets on our BBB
debian@xanbustester:~$ sudo ifconfig can1
can1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
UP RUNNING NOARP MTU:16 Metric:1
RX packets:77659246 errors:0 dropped:77659246 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:572774448 (546.2 MiB) TX bytes:0 (0.0 B)
Interrupt:71
debian@xanbustester:~$ cat /etc/dogtag
BeagleBoard.org Debian Image 2015-03-01
debian@xanbustester:~$ uname -r
3.14.39-ti-r61
errr looks like I was wrong. Many, many dropped RX packets. I was looking at TX. So . . . hmmmm yeah I do not know what to say. This does not affect our end goal though. As the application I’m writing tracks payload sequence numbers, and if any are out of order for the payload, they just get dumped . . .