On 10/9/20 7:40 PM, Kurt Van Dijck wrote: > On Fri, 09 Oct 2020 18:24:02 +0200, Marc Kleine-Budde wrote: >> On 10/9/20 4:16 PM, Kurt Van Dijck wrote: >>> I'm using a v5.4 kernel now, with backported 'can: mcp25xxfd: initial commit'. >>> I did focus up to now to CAN recv performance, but now I face another >>> issue. I have errors transmitting to CAN. >> >> What kind of errors? > First observation is that no response is received for some requests. > This is very high level, I need to investigate if the request is really > sent. This is a needle in a haystack. > Due to the transmit error counter in `ip -s link show can0`, I guess > it's not sent. If the HW TX process of a CAN frame runs into the MAB underflow there will be an error on the CAN bus (stuffing, etc...) The driver switches the HW back into normal mode and the TX is retried. So there should be no packet loss, but some error frames. >>> It's unstable. >> >> What does that mean? > > Each burst of >x CAN frames produces the problem. > I still figure x in this statement. The TX routine of the driver doesn't do any aggregation of CAN frames. Although the network stack offers support for that and the hardware supports that. The TX CAN frames are sent as individual SPI messages. On the other hand, what the driver does is aggregating the readout of the TEF (= TX-completion) messages. It's probably the overall system load that delays the SPI-complete-interrupt to SPI-CS deselect, so that CS stays active for too long after the transfer, and the errata is triggered. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Attachment:
signature.asc
Description: OpenPGP digital signature
