Hi, I'm experiencing a socket timeout when receiving an isotp transfer of 256 + overhead bytes via a real can interface. The same application runs without problems on vcan0. The output of dmesg. [ 146.507796] can: isotp protocol [ 146.534527] NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! [ 146.534672] NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! [ 146.534794] NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! [ 146.534920] NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! [ 146.535044] NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! [ 146.535169] NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! [ 146.535294] NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! [ 146.535418] NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! [ 146.535543] NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! [ 146.535668] NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! [ 194.034609] can-isotp: isotp_tx_timer_handler: can_send_ret -105 The output of candump. mcp0 17FC05F4 [8] 11 07 3C 00 00 00 00 00 mcp0 17FE05F4 [3] 30 00 00 mcp0 17FC05F4 [8] 21 00 42 4F 4F 54 00 00 mcp0 17FC05F4 [8] 22 00 00 00 5E 02 00 6A mcp0 17FC05F4 [8] 23 00 65 90 C4 BB FC 6C mcp0 17FC05F4 [8] 24 7A 68 F2 A2 C0 33 1F mcp0 17FC05F4 [8] 25 C8 D5 A7 E1 7C 00 01 mcp0 17FC05F4 [8] 26 43 20 01 00 00 00 00 mcp0 17FC05F4 [8] 27 00 00 00 00 00 00 00 mcp0 17FC05F4 [8] 28 00 00 00 00 00 00 00 mcp0 17FC05F4 [8] 29 00 00 00 00 00 00 00 mcp0 17FC05F4 [8] 2A 00 00 15 00 00 00 10 mcp0 17FC05F4 [8] 2B 00 00 00 02 00 00 00 mcp0 17FC05F4 [8] 2C D4 57 45 20 E8 57 45 mcp0 17FC05F4 [8] 2D 20 14 58 45 20 1C 58 mcp0 17FC05F4 [8] 2E 45 20 24 58 45 20 2C The setup is a pi0w with the seeed can fd board, e.g. mcp2518fd and current standard Raspbian. I'm running a (file) server on mcp0, a mock client on mcp1 and both are directly connected. The communication is technically full duplex with two independent isotp channels but the other channel is silent until a transfer is complete. Is such an issue known ? May this happen due to the limited resources of a pi0w ? Best Regards, Patrick Menschel
