> On 26.11.2017, at 17:18, Wolfgang Grandegger <wg@xxxxxxxxxxxxxx> wrote: > > Hello Martin, > > Am 25.11.2017 um 15:47 schrieb kernel@xxxxxxxxxxxxxxxx: > > ...snip... >> I see the following counters: >> 7: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10 >> link/can promiscuity 0 >> can <ONE-SHOT,BERR-REPORTING> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0 > > Why do you use "ONE_SHOT" in all your test cases? I did test oneshot and non-oneshot - I just did not document them here, I am just mentioning the issue of dropped frames when the driver is submitting them correctly. Also - for what it is worse - the RX case would not be impacted by one-shot enabled or not. > Did you also check for out-of-order issues, e.g. by using "canfdtest”? As for out of order: yes I have taken extreme care that we do not get out of order packets for all possible cases testing with cangen - there may be one error case where there could be an out of order case in the tx path (unless we want to drop that frame - it would be a MAB case) But until now I did not know about canfdtest, but for all practical purposes it can not test for out-of-order delivery on a 100% saturated bus the way it is working - latencies are too big for that! Still for completeness a quick test from beagleboneblack to a RPI CM3 with a mcp2517fd gives: root@beaglebone:~/can-utils# ./canfdtest -g -vvv can0 -l 32 interface = can0, family = 29, type = 3, proto = 1 0078: [8] 01 02 03 04 05 06 07 08 0078: [8] 02 03 04 05 06 07 08 09 0078: [8] 03 04 05 06 07 08 09 0a 0078: [8] 04 05 06 07 08 09 0a 0b 0078: [8] 05 06 07 08 09 0a 0b 0c 0078: [8] 06 07 08 09 0a 0b 0c 0d 0078: [8] 07 08 09 0a 0b 0c 0d 0e 0078: [8] 08 09 0a 0b 0c 0d 0e 0f 0078: [8] 09 0a 0b 0c 0d 0e 0f 10 0078: [8] 0a 0b 0c 0d 0e 0f 10 11 0078: [8] 0b 0c 0d 0e 0f 10 11 12 0078: [8] 0c 0d 0e 0f 10 11 12 13 0078: [8] 0d 0e 0f 10 11 12 13 14 0078: [8] 0e 0f 10 11 12 13 14 15 0078: [8] 0f 10 11 12 13 14 15 16 0078: [8] 10 11 12 13 14 15 16 17 0078: [8] 11 12 13 14 15 16 17 18 0078: [8] 12 13 14 15 16 17 18 19 0078: [8] 13 14 15 16 17 18 19 1a 0078: [8] 14 15 16 17 18 19 1a 1b 0078: [8] 15 16 17 18 19 1a 1b 1c 0078: [8] 16 17 18 19 1a 1b 1c 1d 0078: [8] 17 18 19 1a 1b 1c 1d 1e 0078: [8] 18 19 1a 1b 1c 1d 1e 1f 0078: [8] 19 1a 1b 1c 1d 1e 1f 20 0078: [8] 1a 1b 1c 1d 1e 1f 20 21 0078: [8] 1b 1c 1d 1e 1f 20 21 22 0078: [8] 1c 1d 1e 1f 20 21 22 23 0078: [8] 1d 1e 1f 20 21 22 23 24 0078: [8] 1e 1f 20 21 22 23 24 25 0078: [8] 1f 20 21 22 23 24 25 26 0078: [8] 20 21 22 23 24 25 26 27 Test messages sent and received: 32 (I can not go to longer tests because I may hit a bug I am just now trying to fix in the current code level). If you are interested in any more specific tests that I should be running, then please list those and I can report them when submitting V2 of the patch set. Just to put everything into perspective: The equipment available to me is: * beagle bone black with c_can * raspberry pi 3 with mcp2515 * raspberry pi CM3 with mcp2517fd * raspberry pi 2 with mcp2517fd * saleae logic analyzer Thanks, Martin-- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
