AW: AW: AW: mcp251xfd: Bad message receiption

From: "Stefan Althöfer" <Stefan.Althoefer@janztec.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: "Thomas.Kopp@microchip.com" <Thomas.Kopp@microchip.com>,
	"linux-can@vger.kernel.org" <linux-can@vger.kernel.org>
Subject: AW: AW: AW: mcp251xfd: Bad message receiption
Date: Sun, 1 Jan 2023 10:43:54 +0000	[thread overview]
Message-ID: <FR0P281MB1966783A50BDAD455BBC7F1A97F69@FR0P281MB1966.DEUP281.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <FR0P281MB196615471DB16E566528E7F097F09@FR0P281MB1966.DEUP281.PROD.OUTLOOK.COM>

[-- Attachment #1: Type: text/plain, Size: 2341 bytes --]

Update: During a recent test-run I had both of the two CAN interfaces of my RPI4 Model B fail. First can0
and then some hours later can1.

Furthermore I attached another dump after fail. The last one was for the case where my application
receives 4 wrong messages (2 of them equal). This case is where my application receives
2 wrong messages only (both being equal). The candump has a different pattern:

CAN selftest can1 ......idx    2 tx:2A5#00 02 01 08 9A 5D 15 4B
         rx:2A5#00 00 D1 7D 9D 18 91 50
idx    3 tx:2A5#00 03 AC 4D 55 BF 2F 56
         rx:2A5#00 00 D1 7D 9D 18 91 50
c (584) fail
0: RX72 (004/003)  2A5#00 00 D1 7D 9D 18 91 50
0: RX72 (004/002)  2A5#00 00 D1 7D 9D 18 91 50
0: TX72 (003/002)  2A5#00 03 AC 4D 55 BF 2F 56
0: RX72 (003/001)  2A5#00 01 B0 ED 22 AE 94 9F
0: TX72 (002/001)  2A5#00 02 01 08 9A 5D 15 4B
0: RX72 (002/000)  2A5#00 00 57 3D 14 2B 3A BA
0: TX72 (001/000)  2A5#00 01 B0 ED 22 AE 94 9F
0: TX72 (000/000)  2A5#00 00 57 3D 14 2B 3A BA

  can1  2A5  [08]  00 03 1C 48 53 3D E1 9B
  can1  2A5  [08]  00 03 1C 48 53 3D E1 9B
  can1  2A5  [08]  00 00 57 3D 14 2B 3A BA
  can1  2A5  [08]  00 00 57 3D 14 2B 3A BA
  can1  2A5  [08]  00 01 B0 ED 22 AE 94 9F
  can1  2A5  [08]  00 01 B0 ED 22 AE 94 9F
  can1  2A5  [08]  00 02 01 08 9A 5D 15 4B     **
  can1  2A5  [08]  00 02 01 08 9A 5D 15 4B     **
  can1  2A5  [08]  00 02 01 08 9A 5D 15 4B     **
  can1  2A5  [08]  00 02 01 08 9A 5D 15 4B     **
  can1  2A5  [08]  00 03 AC 4D 55 BF 2F 56     **
  can1  2A5  [08]  00 03 AC 4D 55 BF 2F 56     **
  can1  2A5  [08]  00 03 AC 4D 55 BF 2F 56     **
  can1  2A5  [08]  00 03 AC 4D 55 BF 2F 56     **

I've seen other failures that followed those two pattern. Unfortunately, I removed my external logger, so
it's unsure what actually happens on the bus.

> And one more observation: Once or twice I have seen my application fail with not returning MTU size in the socketcan read:
>   ERROR: recvfrom: ret=16, errno=0
> Is there any obvious explanation for this? I tried to add more output for this case, but it has not happed until then.

Stupid me. Obviously this is a message in old CAN_MTU size. Is this still used for errors even if the MTU is set to CANFD_MTU?
This did not show up again, so I wasn't yet able to look into the data payload.

-- Stefan

[-- Attachment #2: 20221231T0158_can1.tgz --]
[-- Type: application/x-compressed, Size: 5992 bytes --]