On 16.12.21 09:49, Sam Daniel wrote: > On Thu, Dec 16, 2021 at 12:42 AM Jan Kiszka <jan.kis...@siemens.com> wrote: >> >> On 16.12.21 06:35, Sam Daniel via Xenomai wrote: >>> Hello. I am running on a Xilinx ZCU102 (ARM64, Cortex A53) development >>> board and I've written a lot of userspace software against the POSIX skin >>> of Cobalt 3.1. >>> >>> For context, I have set isolcpus=1,2,3 as kernel boot args. I only run my >>> Xenomai tasks on CPUs 1,2,3. I know that despite isolcpus, the Linux kernel >>> will still run a few kthreads on those cores. I am worried that the cause >>> of my issues might be my Xenomai tasks completely starving those Linux >>> kthreads. >> >> That is likely if your task actually dominates those isolated cores >> (100% CPU usage). The Xenomai watchdog can catch such bugs and resolve >> the lockup by kicking the CPU hog out of RT mode. Then you can analyze >> why the task was not sleeping from time to time. >> >> Jan >> >> -- >> Siemens AG, T RDA IOT >> Corporate Competence Center Embedded Linux > > I have CONFIG_XENO_OPT_WATCHDOG=y and CONFIG_XENO_OPT_DEBUG=y set but > don't get any Xenomai/watchdog related output when this kernel oops > occurs. >
OK, then your task should release the core from time to time, and we have a different kind of crash. What is your kernel version? Where did the patch come from? Also, your trace of the crash is unfortunately filled with printing the oops, likely not with the actual problem. Do you have a backtrace as well? Can you make the trace longer [1]? Jan [1] https://source.denx.de/Xenomai/xenomai/-/wikis/Using_The_I_Pipe_Tracer -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
