PEAK-CAN miniPCIe devices failed on Xenomai 3.0.5

[Johnny_Mao]

Thanks a lot,

We have do the following test with your suggestions:

1. Enable the shared interrupt

Code: Select all

$ grep CONFIG_XENO_OPT_SHIRQ /boot/config-`uname -r`
CONFIG_XENO_OPT_SHIRQ=y

2. The can device can be registered successfully:

Code: Select all

$ dmesg | grep EAK
[    3.413147] PEAK-PCI-CAN: initializing device 001c:0008
[    3.413165] PEAK-PCI-CAN 0000:01:00.0: enabling device (0000 -> 0002)
[    3.418376] PEAK-PCI-CAN: base_addr=ffffb89fc0cb5000 conf_addr=ffffb89fc0cad000 irq=22
[    3.418457] PEAK-PCI-CAN: base_addr=ffffb89fc0cbd400 conf_addr=ffffb89fc0cad000 irq=22

3. Connect two wires CAN-BUS with can0 & can1 directly

Code: Select all

$ sudo /usr/xenomai/rtcanconfig rtcan0 -b 1000000 start
$ sudo /usr/xenomai/rtcanconfig rtcan1 -b 1000000 start

4. View the CAN device information:

Code: Select all

$ cat /proc/rtcan/devices 
Name___________ _Baudrate State___ TX_Counter RX_Counter ____Errors
rtcan0            1000000 active            0          0          0
rtcan1            1000000 active            0          0          0

5. Open one terminal, send the data with rtcansend command:

Code: Select all

$ while :; do sudo /usr/xenomai/bin/rtcansend rtcan0 -i 1 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 -v; sleep 0.1; done
interface rtcan0
s=3, ifr_name=rtcan0
<0x001> [8] 01 02 03 04 05 06 07 08
Cleaning up...
interface rtcan0
s=3, ifr_name=rtcan0

6. Open the another terminal, with

Code: Select all

$ sudo /usr/xenomai/bin/rtcanrecv rtcan1

no data was received.

Xenomai kernel has been tested successfully. Sending and receiving data are failed yet.
(linux kernel 4.9.38 xenomai kernel 3.0.5)
We follow this link to the xenomai installation and testing:
https://rtt-lwr.readthedocs.io/en/lates ... omai3.html
So if we should change the default rt-socket-can driver with the peak-can driver?

Regards.

[Johnny_Mao]

Again, type the dmesg when failing to send data:

Code: Select all

[  429.981561] perf: interrupt took too long (2508 > 2500), lowering kernel.perf_event_max_sample_rate to 79500
[  441.533958] DMAR: DRHD: handling fault status reg 2
[  441.533977] DMAR: [INTR-REMAP] Request device [fa:1f.0] fault index 0 [fault reason 37] Blocked a compatibility format interrupt request

It looks like interrupt is failed and blocked.

[S.Grosjean]

Hi,

The peak-linux-driver in RT mode does not offer the RT-Socket CAN interface but is based on RTDM.
The interrupt problem seems a hw problem and could be the reason why you aren't able to run any driver correctly.
Try first to (de)activate the Intel VT for Directed I/O technology in your BIOS.

Regards,

[Johnny_Mao]

Thank you,

I have disabled Intel VT for Directed I/O technology in the BIOS. But it still doesnot work.

We have tested on two computers:

· EPIC-KBS9, i5-7650, x8, mSATA/Mini-PCIe Full Size x 1 (Default: mSATA, Optional for Mini-PCIe by BOM Change)
· UP2, N4200, x4, Intel HD Graphics 505

Regards.

[Johnny_Mao]

Hi, Stéphane

Bios options for VT-D and PCI-E are both setted.

So would you like to tell me what is the configuration of your tested system, e.g., linux kernel, xenomai kernel, and menuconfig options.

We have been strucked here for a long time. In non-RT linux systems, using can-uitls for the testing are sucessful. But we would like to
use RT-can in xenomai in our project.

Do you have any other suggestoins?

Thank you very much.

Regards.

[S.Grosjean]

Hi,

Did you try to disable the VT-D option and run Xenomai without it? We've also heard that ASPM could also generate problems over the PICe bus.

We can send you our Xenomai 3.1 kernel config but by email only. Please send the request to linux@peak-system.com.

Once again, we are not the author of this driver. You should contact him for more support.

Regards,

[Johnny_Mao]

Hi, Stéphane

I have send an Email to linux@peak-system.com.

Today, we found it seems to be the irq problem, because the irq process for rtcan is not successful when using the command

Code: Select all

 $ cat /proc/interrupt. 

We can not find the corresponding irq number. But in non-RT linux, can0 & can1 irq can be found in the interrupt process.

Again, we have debugged the rtcansend testing program in xenomai, it is strucked in the socket send() function.

Regards.

[Johnny_Mao]

Hi,

Good news! The problem has been solved. This is mainly caused by the following two reasons:
· shared interrupt (should be enabled in kernel)
· VT-D option in (should be disabled in bios)

Thanks a lot for your helps.

Regards.