Dropped CAN-Frames

[S.Grosjean]

Hello,

Unfortunately, they changed the asm stuff in the recent 4.1 kernel, so I was only able to test this on my Ubuntu running the 3.19.

Hum... I admit I don't understand what your wrote above, about some "asm stuff" that may have changed. I would be very astonished if this prevented from building our pcan driver. We first have to check this against this new Kernel asap.

Moreover, to summarize and in order to be sure that I understood everything correctly with your 3.19 Kernel: whatever the driver you're using (pcan or peak-usb), your application does not receive all the frames that have been sent. Sometimes, you detect some hw overrun errors, sometimes not. Right?

I'd like to do a last test: could you rebuild the pcan driver but with "make NET=NO". Doing this, you will build a "chardev" pcan driver that won't be compatible with the socket-CAN layer. *BUT* Id' like to do some tests with this pcan and our test applications. Thus,

Code: Select all

% cd peak-linux-driver-x.y
% make -C driver NET=NO
% make -C lib
% make -C test
% sudo rmmod pcan
% sudo insmod driver/pcan.ko

From this point, you have loaded pcan. Launch the receivetest application please, like this:

Code: Select all

% test/receivetest -f=/dev/pcan32 -b=0x11c 

Then, start your application that loads the CAN bus. Do what you are used to (aka resizing windows). Stop the transmitting application, then the "receivetest" application (^C). This last one displays the number of frames it has received. Could you please compare this number with the number of CAN frames your (writing) application has written? You could also give us a screen copy of this result...

Regards,

Stéphane.

[lstutz]

Hello,

first of all, thanks again for your help!

Hum... I admit I don't understand what your wrote above, about some "asm stuff" that may have changed. I would be very astonished if this prevented from building our pcan driver. We first have to check this against this new Kernel asap.

They removed some assembler legacy code and restructured the whole ASM folder layout (I think they did this in 4.0 already). I got a lot of missing include file erros when trying to compile the peak-drv against the 4.1 kernel.

Moreover, to summarize and in order to be sure that I understood everything correctly with your 3.19 Kernel: whatever the driver you're using (pcan or peak-usb), your application does not receive all the frames that have been sent. Sometimes, you detect some hw overrun errors, sometimes not. Right?

Yes, correct! Have you tried reproducing? It should be fairly easy with the demo I provided.

Then, start your application that loads the CAN bus. Do what you are used to (aka resizing windows). Stop the transmitting application, then the "receivetest" application (^C). This last one displays the number of frames it has received. Could you please compare this number with the number of CAN frames your (writing) application has written? You could also give us a screen copy of this result...

I did that and I don't get dropped frames any more! Seems to work fine. But sadly, chardev is not an option. I really need the NetDev to work.

Regards,
Leonhard

[S.Grosjean]

Hello,

Sorry for the delay to answer, but I took contact with linux-can maintainers to talk about this issue...

For the 4.1 patched kernel to have any chance to work with pcan in netdev mode, one says that pcan must be modified too. And I agree with.

So, if you agree, could you please do the followings on your side:

Code: Select all

% $EDIT driver/src/pcan_netdev.c

Then, in "pcan_netdev_rx()" function, around line ~211, do the following change:

Code: Select all

  skb = dev_alloc_skb(sizeof(struct can_frame));

  if (skb == NULL)
    return -ENOMEM;

+ __net_timestamp(skb);

  skb->dev = ndev;
  skb->protocol = htons(ETH_P_CAN);

Finally, rebuild and reload the new pcan, and tell us if this has changed anything...

Thanks for your tests,

Regards,

Stéphane

[lstutz]

Hi Stéphane,

thanks for your reply. But I can't compile the peak-drv against the 4.1 kernel. I get:

Code: Select all

[lstutz@WindowsMe peak-linux-driver-7.14]$ make -C driver RT_CFLAGS="-Wno-error=date-time"
make: Verzeichnis „/home/lstutz/peak-linux-driver-7.14/driver“ wird betreten
***
*** Host machine kernel version=4.1.0-1-MANJARO
*** Driver kernel version=4.1.0-1-MANJARO
*** Path to kernel sources=/lib/modules/4.1.0-1-MANJARO/build
*** use KBUILD=no
***
gcc -O2 -D__KERNEL__ -DMODULE -Wall -I/lib/modules/4.1.0-1-MANJARO/build/include -I. -DNO_DEBUG -DMODVERSIONS -DPARPORT_SUBSYSTEM -DUSB_SUPPORT -DPCI_SUPPORT -DNO_PCIEC_SUPPORT -DISA_SUPPORT -DDONGLE_SUPPORT -DPCCARD_SUPPORT -DNETDEV_SUPPORT -DNO_RT -Wno-error=date-time   -c -o src/pcan_main.o src/pcan_main.c
In file included from /lib/modules/4.1.0-1-MANJARO/build/include/linux/kernel.h:6:0,
                 from /lib/modules/4.1.0-1-MANJARO/build/include/linux/list.h:8,
                 from /lib/modules/4.1.0-1-MANJARO/build/include/linux/module.h:9,
                 from ./src/pcan_common.h:53,
                 from src/pcan_main.c:45:
/lib/modules/4.1.0-1-MANJARO/build/include/linux/linkage.h:7:25: schwerwiegender Fehler: asm/linkage.h: Datei oder Verzeichnis nicht gefunden
Kompilierung beendet.
<eingebaut>: die Regel für Ziel „src/pcan_main.o“ scheiterte
make: *** [src/pcan_main.o] Fehler 1

Will the patch help on the 3.19 kernel as well?

Edit: I saw on the linux-can mailing list that you are using 3.16. Will test if I can reproduce with it here.

Regards,
Leonhard

[S.Grosjean]

Hi,

Ok, thx for the info. You're right, building pcan with versions 4.x of the Kernel won't work.
Before we deliver a new version, you can fix this by editing "peak-linux-driver-x.y.z/driver/Makefile", and change below line:

Code: Select all

USEKBUILD   := $(shell if [ $(KVERSION) -eq 3 ]  ; then echo "yes" ; else echo "no"  ; fi)

into:

Code: Select all

USEKBUILD   := $(shell if [ $(KVERSION) -ge 3 ]  ; then echo "yes" ; else echo "no"  ; fi)

(note the change from "-eq" into "-ge")

Moreover, it looks like the check_mem_region() function is deprecated in 4.1. So, in order to build pcan with 4.1, you'll have to comment the 2 calls to this function in driver/src/pcan_pci.c too...

Regards,

Stéphane

[lstutz]

Hi,

the modifications worked and I got peak-drv to compile against my patched 4.1 kernel. But the issue is still the same. Lost frames even if I don't do anything with the machine. I tried a USBtin adapter with the same kernel (and netdev described like here) and it works just fine. Any further ideas?

Regards,
Leonhard

[S.Grosjean]

Hi,

As I told you at the beginning, you HAVE TO check the return value when writing a CAN frame on a socket!

I have attached a modified and fixed version of your canTest.c as well as a Makefile to build both binaries "txcan" and "rxcan". Both use argv[1] as name of the CAN interface:

I have connected two PCAN-USB on my Linux PC (running 3.16):

SSH#1:

Code: Select all

$ ./rxcan can0
...
RX: ff ff ff ff 00 00 00 d4
RX: ff ff ff ff 00 00 00 d5
RX: ff ff ff ff 00 00 00 d6
RX: ff ff ff ff 00 00 00 d9
Expected sequence number: 215, received sequence number: 217, delta: 2
$

SSH#2:

Code: Select all

$ ./txcan can1
...
TX: ff ff ff ff 00 00 00 d5
TX: ff ff ff ff 00 00 00 d6
TX: ff ff ff ff 00 00 00 d7
error 105: the above frame won't be transmitted
TX: ff ff ff ff 00 00 00 d8
error 105: the above frame won't be transmitted
TX: ff ff ff ff 00 00 00 d9
TX: ff ff ff ff 00 00 00 da
^C

Code: Select all

$ grep 105 /usr/include/asm-generic/errno.h
#define ENOBUFS         105     /* No buffer space available */
$

Moreover, as you can see below, Rx/Tx counters are matching! Since these counters are handled by the peak-usb driver, this proves that it has forwarded everything it has received 1/ from the PCAN-USB (rx side) 2/ from the linux-can stack (tx side).

If counters are equal and no overrun errors nor dropped frames, the leakage comes obvioulsy from elsewhere. Since the PCAN-USB has proven for years that it is able to handle 250 kb CAN transfer, only the linux-can and/or the application is responsible of the leakage.

In this case, it came from your application.

SSH#1:

Code: Select all

$ ip  -s -d link show can0
11: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
    link/can  promiscuity 0
    can state ERROR-ACTIVE restart-ms 0
          bitrate 250000 sample-point 0.875
          tq 250 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
          pcan_usb: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
          : dtseg1 0..0 dtseg2 0..0 dsjw 1..0 dbrp 0..0 dbrp-inc 0
          clock 8000000
          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
    13960      1745     0       0       0       0
    TX: bytes  packets  errors  dropped carrier collsns
    0          0        0       0       0       0

SSH#2:

Code: Select all

$ /ip  -s -d link show can1
12: can1: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
    link/can  promiscuity 0
    can state ERROR-ACTIVE restart-ms 0
          bitrate 250000 sample-point 0.875
          tq 250 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
          pcan_usb: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
          : dtseg1 0..0 dtseg2 0..0 dsjw 1..0 dbrp 0..0 dbrp-inc 0
          clock 8000000
          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
    0          0        0       0       0       0
    TX: bytes  packets  errors  dropped carrier collsns
    13960      1745     0       0       0       0

Regards,

Stéphane