Oops. Sorry about that. It appears I had neglected to stop a prior instance when preparing the screenshot. However, the symptom does indeed occur with only one instance running. I will try to prepare a reproduction.1. Is ./control_loop your software which is (if I understand the command line correctly) supposed to run on CPU 3? htop shows several instances of it running on the other cores. And the "primary" process is shown as running on CPU 2.
I'm using this I2C AP|, but I had another part of my software doing a USB transfer, and that seems to be where the problem lies. I hope to post a reproduction soon.2. Are you using the normal kernel I2C interface routines? If so, this presumably exposes you to interference from the kernel during I2C accesses - maybe the scheduler sometimes takes a while to recognise that a transaction has completed and pass control back to your task.
Possibly you could prove this by substituting a short delay for the I2C task temporarily (although that will also use kernel services).
Yes, I'm aware, but isolcpus is so much more convenient and still works. I've experimented with cpusets, but it's still something I have to lookup every time I want to use it.Incidentally, are you aware that isolcpus is deprecated as of a couple of years ago? You're supposed to use cgroupscpuset now (no, I haven't tried it yet).
Yes, the latest stable release. And, I also tried the latest `rpi-update` as that has the ability to set interrupt affinity. But the symptom persists.Are you running Bookworm Pi OS?
Statistics: Posted by JinShil — Thu Apr 25, 2024 2:31 am