Hi Marc, everyone,

Do you have any comments on how to heavily test a CAN driver tx/rx
code paths?

Below is the approach I use, which was succesful in triggering many
issues in the kvaser_usb driver. I wonder though if you guys have
any different tricks you use for your own daily CAN driver
development tx/rx testing?


Testing method:
---------------

On tx:

	$ cangen -g1 -I111 -Di -L4 can0 &
	$ cangen -g1 -I222 -Di -L4 can0 &
	$ cangen -g1 -I333 -Di -L4 can0 &
	$ cangen -g1 -I444 -Di -L4 can0 &

On the other end of the CAN bus, to test rx:

	$ cangen -g0 -I555 -Di -L4 can0 &
	$ cangen -g1 -I666 -Di -L4 can0 &
	$ cangen -g1 -I777 -Di -L4 can0 &

Echo is enabled in the driver. Now doing a basic

	$ candump -d -e can0,0:0,#FFFFFFFF > output.txt

produces too many dropped packets after around 10 minutes of use. [1]

Using in-kernel CAN ID filtering solves the issue nicely:

	for i in {1..7}; do
	    candump -e -d can0,$i$i$i:7FF > output-$i$i$i.txt &
	done

Then the machine is left for a day or two. Afterwards, using simple
Python scripts, I analyze each output-XXX.txt file to ensure that
no packets got dropped for each `cangen' path above, and that the
sequential order of data generated by `cangen -Di' is still
maintained.


Thanks a lot,
Darwish


[1] As reported by SO_RCVQ_OFL, skb-attached, ancilliary messages.
    Thanks Oliver, candump `-d' was a life-saving feature!
    http://article.gmane.org/gmane.network.socketcan.user/179