Re: Unexpected switches to in-band

[Philippe Gerum <rpm@xenomai.org>]

Hi Giulio,

Giulio Moro <giulio@bela.io> writes:

> Again, PocketBeagle 2 (TI AM6254). I get errors such as the below:
>
> debian@BeagleBone:~$ sudo latmus -m -H20 -T 500s
> warming up on CPU0 (not isolated)...
> RTT|  00:00:01  (user, 1000 us period, priority 98, CPU0-noisol)
> RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
> RTD|      4.957|     10.135|     22.647|       0|     0|      4.957|     22.647
> RTD|      4.977|     10.107|     23.112|       0|     0|      4.957|     23.112
> RTD|      0.948|     14.831|     52.911|       0|     0|      0.948|     52.911
> RTD|      4.084|      9.548|     24.404|       0|     0|      0.724|    122.540
> RTD|      4.195|     10.080|     50.350|       0|     0|      0.724|    122.540
> ---|-----------|-----------|-----------|--------|------|-----------------------
> RTS|   -982.336|     11.935|  12357.665|      22|     2|      00:02:36/00:08:20
>
> *** WARNING: unexpected switches to in-band mode detected,
>              latency figures displayed are NOT reliable.
>              Please submit a bug report upstream.
> -- aborting

Could you please checkout out the documentation regarding the 'latspot'
(f)tracepoint which the evl core implements [1]? This tracepoint is
specifically designed to help in finding the reason for delays in the
latmus program (you could use it in your own app as well).

>
> Possibly unrelated, it also happens that when I run our program, which runs with a period of 360us using 15% of CPU, it normally works OK, but occasionally I get _large_ underruns (like 3 to 5 ms). I haven't started debugging that yet, and I am not entirely sure it's EVL's fault, but I thought it may be worth mentioning it here.
>
> This is on a kernel I put together: I applied the EVL commits that are at the tip of v6.12.y-evl-rebase on top of the TI v6.12.43-ti-arm64-r53 kernel plus the beagleboard patches. Here's a link, FYI https://github.com/giuliomoro/linux/tree/v6.12.43-ti-arm64-r53-bb-evl
>
> I appreciate this may be a bit too far from mainline to ask for specific help, but I am wondering what the general approach to problem solution is here: what would make a the latmus thread unexpectedly switch to in-band?
>

Something happening in kernel space and/or at machine level (CPUfreq
event, NMI and so on), so the best way is to enable ftrace to track this
issue down.

> Thanks,
> Giulio

[1] https://v4.xenomai.org/core/commands/index.html

-- 
Philippe.