Re: Chip-send-buffer full
Posted: Tue 6. Apr 2021, 18:19
Hello, thanks a lot for the fast answer!
Does the reading thread still receives any CAN frames?
Yes, as mentioned before the reading thread still receives CAN frames.
If I power off the other CAN Device connected to the Channel such that there is no traffic on the CAN-bus anymore (no receives), the tx_pending_msgs still stays at 500. The error count shown in cat /proc/rtai also is 0 all the time.
Is the pcan write function thread save? In the sense that the write function on the same channel can be called from different threads? Currently I dont do that, but I might want to do that in the future.
Are you able to reproduce the issue in non-RT mode?
Im not sure what exactly you mean with that. Do you mean running the threads that use the pcan functions in soft_real_time mode instead of hard_real_time mode? I have not tested that yet.
Which skin are you using?
Not sure what u mean with that. Are you talking about the Xenomai-skin? We dont use Xenomai, we use RTAI.
How do you un-block the writing thread?
Do you mean unblocking when the issue occures (tx buffer full)? Currently we dont recover from this condition (power-cycle is needed).
What does "dmesg | grep pcan" say please?
It only says the following when I boot my system:
[ 10.722442] pcan: Release_20210119_n (le)
[ 10.722445] pcan: driver config [mod] [pci] [pec] [rt]
[ 10.722630] pcan 0000:03:00.0: PCAN-miniPCIe FD sub-system id 14h (4 channels)
[ 10.737372] pcan: PCB v2h FPGA v3.2.1 (mode 3)
[ 10.737449] pcan: - pcie fd device minor 0 found
[ 10.737489] pcan: - pcie fd device minor 1 found
[ 10.737530] pcan: - pcie fd device minor 2 found
[ 10.737571] pcan: - pcie fd device minor 3 found
[ 10.738009] pcan: major 0.
When the issue occures it doesnt say anything.
Regards
Does the reading thread still receives any CAN frames?
Yes, as mentioned before the reading thread still receives CAN frames.
If I power off the other CAN Device connected to the Channel such that there is no traffic on the CAN-bus anymore (no receives), the tx_pending_msgs still stays at 500. The error count shown in cat /proc/rtai also is 0 all the time.
Is the pcan write function thread save? In the sense that the write function on the same channel can be called from different threads? Currently I dont do that, but I might want to do that in the future.
Are you able to reproduce the issue in non-RT mode?
Im not sure what exactly you mean with that. Do you mean running the threads that use the pcan functions in soft_real_time mode instead of hard_real_time mode? I have not tested that yet.
Which skin are you using?
Not sure what u mean with that. Are you talking about the Xenomai-skin? We dont use Xenomai, we use RTAI.
How do you un-block the writing thread?
Do you mean unblocking when the issue occures (tx buffer full)? Currently we dont recover from this condition (power-cycle is needed).
What does "dmesg | grep pcan" say please?
It only says the following when I boot my system:
[ 10.722442] pcan: Release_20210119_n (le)
[ 10.722445] pcan: driver config [mod] [pci] [pec] [rt]
[ 10.722630] pcan 0000:03:00.0: PCAN-miniPCIe FD sub-system id 14h (4 channels)
[ 10.737372] pcan: PCB v2h FPGA v3.2.1 (mode 3)
[ 10.737449] pcan: - pcie fd device minor 0 found
[ 10.737489] pcan: - pcie fd device minor 1 found
[ 10.737530] pcan: - pcie fd device minor 2 found
[ 10.737571] pcan: - pcie fd device minor 3 found
[ 10.738009] pcan: major 0.
When the issue occures it doesnt say anything.
Regards