CAN bus - MCP2515 IRQ eating CPU

Hey there,

I'm using Ubuntu Mate 18.04 arm64 on a Raspberry Pi 3 model B V1.2

I have a CAN bus shield on my RPi that uses a MCP2515 CAN controller (+ a CAN transceiver).
The CAN bus is working fine, I bring it on with:

sudo ip link set can0 up type can bitrate 250000

$ ifconfig can0
can0: flags=193<UP,RUNNING,NOARP>  mtu 16
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 10  (UNSPEC)
        RX packets 8142  bytes 40710 (40.7 KB)
        RX errors 0  dropped 8142  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I can inspect the traffic on the CAN bus with candump can0. I have very light traffic on the CAN bus (3 messages per second).

My problem is that the irq/154-MCP251x is consuming 90% of one core of the RPi and spi0 is consuming 40% of one core of the RPi.
Here are my kernel modules:

$ lsmod
Module                  Size  Used by
bnep                   28672  2
ip6table_filter        16384  1
ip6_tables             32768  1 ip6table_filter
iptable_filter         16384  1
hci_uart              139264  1
btbcm                  20480  1 hci_uart
btqca                  16384  1 hci_uart
btintel                24576  1 hci_uart
bluetooth             659456  28 btqca,btintel,hci_uart,btbcm,bnep
ecdh_generic           24576  1 bluetooth
serdev                 20480  1 hci_uart
binfmt_misc            20480  1
snd_bcm2835            40960  0
snd_pcm_oss            65536  0
snd_mixer_oss          32768  1 snd_pcm_oss
snd_pcm               159744  2 snd_bcm2835,snd_pcm_oss
snd_seq_dummy          16384  0
snd_seq_oss            53248  0
snd_seq_midi           20480  0
snd_seq_midi_event     16384  2 snd_seq_midi,snd_seq_oss
brcmfmac              368640  0
snd_rawmidi            45056  1 snd_seq_midi
brcmutil               16384  1 brcmfmac
snd_seq                86016  6 snd_seq_midi,snd_seq_oss,snd_seq_midi_event,snd_seq_dummy
cfg80211              765952  1 brcmfmac
snd_seq_device         16384  4 snd_seq,snd_seq_midi,snd_seq_oss,snd_rawmidi
snd_timer              36864  2 snd_seq,snd_pcm
mcp251x                24576  0
snd                   110592  9 snd_seq,snd_seq_device,snd_seq_oss,snd_bcm2835,snd_timer,snd_pcm_oss,snd_pcm,snd_rawmidi,snd_mixer_oss
can_dev                32768  1 mcp251x
uio_pdrv_genirq        16384  0
crc32_ce               16384  0
uio                    24576  1 uio_pdrv_genirq
sch_fq_codel           20480  4
ppdev                  20480  0
lp                     20480  0
parport                45056  2 lp,ppdev
ip_tables              32768  1 iptable_filter
x_tables               45056  4 ip6table_filter,iptable_filter,ip6_tables,ip_tables
sdhci_iproc            16384  0

Blacklisted modules:

$ grep -irn "bcm" /etc/modprobe.d/
/etc/modprobe.d/blacklist.conf:36:blacklist bcm43xx

My /boot/config.txt file:

hdmi_drive=2
start_x=1
gpu_mem=128
kernel=vmlinuz
initramfs initrd.img followkernel
dtparam=audio=on
dtparam=spi=on
arm_control=0x200
dtoverlay=mcp2515-can0,oscillator=16000000,interrupt=25
dtoverlay=spi-bcm2835-overlay

Why is the CAN bus eating so much CPU and how can I lower it?

Did you ever get answer here? Having the same issue on an RPi 4.

No sorry. I did not manage to improve the CPU load.

Hi guys i am having exact same issue with the mcp2515 and Pi - tested both on Pi 4B+ as well as Pi Zero. my system has two can bus interfaces and i can sometimes get one to work sort of properly but any attempt to have both of them configed and up'ped at one time will result in irq/160-mcp251x process eating whole cpu to the extent i can barely type any commands in GUI.

Would be really interested in getting to the bottom of it.

Hello,
I do not use Ubuntu Mate, but had the same issue using raspbian. The problem was that the interrupt pin of MCP2515 was not wired correctly to the pin specified in /boot/config.txt. As the interrupt pin is active low, it caused the interrupt to be fired over and over again even though there was no incomming packet on can bus. After wiring it correctly, the problem disappeared.
Perhaps it will help on Ubuntu as well.