On Tue, Aug 05, 2025 at 10:40:30AM +0200, Gabriele Monaco wrote: > Hello Nam, > > I just built and booted up the monitor in a VM (virtme-ng), the > configuration has preemptirq tracepoints and all monitors so far (as we > have seen earlier, it doesn't build if rtapp monitors are not there > because of the circular dependency in the tracepoints). > > All I did was to enable the monitor and printk reactor, but I get a > whole lot of errors (as in, I need to quit the VM for it to stop): > > [ 1537.699834] rv: rts: 7: violation detected > [ 1537.699930] rv: rts: 3: violation detected > [ 1537.701827] rv: rts: 6: violation detected > [ 1537.704894] rv: rts: 0: violation detected > [ 1537.704925] rv: rts: 0: violation detected > [ 1537.704988] rv: rts: 3: violation detected > [ 1537.705019] rv: rts: 3: violation detected > [ 1537.705998] rv: rts: 0: violation detected > [ 1537.706024] rv: rts: 0: violation detected > [ 1537.709875] rv: rts: 6: violation detected > [ 1537.709921] rv: rts: 6: violation detected > [ 1537.711241] rv: rts: 6: violation detected > > Curiously enough, I only see those CPUs (0, 3, 6 and 7). > Other runs have different CPUs but always a small subset (e.g. 10-15, > 6-7 only 2). > It doesn't always occur but enabling/disabling the monitor might help > triggering it. > > Any idea what is happening?
Thanks for the report. I can reproduce the issue. Looking at the tracepoints, it makes sense why the monitor complains, some RT tasks are enqueued but are not dequeued. Then a sched_switch happens which switches to a non-RT task. Most likely the dequeue tracepoint misses some cases, let me investigate.. Nam
